VLANs und VMs?

[Kay Martinen]

Hallo

mir ergab sich eine Frage bezüglich VLANs und den VMs eines ProxMox VE
Hosts. Das Wiki gab dazu leider nur ein generelles setup wieder, das ich
so aber nicht brauche.

Man kann der/den Bridges ja mit einem "Vlan aware" wohl beibringen das
sie VLANs durchleiten sollen. Aber dann sehe ich die zwei möglichkeiten
die VLANs durch Software in der VM zu separieren oder ihr pro VLAN ein
eigenes interface ein zu richten und diesem die VLAN-ID mit zu geben.

Aber die Frage ist, welche von beiden Methoden ist Sinnvoller, Sparsamer
oder sicherer.

Klar ist mir mom. nur das man einer VM deren Software man evtl. nicht
traut (Windows? :) wohl besser nur das VLAN per separatem Interface gibt
das sie auch braucht - und nicht mehr.

Aber wie ist das z.B. mit Geschwindigkeit oder Verarbeitungstempo im
Vergleich zwischen x VLANs auf einem Interface oder einem Interface pro
VLAN.

Und, macht es bezüglich der Sicherheit einen Unterschied, z.B. bei einer
Opnsense-VM die zw. VLANs routen soll?

Der Proxmox Host hat aktuell 3 Gigabit NICs und 2 Bridges.

Kay

[Marcel Mueller]

On 30.04.17 03.11, Kay Martinen wrote:
> mir ergab sich eine Frage bezüglich VLANs und den VMs eines ProxMox VE
> Hosts. Das Wiki gab dazu leider nur ein generelles setup wieder, das ich
> so aber nicht brauche.
>
> Man kann der/den Bridges ja mit einem "Vlan aware" wohl beibringen das
> sie VLANs durchleiten sollen. Aber dann sehe ich die zwei möglichkeiten
> die VLANs durch Software in der VM zu separieren oder ihr pro VLAN ein
> eigenes interface ein zu richten und diesem die VLAN-ID mit zu geben.
>
> Aber die Frage ist, welche von beiden Methoden ist Sinnvoller, Sparsamer
> oder sicherer.

Ein Interface pro VLAN. Alles andere ist doch kein echtes VLAN. Ich mein
in VMs kosten dich die Interfaces ja nichts.

> Klar ist mir mom. nur das man einer VM deren Software man evtl. nicht
> traut (Windows? :) wohl besser nur das VLAN per separatem Interface gibt
> das sie auch braucht - und nicht mehr.

Eben.

> Aber wie ist das z.B. mit Geschwindigkeit oder Verarbeitungstempo im
> Vergleich zwischen x VLANs auf einem Interface oder einem Interface pro
> VLAN.

Das dürfte weitgehend Banane sein. Klar irgendein komisch programmiertes
Stück Software kann das zur einen oder anderen Seite kippen, aber einen
grundsätzlichen Unterschied gibt es da erst mal nicht. Es fließen ja
dieselben Daten.

Bei der Geschwindigkeit virtueller Netze kommt es eher darauf an in der
VM einen gescheiten Treiber zu nutzen. Am schnellsten ist natürlich
virtio, sprich Paravirtualisierung.
Falls man über emulierte Devices gehen muss, sollte man zumindest ein
nominell möglichst schnelles Device nehmen. Dann ist dessen Treiber
wenigstens näherungsweise für die Datenraten ausgelegt. Virtuelle Netze
ohne Phy-Layer sind halt oft ein zwei Zehnerpotenzen schneller als die
echten. Das kann da Timing des Treibers ganz schön durcheinander bringen
und auch mal lange schlafende Race-Conditions wecken.

> Und, macht es bezüglich der Sicherheit einen Unterschied, z.B. bei einer
> Opnsense-VM die zw. VLANs routen soll?

Naja, der Router sieht sowieso alle ihm zugeordneten VLANs.
Die Frage ist eher anders zu stellen: kann deine VM-Software virtuelle
Router zwischen den internen VLANs? Dann kann man sich die Runde durch
eine VM zum Routen nämlich komplett sparen.


Marcel

[Kay Martinen]

Am 30.04.2017 um 10:17 schrieb Marcel Mueller:
> On 30.04.17 03.11, Kay Martinen wrote:
>> Aber die Frage ist, welche von beiden Methoden ist Sinnvoller, Sparsamer
>> oder sicherer.
>
> Ein Interface pro VLAN. Alles andere ist doch kein echtes VLAN. Ich mein
> in VMs kosten dich die Interfaces ja nichts.

Wieso ist das kein echtes VLAN wenn man mehrere auf einem interface in
eine VM hinein bringen kann - wenn es sinn macht!?

Natürlich gehört dazu ein managed Switch, oder mehrere Ports an
verschiedenen Dummen Switches.

>> Aber wie ist das z.B. mit Geschwindigkeit oder Verarbeitungstempo im
>> Vergleich zwischen x VLANs auf einem Interface oder einem Interface pro
>> VLAN.
>

> Bei der Geschwindigkeit virtueller Netze kommt es eher darauf an in der
> VM einen gescheiten Treiber zu nutzen. Am schnellsten ist natürlich
> virtio, sprich Paravirtualisierung.

Wenn der Gast ihn kennt!

> Falls man über emulierte Devices gehen muss, sollte man zumindest ein
> nominell möglichst schnelles Device nehmen. Dann ist dessen Treiber
> wenigstens näherungsweise für die Datenraten ausgelegt. Virtuelle Netze
> ohne Phy-Layer sind halt oft ein zwei Zehnerpotenzen schneller als die

Nun, der Standard ist e1000, das dürfte wohl ein Gigabit-treiber sein.
Schneller ist hier sowieso nichts.

