Umzug von Hyper-V nach VMware Server

PhreakShow

Enthusiast
Thread Starter
Mitglied seit
02.08.2004
Beiträge
1.113
Moin Leute.
Ich beschreibe mal wie meine Serverumgebung atm aussieht:

AMD 4050e, 4GB Ram, 2x 320GB Raid1 fürs System und 4x 750GB Raid5 für Daten (alle sechs Platten an einem Promise TX8654).
Darauf läuft ein Server 2008 R2, mit der installierten Hyper-V Rolle. Das Datenraid ist als Netzlaufwerk auf Clients eingebunden.

Als virtuelle Maschine läuft ein Server 2008 R2 mit DC, DNS, DHCP, Exchange 2007, WDS, WINS, all dem netten Spielkram eben. Einziger User bin ich, mit mehreren Notebooks, Desktoprechner, Handy.
Die VM hat den Vorteil, dass ich mit Snapshots immer mal wieder was ausprobieren kann ohne mir gleich das ganze System zu killen.
Backups werden über LAN und einen Client auf ne eSata-Platte gemacht.

Der Grund für den Umzug ist, dass ich mit dem Hyper-V unzufrieden bin. Ich probiere gern mehrere VMs auf dem Server aus, weil meine Clients alle nur SSDs haben und daher der Platz begrenzt ist. Mit Hyper-V gibts keine USB-Unterstützung, und bis zum Installieren der Gasterweiterungen gibts auch keine Maus.

Außerdem ist die Performance eher mau, weil Host und Gast auf demselben Raid1 laufen.

Neue Hardware ist auch besorgt: i3-540, 8GB Ram, H55 Board

Mein Plan wäre nun folgender: Als Host-OS Windows 7, darauf VMware Server. Beides läuft auf einer einzelnen 2,5" Platte.
Im VMWare Server ist das Raid1 als Storage definiert, darauf laufen dann die VMs (Exchange + Test-VM). Das Datenraid wird unter Win7 freigegeben oder über Software eines Drittanbieters als iSCSI Target bereit gestellt.

Die Frage ist jetzt, wie krieg ich die VM von Hyper-V zu VMware Server migiert, und zwar so dass sie auf dem physikalischen Raid1 läuft, ohne den Umweg über eine vmd-Datei?

Die zweite Frage ist, was sagt ihr zu dem Plan.

Gruß Phreak
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Mir ist nicht bekannt, das eine VM ohne virtuelle Festplatte laufen kann.
 
Ich kenn das von VMware Workstation, dass man der VM entweder eine vmd-Datei geben kann oder direkten Zugriff auf eine Festplatte. Letzteres wollte ich verweden, weiß aber nicht obs das beim Server auch gibt.
 
VMWare Converter in der VM auf dem HyperVisor installieren und live rüber schupsen lassen?
Wäre denke ich, die einfachste Methode.
 
Ich würds auch über den Converter probieren! Da kriegt man echt einiges mit hin.
 
Hm, ja den Converter kenn ich, wusste aber ned dass der VMware Server generell kein HDD-Passthrough kann. Daher hab ich den Converter jetzt benutzt.

Sonstige Bemerkungen zu dem Szenario? Vor allem in bezug auf die Platten...
 
Also das mit den Platten passt, habe das mehr oder weniger genau so bei mir laufen:

1x 80GB System (2008 R2 + VMware Workstation)
2x 300GB SAS RAID1 VMware Storage (iSCSI)
9x 1TB RAID5 Storage

Habe Windows Server 2008 genommen, damit ich auch mal ein Hyper-V Server installieren kann, falls ich das brauch (USB Support via Fabula Tech USB-Server). VMware Workstation, weil es einfach viel mehr kann als die Server-Version.
Das RAID1 wird als Storage für die lokalen VMs sowie für ESXi's genutzt, die bei Bedarf gestartet werden.
RAID5 dient nur als Datengrab via SMB
 
