Discussion:
VLANs und VMs?
(zu alt für eine Antwort)
Kay Martinen
2017-04-30 01:11:44 UTC
Permalink
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
2017-04-30 08:17:08 UTC
Permalink
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Kay Martinen
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
2017-05-01 20:56:26 UTC
Permalink
Post by Marcel Mueller
Post by Kay Martinen
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.
Post by Marcel Mueller
Post by Kay Martinen
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!
Post by Marcel Mueller
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.
Post by Marcel Mueller
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.
Post by Marcel Mueller
Post by Kay Martinen
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.
Post by Marcel Mueller
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
2017-05-01 23:31:36 UTC
Permalink
Post by Kay Martinen
Post by Marcel Mueller
Post by Kay Martinen
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?
Post by Kay Martinen
Post by Marcel Mueller
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.
Post by Kay Martinen
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.
Post by Kay Martinen
Post by Marcel Mueller
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.
Post by Kay Martinen
Post by Marcel Mueller
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Kay Martinen
Also
schliesse ich daraus das dann auch nur dieses VLAN in diese VM hinein
reicht.
Es sein denn, man bindet 2 virtuelle Interfaces.
Post by Kay Martinen
Was automatisch bedeutet, entweder alle VLANs auf einem Interface oder
pro VLAN ein eigenes Interface mit vorgabe.
Exakt.
Post by Kay Martinen
Was; wenn ich richtig verstehe; auch nur klappt wenn man das
"VLAN-aware" bei der Bridge nicht abschaltet und neu bootet.
?
Post by Kay Martinen
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.
Post by Kay Martinen
Post by Marcel Mueller
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.
Post by Kay Martinen
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
m***@invalid.invalid
2017-05-02 06:47:45 UTC
Permalink
Post by Marcel Mueller
Post by Kay Martinen
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.
Proxmox ist meinem Verständnis nach open source, das einzige, wofür man
zahlen darf, ist Support.

cu
.\\arc
Richard Lechner
2017-05-04 05:20:27 UTC
Permalink
Post by m***@invalid.invalid
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
2017-05-04 12:37:49 UTC
Permalink
Post by Richard Lechner
Post by m***@invalid.invalid
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.
Post by Richard Lechner
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.
Post by Richard Lechner
Ansonsten gute Software aber Open Source meint bei Proxmox auch genau das.
Was auch immer du damit sagen willst, *shrug*.

-mika-
Richard Lechner
2017-05-05 11:14:58 UTC
Permalink
Post by 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!
Post by Michael Prokop
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.
Post by Michael Prokop
Post by Richard Lechner
Ansonsten gute Software aber Open Source meint bei Proxmox auch genau das.
Was auch immer du damit sagen willst, *shrug*.
man source
Michael Prokop
2017-05-05 12:49:04 UTC
Permalink
Post by Richard Lechner
Post by 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.
Post by Richard Lechner
Post by Michael Prokop
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!
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.)
Post by Richard Lechner
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
2017-05-05 13:26:47 UTC
Permalink
Post by Michael Prokop
Post by Richard Lechner
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?
Post by Michael Prokop
Post by Richard Lechner
Post by Michael Prokop
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!
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?
Post by Michael Prokop
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
2017-05-05 13:50:46 UTC
Permalink
Post by Richard Lechner
Post by Michael Prokop
Post by Richard Lechner
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.
Post by Richard Lechner
Post by Michael Prokop
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.
Post by Richard Lechner
Post by Michael Prokop
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
2017-05-05 15:03:29 UTC
Permalink
Post by Richard Lechner
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!
Post by Richard Lechner
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!
Post by Richard Lechner
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
2017-05-05 16:01:44 UTC
Permalink
Post by Richard Lechner
Post by Richard Lechner
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
[...]
Post by Richard Lechner
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-

Sven Hartge
2017-05-02 07:23:13 UTC
Permalink
Post by Marcel Mueller
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.)


--
Sigmentation fault. Core dumped.
Kay Martinen
2017-05-02 23:54:26 UTC
Permalink
Post by Marcel Mueller
Post by Kay Martinen
Post by 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.
Post by Marcel Mueller
Post by Kay Martinen
Nun, der Standard ist e1000, das dürfte wohl ein Gigabit-treiber sein.
Ja, das sind die Intel GBit-Karten.
Post by Kay Martinen
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.
Post by Marcel Mueller
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.
Post by Marcel Mueller
Post by Kay Martinen
Post by Marcel Mueller
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.
Post by Marcel Mueller
Post by Kay Martinen
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.
Post by Marcel Mueller
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!
Post by Marcel Mueller
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Marcel Mueller
Post by Kay Martinen
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.
Post by Marcel Mueller
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).
Post by Marcel Mueller
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.
Post by Marcel Mueller
Post by Kay Martinen
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.
Post by Marcel Mueller
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
2017-05-03 07:41:46 UTC
Permalink
Post by Kay Martinen
Post by Marcel Mueller
Post by Kay Martinen
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]
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Kay Martinen
Post by Marcel Mueller
Post by Kay Martinen
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]
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Kay Martinen
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.
Post by Kay Martinen
Post by Marcel Mueller
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.
Post by Kay Martinen
Post by Marcel Mueller
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.
Post by Kay Martinen
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.
Post by Kay Martinen
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
2017-05-03 17:46:01 UTC
Permalink
Post by Kay Martinen
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
2017-05-03 22:23:24 UTC
Permalink
Post by Marc Haber
Post by Kay Martinen
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.
Post by Marc Haber
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
Lesen Sie weiter auf narkive:
Loading...