> echten. Das kann da Timing des Treibers ganz schön durcheinander bringen
> und auch mal lange schlafende Race-Conditions wecken.

Was meinst du mit "lange schlafendes Race-condiditions" genau? Kannst du
mir da ein Beispiel geben wo und wie so etwas auftritt oder entstehen
kann? Und wie lang das "schlafen" kann?

Ich habe hier heute grad ein seltsames Netzwerk-Problem gehabt das ich
aber nicht auf den VM-Host oder dessen gäste zurück führe, mir aber
dennoch ein Rätsel ist. Mehr dazu in der hardware-networking gruppe.

>> Und, macht es bezüglich der Sicherheit einen Unterschied, z.B. bei einer
>> Opnsense-VM die zw. VLANs routen soll?
>
> Naja, der Router sieht sowieso alle ihm zugeordneten VLANs.

Naja, eben nur wenn du sie nicht beim interface dieser VM angibst UND
die bridge "vlan-aware" ist.

So verstehe ich das. In dem fall bekommt die VM auf dem einen interface
alle VLANs zu sehen die über die bridge rein kommen.

Man kann jedem LANinterface der VM aber nur EIN VLAN vorgeben. Also
schliesse ich daraus das dann auch nur dieses VLAN in diese VM hinein
reicht.

Was automatisch bedeutet, entweder alle VLANs auf einem Interface oder
pro VLAN ein eigenes Interface mit vorgabe.

Was; wenn ich richtig verstehe; auch nur klappt wenn man das
"VLAN-aware" bei der Bridge nicht abschaltet und neu bootet.

Das ist das einzig blöde. Man muss zum ändern der bridges und interfaces
neu booten, was ein normales Linux nicht bräuchte. Aber mir ist klar das
es hier wegen der VMs der sicherere Weg ist.

> Die Frage ist eher anders zu stellen: kann deine VM-Software virtuelle
> Router zwischen den internen VLANs? Dann kann man sich die Runde durch
> eine VM zum Routen nämlich komplett sparen.

Ich wüsste jetzt nicht das Proxmox VE so was könnte. Zumindest habe ich
bisher nirgends einen Hinweis darauf gesehen. Da die Basis ein
Debian-linux ist wird das sicher irgendwie gehen. Eine Firewall ist;
offenbar pro VM aktivierbar; an board, sonst wüsste ich nichts.

Aber Opnsense ist ein BSD und ebenso wie ipfire )Linux) eben auch
bezügl. WebUI auf routing und Filterung speziell eingerichtet.

Vielleicht bietet Proxmox auch so was an, dann aber vermutlich als
kostenpflichtiges Feature. Aber dann will ich das nicht weil ich den
privat nutze. Der Mäkelt schon jedes mal beim einloggen ich hätte keine
subskription, arbeitet dann aber normal.

Einen kostenlosen lizenzkey für Privat scheint es nicht zu geben. So
lange es läuft soll mir das so auch recht sein.

Kay

[Marcel Mueller]

On 01.05.17 22.56, Kay Martinen wrote:
> Am 30.04.2017 um 10:17 schrieb Marcel Mueller:
>> On 30.04.17 03.11, Kay Martinen wrote:
>>> Aber die Frage ist, welche von beiden Methoden ist Sinnvoller, Sparsamer
>>> oder sicherer.
>>
>> Ein Interface pro VLAN. Alles andere ist doch kein echtes VLAN. Ich mein
>> in VMs kosten dich die Interfaces ja nichts.
>
> Wieso ist das kein echtes VLAN wenn man mehrere auf einem interface in
> eine VM hinein bringen kann - wenn es sinn macht!?
>
> Natürlich gehört dazu ein managed Switch, oder mehrere Ports an
> verschiedenen Dummen Switches.

In einer VM?

>> Falls man über emulierte Devices gehen muss, sollte man zumindest ein
>> nominell möglichst schnelles Device nehmen. Dann ist dessen Treiber
>> wenigstens näherungsweise für die Datenraten ausgelegt. Virtuelle Netze
>> ohne Phy-Layer sind halt oft ein zwei Zehnerpotenzen schneller als die
>
> Nun, der Standard ist e1000, das dürfte wohl ein Gigabit-treiber sein.

Ja, das sind die Intel GBit-Karten.

> Schneller ist hier sowieso nichts.

OK. Ich habe dunkel in Erinnerung, das über die virtuellen Karten
deutlich mehr geht. Natürlich immer vorausgesetzt der Traffic bleibt lokal.

>> echten. Das kann da Timing des Treibers ganz schön durcheinander bringen
>> und auch mal lange schlafende Race-Conditions wecken.
>
> Was meinst du mit "lange schlafendes Race-condiditions" genau? Kannst du
> mir da ein Beispiel geben wo und wie so etwas auftritt oder entstehen
> kann? Und wie lang das "schlafen" kann?

Naja, normalerweise dauern bestimmte I/O Aktivitäten mindestens eine
Bestimmte Zeit. Ein fehlerhafter Treiber könnte sich darauf
(versehentlich) verlassen und dann in einer VM auf die Nase fallen und
abstürzen. Es kommt schon gelegentlich mal vor, dass ein Programm in der
VM aufgrund des geänderten Timings sich unerwartet verhält. Beim
Netzwerk erinnere ich mich jetzt nicht an so einen Fall, aber bei
(virtuellen) Soundkarten hatte ich das definitiv schon.

>>> Und, macht es bezüglich der Sicherheit einen Unterschied, z.B. bei einer
>>> Opnsense-VM die zw. VLANs routen soll?
>>
>> Naja, der Router sieht sowieso alle ihm zugeordneten VLANs.
>
> Naja, eben nur wenn du sie nicht beim interface dieser VM angibst UND
> die bridge "vlan-aware" ist.