So, ich hab nun umgestellt. Als Host-OS läuft Win7, weil das Vorteile in Bezug auf Software hat (Acronis Backup & Recovery lässt sich zB in der Workstation-Variante betreiben).
Darauf aufgesetzt ist der VMWare Server 2.0, welcher ja glücklicherweise kostenlos ist und alles mitbringt was ich so brauche.
Der Netzwerkdurchsatz von meinen Clients auf den Win7 Host liegt bei 115MB/s (mit NetIO gemessen) und ist daher fast an der Grenze des theoretisch möglichen.
Das Datenraid ist im Moment noch als Netzlaufwerk eingebunden, da möchte ich aber eigentlich zu iSCSI gehen.

Ich möchte iSCSI Cake verwenden um das Datenraid auf den Clients einzubinden. Meine Frage ist nun ob das so klappt wie ichs mir vorstell.
Ich installiere den iSCSI Cake Server auf dem Win7, gebe als Laufwerk die Datenpartition an und binde das Volume auf den Win7-Clients mit dem iSCSI-Initiator ein.
Gleichzeitig soll das Datenraid aber lokal vom Server aus benutzbar bleiben.
 
Für das Vorhaben brauchst du ein Dateisystem auf dem Daten Array, was mehrere gleichzeitige Zugriffe erlaubt. NTFS kann das so nicht. Sprich wenn du das physische Array per NTFS formatierst und dann über eine iSCSI Software freigibst, so wird das wohl nicht funktionieren...

Mit Linux und Co. müsste man sowas aber machen können... Die Frage ist, warum muss es für ein Daten Array zwingend iSCSI sein?
Das macht sich auch als Netzlaufwerk sehr gut...
 
Ich dachte dass ich über iSCSI mehr Datendurchsatz habe als über ne Freigabe.
Der Plan ist nämlich, dass ich Spiele nicht mehr lokal sondern übers LAN starte weil mir der Platz auf meiner SSD ausgeht :)
 
Ein nerviges Detail ist mir grad aufgefallen:
Der Netzwerkzugriff über SMB ist saulahm, vom Host-Win7 auf den Gast-2008R2.
Mit NetIO krieg ich da maximal 200kB/s hin. In Gegenrichtung sinds immerhin 50MB/s.
Woran könnte das denn liegen?
 
Hi,

ich habe ein sehr ähnliches Setup wie du und bin mit Hyper-V eigentlich rundum zufrieden:

Der Grund für den Umzug ist, dass ich mit dem Hyper-V unzufrieden bin. Ich probiere gern mehrere VMs auf dem Server aus, weil meine Clients alle nur SSDs haben und daher der Platz begrenzt ist. Mit Hyper-V gibts keine USB-Unterstützung, und bis zum Installieren der Gasterweiterungen gibts auch keine Maus.

Das kann ich so nicht bestätigen. Wenn ich mit dem Hyper-V Manage mich zu einer VM connecte kann ich immer die Maus benutzen? Meistens gehe ich diesen Umweg aber nicht sondern verbinde mich zu den VMs direkt per RDP.
 
Ein nerviges Detail ist mir grad aufgefallen:
Der Netzwerkzugriff über SMB ist saulahm, vom Host-Win7 auf den Gast-2008R2.
Mit NetIO krieg ich da maximal 200kB/s hin. In Gegenrichtung sinds immerhin 50MB/s.
Woran könnte das denn liegen?

Das kann eigentlich nur eine Konfigurationssache sein...
Eventuell mal mit virtuellen Netzwerkadaptern probieren. Sprich neben dem physischen Adapter im Bridge Mode einen virtuellen Adapter zur Kommunikation intern von Host zu VM verwenden. Dieses virtuelle LAN dann in einem anderen Subnetz definieren und mit statischen Routen oder Hosteinträgen arbeiten... (damit auch zwingend für die interne Kommunikation der virtuelle LAN Weg genommen wird)