Deswegen sage ich doch: die zugeordneten.

> So verstehe ich das. In dem fall bekommt die VM auf dem einen interface
> alle VLANs zu sehen die über die bridge rein kommen.

Das wäre die Alternative mit nur einem Interface.
Aber außer dass sich dann die Daten der beiden Interfaces um ein
einziges Device prügeln müssen, hat man da jetzt nicht viel erreicht.

> Man kann jedem LANinterface der VM aber nur EIN VLAN vorgeben.

Damit ist die Sache doch schon geklärt. Dann kann der virtuelle Switch
der VM keine VLANs virtualisieren, sondern nur durchreichen.

> Also
> schliesse ich daraus das dann auch nur dieses VLAN in diese VM hinein
> reicht.

Es sein denn, man bindet 2 virtuelle Interfaces.

> Was automatisch bedeutet, entweder alle VLANs auf einem Interface oder
> pro VLAN ein eigenes Interface mit vorgabe.

Exakt.

> Was; wenn ich richtig verstehe; auch nur klappt wenn man das
> "VLAN-aware" bei der Bridge nicht abschaltet und neu bootet.

?

> Das ist das einzig blöde. Man muss zum ändern der bridges und interfaces
> neu booten, was ein normales Linux nicht bräuchte. Aber mir ist klar das
> es hier wegen der VMs der sicherere Weg ist.

Neu booten sicher nicht. Maximal den VM Service durchstarten.
Das geht bei VBox zumindest bei laufenden VMs, wenn es richtig
konfiguriert ist. Die VMs gehen dabei in den Pausezustand und können
nach dem Restart mit Resume wieder geweckt werden. Man muss nur etwas
mit dem Timeout zum Stoppen des Dienstes aufpassen, wenn die VMs viel
Speicher belegen. Es kann nämlich schon mal eine Weile dauern, bis z.B.
15GB auf die Platte geschrieben wurden.

>> Die Frage ist eher anders zu stellen: kann deine VM-Software virtuelle
>> Router zwischen den internen VLANs? Dann kann man sich die Runde durch
>> eine VM zum Routen nämlich komplett sparen.
>
> Ich wüsste jetzt nicht das Proxmox VE so was könnte. Zumindest habe ich
> bisher nirgends einen Hinweis darauf gesehen. Da die Basis ein
> Debian-linux ist wird das sicher irgendwie gehen. Eine Firewall ist;
> offenbar pro VM aktivierbar; an board, sonst wüsste ich nichts.

Naja, für virtuelle VLANs mit virtuellem Managed Switch dazwischen
braucht man schon ein bisschen mehr als eine Firewall.

> Vielleicht bietet Proxmox auch so was an, dann aber vermutlich als
> kostenpflichtiges Feature. Aber dann will ich das nicht weil ich den
> privat nutze. Der Mäkelt schon jedes mal beim einloggen ich hätte keine
> subskription, arbeitet dann aber normal.

Deswegen mache ich üblicherweise einen Bogen um solche
Freemium-Software, es sei denn ich will sowieso lizenzieren.
Daher bin ich für die virtuellen Desktops bei VBox gelandet. Für Server
würde ich vmtl. eher Xen nehmen.


Marcel

[ma...@invalid.invalid]

Proxmox ist meinem Verständnis nach open source, das einzige, wofür man
zahlen darf, ist Support.

cu
.\\arc

[Sven Hartge]

Marcel Mueller <news.5...@spamgourmet.org> wrote:

> OK. Ich habe dunkel in Erinnerung, das über die virtuellen Karten
> deutlich mehr geht. Natürlich immer vorausgesetzt der Traffic bleibt
> lokal.

Das ist auch so. Ich erreiche hier in einem ESX5.5 mit einer virtuelle
E1000 zwischen zwei VMs, die lokal auf dem gleichen Server laufen, eine
Übertragungsgeschwindigkeit von ~5000MBit/s. Stelle ich das auf den
paravirtualisierten VMXNet3 um, steigt das ganze auf ~9000MBit/s.

(Test mit iperf3.)

S°

--
Sigmentation fault. Core dumped.

[Kay Martinen]

Am 02.05.2017 um 01:31 schrieb Marcel Mueller:
> On 01.05.17 22.56, Kay Martinen wrote:
>> Am 30.04.2017 um 10:17 schrieb Marcel Mueller:
>>>
>>> Ein Interface pro VLAN. Alles andere ist doch kein echtes VLAN.
>>

>> Wieso ist das kein echtes VLAN wenn man mehrere auf einem interface in
>> eine VM hinein bringen kann - wenn es sinn macht!?
>>
>> Natürlich gehört dazu ein managed Switch, oder mehrere Ports an
>> verschiedenen Dummen Switches.
>
> In einer VM?

Nein, natürlich nicht in der VM. Sondern Extern am VM-Host selbst.

>> Nun, der Standard ist e1000, das dürfte wohl ein Gigabit-treiber sein.
>
> Ja, das sind die Intel GBit-Karten.
>
>> Schneller ist hier sowieso nichts.

Damit meinte ich die Externe HW außerhalb der VMs. Da ist nichts
schneller als Gigabit. Wollte damit nur sagen das ich noch keine 10GbE
oder irgendwas dazwischen hab. Auch keine Link-aggregation/Trunk/Bond u.s.w.

> OK. Ich habe dunkel in Erinnerung, das über die virtuellen Karten
> deutlich mehr geht. Natürlich immer vorausgesetzt der Traffic bleibt lokal.

Ah, okay. Das hab ich noch nie probiert weil das m.E. nur ein lokales
umschichten wäre. Und von einem VM-Host zu einem 2. (den ich auch nicht
hab) schlagen ja wieder die Limits der externen Karten zu.

>>> echten. Das kann da Timing des Treibers ganz schön durcheinander bringen
>>> und auch mal lange schlafende Race-Conditions wecken.

Kann hier vermutlich nicht passieren da ich (s.o.) keinen großartigen
lokalen verkehr habe.

>> Was meinst du mit "lange schlafendes Race-condiditions" genau? Kannst du
>

> Naja, normalerweise dauern bestimmte I/O Aktivitäten mindestens eine
> Bestimmte Zeit. Ein fehlerhafter Treiber könnte sich darauf
> (versehentlich) verlassen und dann in einer VM auf die Nase fallen und
> abstürzen. Es kommt schon gelegentlich mal vor, dass ein Programm in der
> VM aufgrund des geänderten Timings sich unerwartet verhält. Beim
> Netzwerk erinnere ich mich jetzt nicht an so einen Fall, aber bei
> (virtuellen) Soundkarten hatte ich das definitiv schon.

Dann betrifft es mich offenbar eh nicht. Der Host ist ein Server ohne
Audio und wenn ich mal eine Desktop-VM dort haben sollte dann ginge die
Ausgabe eh an den Client, also nichtlokal.

> Das wäre die Alternative mit nur einem Interface.
> Aber außer dass sich dann die Daten der beiden Interfaces um ein
> einziges Device prügeln müssen, hat man da jetzt nicht viel erreicht.

Daran hatte ich noch nicht gedacht, guter Punkt. Andererseits ist der
GbE-Port des Servers theoretisch 10 mal Schneller als eine Virtuelle
Fastethernet-NIC. Was hier meist reichen würde da der "dicke" Traffic
(Videos, fileserver) eh durch die echten Switche geht und die VMs nicht
tangiert. Dort wäre (router-einsatz) FE ausreichend zwischen DMZ, WAN
und allem anderen. Hab eh nur 2Mbit Internet!

>> Man kann jedem LANinterface der VM aber nur EIN VLAN vorgeben.
>
> Damit ist die Sache doch schon geklärt. Dann kann der virtuelle Switch
> der VM keine VLANs virtualisieren, sondern nur durchreichen.

>> Was; wenn ich richtig verstehe; auch nur klappt wenn man das
>> "VLAN-aware" bei der Bridge nicht abschaltet und neu bootet.
>
> ?

Die OpenVbridge/Switch o.ä. hab ich noch nicht eingesetzt. Bisher nur
das übliche Bridge-setup. Und da gibt es m.W. nur die möglichkeit bei
einer bridge Vlan-aware= yes oder no zu wählen.

No= VLAN werden blockiert.
Yes= Vlans gehen durch.

Und nur bei yes kann man ja auf den virtuellen interfaces VLANs nutzen.

>> neu booten, was ein normales Linux nicht bräuchte. Aber mir ist klar das
>> es hier wegen der VMs der sicherere Weg ist.
>
> Neu booten sicher nicht. Maximal den VM Service durchstarten.

Das hier ist ProxmoxVE mit KVM und Qemu. Ich wüsste jetzt nicht was ich
da allein neu starten müsste. Wenn ich im WebUI die netzwerk-konfig des
hosts ändere dann passiert nichts sofort. Nur ein Hinweis das änderungen
erst nach Reboot aktiv werden.

> Das geht bei VBox zumindest bei laufenden VMs, wenn es richtig
> konfiguriert ist. Die VMs gehen dabei in den Pausezustand und können
> nach dem Restart mit Resume wieder geweckt werden. Man muss nur etwas
> mit dem Timeout zum Stoppen des Dienstes aufpassen, wenn die VMs viel
> Speicher belegen. Es kann nämlich schon mal eine Weile dauern, bis z.B.
> 15GB auf die Platte geschrieben wurden.

Ich hab bei vbox nie mit dem netzwerk gespielt, möglich das es dort geht.

Ich würde auch gern virtualbox auf diesem ProxMox server haben, glaube
aber das sich das nicht in dessen konfigurations-schemata einfügt.

Und einen Gast auf zu setzen unter dem dann Virtualbox wiederrum gäste
liefert ist mir zu viel doppeltgemoppelt. Denn wenn, dann wäre das die
Praktischste Lösung für remote Desktops (via RDP zum vbox-eigenen
serverdienst).

> Naja, für virtuelle VLANs mit virtuellem Managed Switch dazwischen
> braucht man schon ein bisschen mehr als eine Firewall.

Die VLANs machen hier ein Cisco, ein TP-Link und ein Netgear Switch
extern. Die sollen nur über die Bridge zu den VMs rein reichen.

>> privat nutze. Der Mäkelt schon jedes mal beim einloggen ich hätte keine
>> subskription, arbeitet dann aber normal.
>
> Deswegen mache ich üblicherweise einen Bogen um solche
> Freemium-Software, es sei denn ich will sowieso lizenzieren.

Es ist ein Debian-linux mit den ProxmoxVE paketen. Das läuft auch so.
Zahlen müsste man da wohl nur für Support und evtl. für Erweiterungen
die VM-Cluster betreffen - die ich nicht hab und brauch.

Die Meldung taucht nur einmal bei jedem einloggen in die WebUI auf und
ansonsten nicht.

> Daher bin ich für die virtuellen Desktops bei VBox gelandet. Für Server
> würde ich vmtl. eher Xen nehmen.

Xen habe ich mal versucht, aber wohl falsch oder nicht verstanden. Dann
hatte der sich stundenlang mit dem einrichten aufgehalten und ich
stellte fest das der eine komplette distri durch meinen dünnen
DSL-strohhalm saugen wollte. :-/