Übrigens, der Vorteil an iSCSI ist einfach, das du das Volume direkt in die Maschine mountest und es sich wie eine physische HDD verhält. Sprich das OS sieht so nicht, das es nicht lokal ist. Das heist, du kannst auf diesem Volume dann auch Stressfrei Programme installieren usw.
Nachteil ist einfach, iSCSI ist schön und gut, aber für mehrere PCs gleichzeitig auf ein und das selbe Volume brauchst du ein Dateisystem, was gleichzeitige Zugriffe zulässt. Und das kann NTFS so nicht... Das heist wiederum, du kannst das iSCSI Volume immer nur von einer einzigen Maschine aus mounten, ebenso sollte der Zugriff vom Host auf dieses Volume dann nicht funktionieren. Bzw. es kann auch sein, das eine Art Container angelegt wird, welcher dann quasi das Volume beinhaltet. So hat der Host gar keinen Zugriff. Außer man mountet es dort als iSCSI Volume.
Geschwindigkeitstechnisch nimmt sich das nix... Aber ich kann dir jetzt schon sagen, Performancetechnisch ist das alles kontraproduktiv. Vor allem wenn du sagst, du willst Game darauf installieren... Es macht wenig Sinn hier das ganze auszulagern, wenn die Games sowieso einen gewissen Teil ihrer Daten in der Registry sowie auf dem Systemlaufwerk ablegen nutzt dir das auslagern des reinen Gameordners sogut wie gar nix.
 
Zuletzt bearbeitet:
Der Nutzen wäre halt eine immense Platzersparnis. Aber das kann ich in Ruhe testen wenn ansonsten alles eingeschwungen läuft.

Das Problem mit der unterirdisch schlechten Netzwerkperformance zwischen Hos und Gast konnte ich übringens lösen, "Abladung großer Übertragung V2 IPv4" am Netzwerkadapter des Hosts war schuld an der Sache.
Wenn man den Eintrag im Gerätemanager deaktiviert, funktionierts plötzlich...
 
Macht das denn wirklich Sinn von Hyper-V nach VMWare Server 2 "umzuziehen" ?

Ich nutze derzeit VMWare Server 2 um mehrere virtuelle Maschinen zu hosten aber spiele mit dem Gedanken auf Hyper-V umzusteigen. Der Grund ist der, weil der Support vom VMWare Server 2 ausläuft bzw. auch keine neuen Updates etc. erscheinen sollen.
Wie das mit der unterstützung von zukünftigen Betriebssystemen aussieht kann ja auch keiner sagen soviel ich weiss.

Das Webinterface ist leider auch recht lahm, auch wenn ich mit dem VMWare Infrastructure Client auf die VMWare Server Instanz zugreife.
 
Ich finde auch, dass es wenig Sinn macht, von Hyper-V nach VMWare Server zu wechseln. Das ist technisch ein arger Rückschritt. Ich sehe eigentlich nur zwei Optionen:

1. Irgendein Windows, wenn ein Basis-Windows benötigt wird + VMWare Workstation.
Am Besten XP, da bleibt viel Leistung für die VM's übrig.

oder aber
2. ein richtiger Type-1 Barebone Hypervisor, wenn maximale Performance mit Serveranwendungen gefragt ist; also in diesem Fall VMWare esxi 4.1

Von Hyper-V habe ich mich vor zwei Jahren verabschiedet und bin zum esxi gewechselt: Hauptgrund waren die wöchentlichen "wichtigen" Security-Updates mit Neustart - ein Unding für einen Server, der andere Server hosten soll.

Die kostenlose esxi Version ist zwar arg kastriert was den Zugriff darauf angeht (move, copy,backup). Sobald man einen extra NFS-SAN Storage hat, ist es aber perfekt.

Ich integriere seit Neuem daher einen NexentaCore/Solaris* +napp-it ZFS-SAN-Server virtuell als erstes Gast-OS und speichere darauf meine VM's auf dessen NFS Freigabe. Damit habe ich eine kostenlose und ziemlich perfekte Lösung in einem Rechner - vor allem wegen der ZFS Snapshots (ein Traum verglichen mit allem anderem) und weil ich die VM's in diesem Fall einfach per SMB sichern oder klonen kann + einen perfekten SMB/AFP Fileserver. (Virtual Server + Storage-Server + Virtual Switch LAN/SAN/Vlan, All-In-One)