Worauf fußen deine Virtuellen Desktops? Ein WoW (Windows on Windows)
finde ich total unsinnig, weil man immer versucht ist direkt auf dem
host zu arbeiten. Bleibt nur Linux als Host der VMs oder?

Benutzt du die oracle-pakete oder die der distri?

Kay

[Marcel Mueller]

On 03.05.17 01.54, Kay Martinen wrote:
>>> Nun, der Standard ist e1000, das dürfte wohl ein Gigabit-treiber sein.

>>> Schneller ist hier sowieso nichts.
>
> Damit meinte ich die Externe HW außerhalb der VMs. Da ist nichts
> schneller als Gigabit. Wollte damit nur sagen das ich noch keine 10GbE
> oder irgendwas dazwischen hab. Auch keine Link-aggregation/Trunk/Bond
> u.s.w.

Habe ich auch alles nicht. Allerdings laufen alle VMs auf derselben
Hardware die ebenfalls den Netzwerk-Storage beheimatet, so dass bestimmt
80% des Traffics hardwaretechnisch lokal sind.


[Timing virtueller Hardware und Treiberfehler]

> Dann betrifft es mich offenbar eh nicht. Der Host ist ein Server ohne
> Audio und wenn ich mal eine Desktop-VM dort haben sollte dann ginge die
> Ausgabe eh an den Client, also nichtlokal.

Bei mir auch. Hat trotzdem geknallt, weil das Timing der virtuellen
Soundkarte eben doch nicht dasselbe ist.

> Daran hatte ich noch nicht gedacht, guter Punkt. Andererseits ist der
> GbE-Port des Servers theoretisch 10 mal Schneller als eine Virtuelle
> Fastethernet-NIC. Was hier meist reichen würde da der "dicke" Traffic
> (Videos, fileserver) eh durch die echten Switche geht und die VMs nicht
> tangiert. Dort wäre (router-einsatz) FE ausreichend zwischen DMZ, WAN
> und allem anderen. Hab eh nur 2Mbit Internet!

Für Internet-Routing reicht es immer. Nur im Intranet hat man gerade
beim Kopieren größerer Dateien (z.B. Filme oder VM-Container beim
Backup) keine Lust ewig zu warten.

>>> neu booten, was ein normales Linux nicht bräuchte. Aber mir ist klar das
>>> es hier wegen der VMs der sicherere Weg ist.
>>
>> Neu booten sicher nicht. Maximal den VM Service durchstarten.
>
> Das hier ist ProxmoxVE mit KVM und Qemu. Ich wüsste jetzt nicht was ich
> da allein neu starten müsste. Wenn ich im WebUI die netzwerk-konfig des
> hosts ändere dann passiert nichts sofort. Nur ein Hinweis das änderungen
> erst nach Reboot aktiv werden.

Da hat man sich halt nicht viel Mühe gegeben.
Das ist wie bei Windows-Installern. "Bitte starten sie das System neu."
90% der Software funktioniert auch ohne Neustart, aber wen interessiert das?

[Host bei laufenden VMs durchstarten]

> Ich hab bei vbox nie mit dem netzwerk gespielt, möglich das es dort geht.

Wenn Du die VMs auf Filesystemebene pausieren kannst, also so, dass die
Prozesse weg sind, dann sollten die Bedingungen dafür gegeben sein. Alle
VMs pausieren, Host durchstarten, VMs wieder weiter laufen lassen.

> Ich würde auch gern virtualbox auf diesem ProxMox server haben, glaube
> aber das sich das nicht in dessen konfigurations-schemata einfügt.

Das geht oft Hardwaretechnisch nicht. Zumindest Intel-Prozessoren dulden
keine mehreren Götter (also mehrere Nutzer der Hardware-Virtualisierung).
Bei AMD geht das wohl, aber das ist noch lange keine Garantie, dass sich
die Lösungen nicht an anderer Stelle, z.B. dem Netzwerkinterface,
gegenseitig in die Quere kommen.

> Und einen Gast auf zu setzen unter dem dann Virtualbox wiederrum gäste
> liefert ist mir zu viel doppeltgemoppelt.

Ack. So etwas macht man, wenn man muss, nicht weil man es kann.

> Denn wenn, dann wäre das die
> Praktischste Lösung für remote Desktops (via RDP zum vbox-eigenen
> serverdienst).

Ja, das ist tatsächlich eine sehr gute Lösung, die sich im Gegensatz zu
den Administrativen Zugängen anderer Lösungen auch für den täglichen
Betrieb eignet. In Punkto zentrale Desktop-Virtualisierung kommt da
bisher niemand ran.
Aber wenn man Remote nicht braucht, ist es auch kein Vorteil.

>> Naja, für virtuelle VLANs mit virtuellem Managed Switch dazwischen
>> braucht man schon ein bisschen mehr als eine Firewall.
>
> Die VLANs machen hier ein Cisco, ein TP-Link und ein Netgear Switch
> extern. Die sollen nur über die Bridge zu den VMs rein reichen.

Das hat halt den Nachteil, dass der ganze VM zu VM Traffic auch
mindestens zweimal über die physikalischen Netzwerkinterfaces muss. Die
Runde kann man sich sparen, wenn man auch das virtualisiert. ESX ist an
dieser Stelle wohl ziemlich weit.

>> Daher bin ich für die virtuellen Desktops bei VBox gelandet. Für Server
>> würde ich vmtl. eher Xen nehmen.
>
> Xen habe ich mal versucht, aber wohl falsch oder nicht verstanden. Dann
> hatte der sich stundenlang mit dem einrichten aufgehalten und ich
> stellte fest das der eine komplette distri durch meinen dünnen
> DSL-strohhalm saugen wollte. :-/

Ja, das ist bei Linux mittlerweile so üblich. Aber ab Win10 ist es da
dasselbe - ohne fette Leitung nicht sinnvoll benutzbar.

> Worauf fußen deine Virtuellen Desktops? Ein WoW (Windows on Windows)
> finde ich total unsinnig, weil man immer versucht ist direkt auf dem
> host zu arbeiten. Bleibt nur Linux als Host der VMs oder?

Ja Host ist ein altes Debian. Darauf laufen dann die VMs. Darunter auch
solche Sachen, wie eComStation gerade hier.

Der eigentliche Antrieb war, dass mehr oder minder alle Familien PCs
veraltet waren (8 Jahre oder mehr), und außerdem waren die Daten, die
man braucht oder der Drucker immer an dem Rechner, der gerade aus war.
Netzwerk-Storage gab es zwar schon längst, aber der wurde eben nicht
konsequent genutzt.
Anstelle einer Komplett-Sanierung habe ich daher für rund 300€ einen
VM-Server hingestellt und die existierenden Rechner zu Thin-Clients
degradiert. Dafür genügen sie noch heute. Der Älteste ist jetzt fast 15
Jahre. OK, der wird langsam grenzwertig.
Wesentlicher Vorteil der Lösung ist, dass man die Programme einfach alle
offen lassen kann und eben diese offenen Programme vom Laptop im Garten
nahtlos zum PC im Büro (mit gescheitem 30") Schirm mitnehmen kann.

> Benutzt du die oracle-pakete oder die der distri?

Oracle.
Bei Debian sind nicht nur die Server, sondern auch die Versionsnummern
der Programme stabil. Ich glaube die sind irgendwo bei VBox 3.irgendwas.
Und RDP geht damit auch nicht.


Marcel

[Marc Haber]

Kay Martinen <k...@martinen.de> wrote:
>mir ergab sich eine Frage bezüglich VLANs und den VMs eines ProxMox VE
>Hosts. Das Wiki gab dazu leider nur ein generelles setup wieder, das ich
>so aber nicht brauche.
>
>Man kann der/den Bridges ja mit einem "Vlan aware" wohl beibringen das
>sie VLANs durchleiten sollen. Aber dann sehe ich die zwei möglichkeiten
>die VLANs durch Software in der VM zu separieren oder ihr pro VLAN ein
>eigenes interface ein zu richten und diesem die VLAN-ID mit zu geben.
>
>Aber die Frage ist, welche von beiden Methoden ist Sinnvoller, Sparsamer
>oder sicherer.

Ich kann jetzt nicht konkret für Proxmox sprechen, aber es ist weithin
Stand der Technik, dass man mehrere VLANS in einem Trunk an den
VM-Host heranführt und dann einzelne VLANs an die VMs weitergibt. Ich
gebe grundsätzlich jedes VLAN als ein einzelnes, nicht getaggtes
Interface an eine VM weiter; virtuelle Interfaces kosten nichts und
halten die Konfiguration der VM einfacher.

Ausnahme sind VMs, die sowieso alle VLANs brauchen (z.B. der
virtualisierte Router zwischen den VLANs), die bekommen den Trunk 1:1
hineingereicht.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Kay Martinen]

Am 03.05.2017 um 19:46 schrieb Marc Haber:

> Kay Martinen <k...@martinen.de> wrote:
>> sie VLANs durchleiten sollen. Aber dann sehe ich die zwei möglichkeiten
>> die VLANs durch Software in der VM zu separieren oder ihr pro VLAN ein
>> eigenes interface ein zu richten und diesem die VLAN-ID mit zu geben.
>

> Ich kann jetzt nicht konkret für Proxmox sprechen, aber es ist weithin
> Stand der Technik, dass man mehrere VLANS in einem Trunk an den
> VM-Host heranführt und dann einzelne VLANs an die VMs weitergibt. Ich
> gebe grundsätzlich jedes VLAN als ein einzelnes, nicht getaggtes
> Interface an eine VM weiter; virtuelle Interfaces kosten nichts und
> halten die Konfiguration der VM einfacher.

Ja, das sehe ich durch Marcel's Antworten nun auch so. Weil ich einfach
nicht auf die idee kam das virtuelle IFs ja nix kosten.

Ebenso hab ich eingangs vergessen zu erwähnen das ich natürlich einen
Trunk mit multiplen VLans vom Externen Switch zum physischen Interface
des VM-Hosts meine. Weil es mir die einzig sinnvolle Lösung schien hab
ich es wohl nicht erwähnt. Mag sein das ich Marcel und ich da ungewollt
aneinander vorbei redeten.

> Ausnahme sind VMs, die sowieso alle VLANs brauchen (z.B. der
> virtualisierte Router zwischen den VLANs), die bekommen den Trunk 1:1
> hineingereicht.

Das war auch mein Gedanke mit Opnsense. Die Idee von Marcel, das sich
die In und Out-daten dann nicht um das Interface prügeln müssten ist
natürlich ein PRO für einzelne If's für den Router.

Selbst wenn Proxmox zwischen VLANs routen könnte, irgendwie sehe ich
darin eine Aufweichung des Konzepts eines VM-Hosts.

Kay

[Richard Lechner]

Am Tue, 02 May 2017 08:47:45 +0200 schrieb marc:

> Proxmox ist meinem Verständnis nach open source, das einzige, wofür man
> zahlen darf, ist Support.