Gea
 
Zuletzt bearbeitet:
Warum wöchentliche Updates?
MS bringt die Updates idR jeweils am zweiten Dienstag des Monats raus... Einmal im Monat Updaten halte ich nun nicht für äußerst kritisch.
Mal ganz davon ab ist es besser Sicherheitslücken zu schließen als diese offen über Wochen/Monate stehen zu lassen.

Ich denke sogar, Mircosoft Betriebssysteme der neuesten Generation sind weit sicherer als alles andere, die ganzen Patches mögen zwar das Gegenteil bescheinigen, aber für kein anderes Betriebssystem werden so schnell Sicherheitslücken gefunden und gleichsam von MS auch geschlossen... ;)

Übrigens, für Wartungen am Host sind so Sachen ala VMotion Gold wert. Einfach die VMs vom einen Host auf einen anderen schnieben, Unterbrechungsfrei und ohne merklichen Unterschied für den User, Host patchen und zurück schieben ;)
Der Hyper-V sollte sowas glaube ich auch können...
 
ich habe da mal einen netten Vergleich gelesen.

OSX ist wie ein Bauernhof in der Wildnis, alle Türen sind offen und es wird nicht gestohlen.
Viele nutzen OSX genau deswegen.

Windows ist dagegen wie die Tankstelle mitten im schlimmsten Getto. Wird ständig angegriffen, wird ständig sicherer und dennoch passiert dauernd etwas.


Ich halte Windows inzwischen schon für relativ sicher, es ist aber konzeptionell falsch, ein Full Featured OS mit Mediaplayer und Browser und Flash und tausend anderen Sachen als Basis für einen virtuellen Server zu nehmen - da hilft auch die CLI Version nicht wirklich - verglichen mit dem Minimalansatz von XEN oder esxi gibt es einfach hundertmal soviele Angriffspunkte.

Ich möchte eben nicht wegen der dauernden Patcherei alle virtuellen Server umziehen. Damit löse ich nur Probleme, die es ohne Windows gar nicht gäbe. Ich möchte lieber etwas dass konzeptionell so sicher/ minimalistisch ist, dass ich das nicht brauche, oder zumindest nur sehr selten.
 
Zuletzt bearbeitet:
Ich halte Windows inzwischen schon für relativ sicher, es ist aber konzeptionell falsch, ein Full Featured OS mit Mediaplayer und Browser und Flash und tausend anderen Sachen als Basis für einen virtuellen Server zu nehmen - da hilft auch die CLI Version nicht wirklich - verglichen mit dem Minimalansatz von XEN oder esxi gibt es einfach hundertmal soviele Angriffspunkte.

Wofür gibt es denn die Core-Varianten vom Windows Server?^^
 
Was meinst du wofür das CLI in seinem Post steht? ;)

ESX(i) ist einfach, zusammen XEN die Plattform fürs Virtualisieren.
 
man müsste mal schauen, was an Patches beispielsweise für den schon zwei Jahre erhältlichen 2008 (non R2) als Core in der Basisversion ohne weitere Rollen erhältlich ist...

So viel wird das denke ich nicht sein. Und wie gesagt, wenn man die Windows VMs patcht, kann man auch gleich den Host mit patchen... Das macht den Braten nicht fett.

Ich bin aber auch der Meinung für echte virtualisierung eher in Richtung ESX oder Xen zu gehen, wobei mir der Xen so nicht ganz zusagt, mit meinen Tests wirkt das Produkt sehr unausgereift. Das ist aber sicher auch Ansichtssache/Gewöhnungssache.
 
Da Hyper-V im Grunde Xen for Windows ist, wäre es technisch schon geeignet, wenn es nicht alle Angriffspotentiale von Windows geerbt hätte.