Weniger auf die Werbung schauen!
Zugang zum "stabilen" Repo gibts nur gegen Geld und die Beträge steigen
jedes Jahr deutlich über Inflationsrate. :-(

Ansonsten gute Software aber Open Source meint bei Proxmox auch genau das.

[Michael Prokop]

* Richard Lechner wrote:
> Am Tue, 02 May 2017 08:47:45 +0200 schrieb marc:

>> Proxmox ist meinem Verständnis nach open source, das einzige, wofür man
>> zahlen darf, ist Support.

> Weniger auf die Werbung schauen!
> Zugang zum "stabilen" Repo gibts nur gegen Geld

Naja, das Proxmox VE Enterprise-Repository brauchts nicht zwingend,
auch nicht für den Produktivbetrieb. BTDT.

> und die Beträge steigen jedes Jahr deutlich über Inflationsrate.
> :-(

Im Juli 2015 ware es laut
http://web.archive.org/web/20150707133137/http://www.proxmox.com/de/proxmox-ve/preise
4,99 EUR für Community, 18,33 für Basic, 33,17 für Standard
und 66,33 für Premium pro CPU und Monat.

Im Mai 2016 waren es 5,41 EUR für Community, 19,16 für Basic, 33,17
für Standard und 66,33 für Premium pro CPU und Monat.

Aktuell (Mai 2017) liegt es bei 5,83 EUR für Community, 19,99 für
Basic, 33,17 für Standard und 66,33 für Premium pro CPU und Monat.

Das "deutlich" kann ich also nicht nachvollziehen, vor allem weil
die Standard- und Premium-Subskriptionen preislich seit mind. 2
Jahren gleich sind.

> Ansonsten gute Software aber Open Source meint bei Proxmox auch genau das.

Was auch immer du damit sagen willst, *shrug*.

-mika-

[Richard Lechner]

Am Thu, 04 May 2017 14:37:49 +0200 schrieb Michael Prokop:

> Naja, das Proxmox VE Enterprise-Repository brauchts nicht zwingend,
> auch nicht für den Produktivbetrieb. BTDT.

Testing in der Produktion? Na dann viel Spass mal!

> Das "deutlich" kann ich also nicht nachvollziehen, vor allem weil die
> Standard- und Premium-Subskriptionen preislich seit mind. 2 Jahren
> gleich sind.

HAHAHAHA! Der war gut!

OK extra für dich nachgesehen:

2014 49,90/per Node / Jahr
2017 69,90/per Node / Jahr

So jetzt darfst selber rechnen!

Das macht bei mehreren Nodes schon was aus wenn die Preise derartig
anziehen. Wo uns Vmware für 3 Nodes a 2 CPU's gerade mal gesamt ~58.-/
Jahr kostet.

>> Ansonsten gute Software aber Open Source meint bei Proxmox auch genau
>> das.
>
> Was auch immer du damit sagen willst, *shrug*.

man source

[Michael Prokop]

* Richard Lechner wrote:
> Am Thu, 04 May 2017 14:37:49 +0200 schrieb Michael Prokop:

>> Naja, das Proxmox VE Enterprise-Repository brauchts nicht zwingend,
>> auch nicht für den Produktivbetrieb. BTDT.

> Testing in der Produktion? Na dann viel Spass mal!

Man macht die QA dann halt selbst, wenn man das Geld nicht beim
Hersteller einwerfen will. Aber es *geht* und man darf es.

>> Das "deutlich" kann ich also nicht nachvollziehen, vor allem weil die
>> Standard- und Premium-Subskriptionen preislich seit mind. 2 Jahren
>> gleich sind.

> HAHAHAHA! Der war gut!

> OK extra für dich nachgesehen:

> 2014 49,90/per Node / Jahr
> 2017 69,90/per Node / Jahr

> So jetzt darfst selber rechnen!

Wie schon geschrieben: die Standard- und Premium-Subskriptionen
*sind* seit mind. 2 Jahren unverändert geblieben. (Und die 20 EUR
Preissteigerung innerhalb von 3 Jahren finde ich im professionellen
Umfeld keiner Diskussion würdig, YMMV.)

> Das macht bei mehreren Nodes schon was aus wenn die Preise derartig
> anziehen. Wo uns Vmware für 3 Nodes a 2 CPU's gerade mal gesamt ~58.-/
> Jahr kostet.

Von welchem VMware-Produkt redest du hier, das in Summe 58EUR/Jahr
für 3 Nodes a 2 CPUs ausmacht und mit Proxmox vergleichbar wäre?

-mika-

[Richard Lechner]

Am Fri, 05 May 2017 14:49:04 +0200 schrieb Michael Prokop:

>> Testing in der Produktion? Na dann viel Spass mal!
>
> Man macht die QA dann halt selbst, wenn man das Geld nicht beim
> Hersteller einwerfen will. Aber es *geht* und man darf es.

Das hat jetzt mit dem stabilen Repozugang was zu tun?

>>> Das "deutlich" kann ich also nicht nachvollziehen, vor allem weil die
>>> Standard- und Premium-Subskriptionen preislich seit mind. 2 Jahren
>>> gleich sind.
>
>> HAHAHAHA! Der war gut!
>
>> OK extra für dich nachgesehen:
>
>> 2014 49,90/per Node / Jahr 2017 69,90/per Node / Jahr
>
>> So jetzt darfst selber rechnen!
>
> Wie schon geschrieben: die Standard- und Premium-Subskriptionen *sind*
> seit mind. 2 Jahren unverändert geblieben. (Und die 20 EUR
> Preissteigerung innerhalb von 3 Jahren finde ich im professionellen
> Umfeld keiner Diskussion würdig, YMMV.)

Naja das sind immerhin ~40% und damit liegt es _deutlich_ ÜBER der
Inflationsrate von 1 - 1,4% pro Jahr, meinst du nicht auch?

> Von welchem VMware-Produkt redest du hier, das in Summe 58EUR/Jahr für 3
> Nodes a 2 CPUs ausmacht und mit Proxmox vergleichbar wäre?

vSphere 5 steht in der Verlängerung, die Version läuft schon länger. :-)

[Michael Prokop]

* Richard Lechner wrote:
> Am Fri, 05 May 2017 14:49:04 +0200 schrieb Michael Prokop:

>>> Testing in der Produktion? Na dann viel Spass mal!

>> Man macht die QA dann halt selbst, wenn man das Geld nicht beim
>> Hersteller einwerfen will. Aber es *geht* und man darf es.

> Das hat jetzt mit dem stabilen Repozugang was zu tun?

Die Pakete aus dem offenen Repository wandern einfach nur nach
einiger Zeit (AKA abhängen) ins Enterprise-Repository, AFAICT. Du
musst die "Bleeding-Edge"-Pakete ja nicht zwingend umgehend
einspielen, sondern kannst die durch deine eigene QA jagen, dann
brauchst du das Enterprise-Repository auch nicht.

>> Wie schon geschrieben: die Standard- und Premium-Subskriptionen *sind*
>> seit mind. 2 Jahren unverändert geblieben. (Und die 20 EUR
>> Preissteigerung innerhalb von 3 Jahren finde ich im professionellen
>> Umfeld keiner Diskussion würdig, YMMV.)

> Naja das sind immerhin ~40% und damit liegt es _deutlich_ ÜBER der
> Inflationsrate von 1 - 1,4% pro Jahr, meinst du nicht auch?

Für die *kleinen* (Community- und Basic-)Subskription-Pakete, ja.
Mir ists halt idR schon lieber, wenn der Hersteller seine Preise
anpasst und dafür am Markt bestehen bleibt, als dass er stattdessen
an der Qualitätsschraube drehen muss. Und die Standard- und
Premium-Subskriptionen (auf die man dann bei Produktionsbetrieb eher
schauen wird) sind unverändert geblieben.

>> Von welchem VMware-Produkt redest du hier, das in Summe 58EUR/Jahr für 3
>> Nodes a 2 CPUs ausmacht und mit Proxmox vergleichbar wäre?

> vSphere 5 steht in der Verlängerung, die Version läuft schon länger. :-)

Toller Vergleich...

-mika-

[Richard Lechner]

Am Fri, 05 May 2017 15:50:46 +0200 schrieb Michael Prokop:

>> Das hat jetzt mit dem stabilen Repozugang was zu tun?
>
> Die Pakete aus dem offenen Repository wandern einfach nur nach einiger
> Zeit (AKA abhängen) ins Enterprise-Repository, AFAICT. Du musst die
> "Bleeding-Edge"-Pakete ja nicht zwingend umgehend einspielen, sondern
> kannst die durch deine eigene QA jagen, dann brauchst du das
> Enterprise-Repository auch nicht.

Hat auch nichts mit Zugang zum Repro nur gegen Geld zu tun. Ausserdem
schreibt der Hersteller:

Proxmox VE Enterprise Repository
This is the default, stable and recommended repository, available for all
Proxmox VE subscription users. It contains the most stable packages, and
is suitable for production use.

Proxmox VE No-Subscription Repository
As the name suggests, you do not need a subscription key to access this
repository. It can be used for testing and non-production use. Its not
recommended to run on production servers, as these packages are not
always heavily tested and validated.

Also nochmal, man zahlt erstmal für den Zugang zu den stabilen Programmen
und nicht nur für den Support. Thats all i'm saying!

>> Naja das sind immerhin ~40% und damit liegt es _deutlich_ ÜBER der
>> Inflationsrate von 1 - 1,4% pro Jahr, meinst du nicht auch?
>
> Für die *kleinen* (Community- und Basic-)Subskription-Pakete, ja. Mir
> ists halt idR schon lieber, wenn der Hersteller seine Preise anpasst und
> dafür am Markt bestehen bleibt, als dass er stattdessen an der
> Qualitätsschraube drehen muss. Und die Standard- und
> Premium-Subskriptionen (auf die man dann bei Produktionsbetrieb eher
> schauen wird) sind unverändert geblieben.

Naja die Preise sind wohl "angepasst" worden, hat halt nichts mit der
Teuerung zu tun. Vermutlich neue schöne Dienstautos. :-)
Steht aber jedem frei das zu tun!

>> vSphere 5 steht in der Verlängerung, die Version läuft schon länger.
>> :-)
>
> Toller Vergleich...

Die Maschinen tun seit Jahren ihre Arbeit, störungsfrei mehr oder
weniger. Seh da jetzt einen grossen Unterschied.

[Michael Prokop]

* Richard Lechner wrote:
> Am Fri, 05 May 2017 15:50:46 +0200 schrieb Michael Prokop:

>>> Das hat jetzt mit dem stabilen Repozugang was zu tun?

>> Die Pakete aus dem offenen Repository wandern einfach nur nach einiger
>> Zeit (AKA abhängen) ins Enterprise-Repository, AFAICT. Du musst die
>> "Bleeding-Edge"-Pakete ja nicht zwingend umgehend einspielen, sondern
>> kannst die durch deine eigene QA jagen, dann brauchst du das
>> Enterprise-Repository auch nicht.

> Hat auch nichts mit Zugang zum Repro nur gegen Geld zu tun. Ausserdem
> schreibt der Hersteller:

[...]

> Also nochmal, man zahlt erstmal für den Zugang zu den stabilen Programmen
> und nicht nur für den Support. Thats all i'm saying!

Du zahlst dafür, dass du (zusätzlich zum Support) "gut abgehangene"
Pakete bekommst. Du kannst sie (die Pakete aus dem offenen
Repository) auch bei dir selbst testen und abhängen lassen. Wenn man
das nicht selbst machen will/kann und/oder den Support in Anspruch
nehmen möchte, zahlt man die Subkription. Thats all i'm saying! :)

-mika-