Wir haben Virtualisierung mit Hyper-V begonnen und wären auch dabei geblieben, wenn es das Patch Problem nicht gegegen hätte und nicht die alte MS Krankheit alles mit allem zu vermauscheln. Als wir das erste Mal versucht haben eine virtuelle Maschine ohne sie zuvor zu exportieren von a nach b zu verschieben und dabei voll auf die Nase gefallen sind (weiss nicht ob das zwischenzeitlich anders ist) und gesehen haben, dass das bei esxi nur eine Rückfrage zur Folge hat, ob wir diese VM verschoben oder kopiert (neue Maschine ID) hätten, war die Sache klar - weg von Hyper-V.

Wobei mir XEN pur auch zu anstrengend wäre - ich würde da auch eher auf XENServer setzen - der kann in der Kostenlosversion auch viel mehr als ein Gratis esxi - eigentlich alles was man braucht - aber: leider kein pci-passthrough, was ich aber unbedingt brauche.

Wobei ich noch erwähnen möchte, dass ich OSS oder freie Software nach Möglichkeit bevorzuge - sofern es funktionell meine Bedürfnisse abdeckt. Zudem lautet meine Maxime: keep it as simple as possible!
 
Zuletzt bearbeitet:
So schlimm ist Windows eigentlich gar nicht ;)

Wie oben schon erwähnt, die Patcherei kommt ja eher daher, weil eben so viele Leute Windows nutzen und dementsprechend auch viele potentielle Angreifer sich an Sicherheitslücken versuchen.
Wäre die ganze Sache in Richtung MacOS oder Linux/Unix verschoben, hätten wir das gleiche Problem in Bund nur eben mit anderer Software.

Auch sollte man Microsoft noch zugute halten, das die aktuelle Hyper-V Umsetzung ja immernoch die quasi erste Version ist. Schaut man sich bei den anderen mal um, so haben die viel mehr Erfahrungen in diesem Bereich.


Was hattet ihr eigentlich im Testeinsatz?
Den echten Hyper-V oder einen 2008er Server mit Hyper-V Rolle?
 
So schlimm ist Windows eigentlich gar nicht ;)

Wie oben schon erwähnt, die Patcherei kommt ja eher daher, weil eben so viele Leute Windows nutzen und dementsprechend auch viele potentielle Angreifer sich an Sicherheitslücken versuchen.
Wäre die ganze Sache in Richtung MacOS oder Linux/Unix verschoben, hätten wir das gleiche Problem in Bund nur eben mit anderer Software.

Auch sollte man Microsoft noch zugute halten, das die aktuelle Hyper-V Umsetzung ja immernoch die quasi erste Version ist. Schaut man sich bei den anderen mal um, so haben die viel mehr Erfahrungen in diesem Bereich.


Was hattet ihr eigentlich im Testeinsatz?
Den echten Hyper-V oder einen 2008er Server mit Hyper-V Rolle?

Server 2008 mit Hyper-V Rolle - from the first beta zwei Jahre lang. - wobei ich nicht sehe, was da ncht echt sein sollte :-)) und nicht im Testeinsatz - unsere AD Server, Terminalserver und Renderserver liefen darauf virtuell.

Und natürlich ist OSX (Gott bewahre mich vor dem Tag, an dem das massiv angegriffen wird) oder Linux nicht besser, eine Minimal-Barbone-Installation von esxi oder XEN (ist ja auch Linux) hat einfach nur erheblich weniger Angriffsoptionen da es nichts mitbringt ausser dem was für diese Spezialaufgabe nötig wäre, während Windows (CLI=fast) immer alles mitbringt, was MS so anbietet - auch wenn man viele Rollen nicht nutzt

- Für mich gilt halt: small is beautifull- vor allem bei Servern, ganz im Gegensatz zum MS-Ansatz: Ich kann alles.

Vmware hat mal damit geworben, dass der der Kern von esxi nur 32 MB groß wäre - keine Ahnung wieviel das jetzt ist. Sicher ist, dass es mit 1,5 GB läuft wobei der meiste Platz für die Windows Management Software zum Downloaden benötigt wird.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh