Windows-Gast mounten/umziehen

[thilo]

Hallo zusammen,

wenn man domUs umzieht, mountet man den Snapshot, erstellt ein tar Archiv, entpackt es auf dem neuen Server und gut ist.

Wie aber geht das mit hvm-guests? Da ist die Partition ja nur emuliert, wenn ich den Snapshot eines Windows-Gasts oder diesen selber mounten will (z.B. mit -t ntfs), gibt es da natürlich eine Fehlermeldung ("wrong fs type etc...").

Aber das geht doch, oder?

Besten Gruß
Thilo

[daemotron]

Was benutzt Du denn als "Unterlage" für die DomU's - LVM-Volumes, "echte" Partitionen oder Image-Dateien? Bei einem Linux-fremden Dateisystem (egal ob NTFS, UFS, HPFS) würde ich eher ein Image ziehen (per dd, z. B.) und dieses komprimieren. Wie's geht: http://blog.my-universe.com/archives/13 ... spipe.html (die Pipe zu aespipe und ncftp sind natürlich optional ;))

[thilo]

wow, das ging ja schnell!

Ich benutze LVM

An dd hatte ich auch schon gedacht.
Einfach dd? In etwa so?

Code: Select all

dd if=/dev/vg/winxp of=winxp.img

Werd ich mal testen
Das wäre ja einfach...

Thilo

[daemotron]

So in etwa würde ich es machen. Allerdings musst Du Dir auch die genauen "Geometriedaten" des LVM Volume und der dazugehörigen Volume Group notieren - wenn die auf einer anderen Maschine nicht übereinstimmen (PE Size, Stripe Size, Größe des Volume), kann das mit dem Image höllisch schief gehen.

[thilo]

Danke für den Hinweis, ist klar.

Ich werde wohl erst nächste Woche dazu kommen. Ich berichte dann.

Besten Gruß
Thilo

[thilo]

So, nach dem Motto besser spät als gar nicht... :)

Das hat ohne Fehlermeldung geklappt, aber wenn ich den Windows-Gast starte, kommt das Windows-Setup von der CD (ist als CD-LW in der config).
Ein fixboot geht nicht, fixmbr schon, aber leider ohne Erfolg.

Was läuft da schief?

Thilo

[danu]

Ein WIndows System in ein Tar Archiv packen, da kann IMHO schon einiges
schief laufen. Ausserdem müsste das neue dd if=/dev/vg/winxp vor dem
Entpacken des Tar Archives wieder mit NTFS formatiert sein.

Ich habe es so gemacht:
/dev/vg/winxp gemountet
darauf
dd if=/dev/zero of=/mnt/winxp.img bs=1024k count=<Grösse>

[thilo]

Ich habe es so gemacht:
/dev/vg/winxp gemountet

Das LV mounten? Genau das ging bei mir ja nicht, siehe erstes Posting:

Wie aber geht das mit hvm-guests? Da ist die Partition ja nur emuliert, wenn ich den Snapshot eines Windows-Gasts oder diesen selber mounten will (z.B. mit -t ntfs), gibt es da natürlich eine Fehlermeldung ("wrong fs type etc...")

[Joe User]

Ein WIndows System in ein Tar Archiv packen, da kann IMHO schon einiges schief laufen.

Bei FAT32 Nichts, bei NTFS Alles...

[danu]

Das LV zuerst formatieren:
mkfs.ext3 /dev/vg/winxp

dann
mount /dev/vg/winxp /mnt

Das sollte schon funktionieren, sonst ist bei der Installation von LVM etwas schief gelaufen.

[daemotron]

Interessant... und wie betreibst Du WinXP auf ext3?

[thilo]

...das interessiert mich auch brennend!

[danu]

und wie betreibst Du WinXP auf ext3

Natürlich nicht.

Ich formatiere das LV mit ext3, damit ich es mounten kann.

Ich bin davon ausgegangen, dass auch bei einem snapshot
das ursprüngliche winxp.img erhalten bleiben muss.

Ich wollte eigendlich sagen, wenn du

dd if=/dev/vg/winxp of=winxp.img

machst, beisst sich der Hund selber in den Schwanz.
Mit dd if=/dev/zero of=winxp.img auf der meinetwegen mit ext3 formatierten und gemounteten
LV hättest du eigendlich, was du wolltest. Mit winxp.img hättest du eine Datei, die sich
dann auch so verhält.

Was man alles mounten kann, und was nicht, darüber bin ich zuwenig informiert. Mit FAT32
hats noch funktioniert, mit NTFS scheinbar weniger :D/

[daemotron]

Ich glaub, da liegt ein Mißverständnis vor. Thilo hat ein LVM-Volume mit NTFS, auf dem WinXP installiert ist, da gibt es keine Image-Dateien mehr dazwischen (das wäre ja auch etwas hirnlos, da mehrere Abstraktionsschichten I/O unerträglich langsam machen).

[danu]

Hier ist kein Missverständnis meinerseits. Ich habe hier einfach meinen Lösungsvorschlag dargelegt. Was macht
die Virtualisierung für einen Sinn, wenn ich zuerst einen halben Tag lang die Plattengeometrie berechnen muss, um nachher
einzugestehen, dass es trotzdem nicht funktioniert ? [-X

(das wäre ja auch etwas hirnlos, da mehrere Abstraktionsschichten I/O unerträglich langsam machen).

...vor 10 Jahren hätte ich diesem Argument zugestimmt. Aber mit der heutigen Hardware kann man die paar Prozente Einbusse in der Performence vernachlässigen.

[daemotron]

Hier ist kein Missverständnis meinerseits. Ich habe hier einfach meinen Lösungsvorschlag dargelegt. Was macht
die Virtualisierung für einen Sinn, wenn ich zuerst einen halben Tag lang die Plattengeometrie berechnen muss, um nachher
einzugestehen, dass es trotzdem nicht funktioniert ? [-X

Images sind vielleicht portabler, waren aber nicht Gegenstand der Frage des OP. Wenn Du gerne Image-Files nutzt, wird Dich keiner davon abhalten. Wenn man aber schon Image Files nutzt, sollte man nicht noch eine weitere Abstraktionsschicht à là LVM drunterpacken, oder man darf sich halt nicht wundern, wenn einem alle Optimierungs-Strategien nicht mehr helfen, die Dienste auch performant ans Rennen zu kriegen.

(das wäre ja auch etwas hirnlos, da mehrere Abstraktionsschichten I/O unerträglich langsam machen).

...vor 10 Jahren hätte ich diesem Argument zugestimmt. Aber mit der heutigen Hardware kann man die paar Prozente Einbusse in der Performence vernachlässigen.

Disk I/O ist auch ohne Abstraktionsschichten schon in 99% aller Fälle das Nadelöhr, das sinnvolle Skalierung verhindert. Selbst SAS oder SATA2 sind im Verhältnis zu Quadcore-Prozessoren und Gigabytes an RAM unerträglich langsam. In den letzten 10 Jahren hat sich nur die Prozessorleistung merklich gesteigert, aber weder die Geschwindigkeit der Bussysteme für RAM noch die der Festspeicher-Subsysteme.

Um mal einen Extremfall zu konstruieren: Man lege auf einer Partition eine Volume Group an, in dieser wiederum ein Logical Volume. Auf selbigem erzeuge man ein Dateisystem, auf dem man wiederum eine Image-Datei erzeugt. In dieser Image-Datei lege man wieder ein Dateisystem an und installiere darauf eine Xen DomU mit einem MySQL Datenbank-Server. Nutzt dieser InnoDB, legt er selbst wieder eine Art Image-Datei an, in der er die Daten und Meta-Strukturen einsortiert. In diesem gar nicht so weit hergeholten Fall durchläuft ein Plattenzugriff sage und schreibe 5 Abstraktionsschichten: Device Mapper/LVM, Loopback, Datenbank-Storage-Engine und zwei Dateisysteme, die möglicherweise auch noch unterschiedliche Strategien bei der Anordnung der Daten auf dem Datenträger verfolgen.

Die Performance-Einbuße dürfte in solche einem Fall nicht nur mess- sondern auch spürbar sein und deutlich mehr als nur ein paar Prozent betragen. Und das, wo man sich bei Festspeichern einen Performance-Verlust kaum leisten kann...

[danu]

An dieser Stelle verweise ich mal auf das Xen User's Manual Xen v3.0
http://www.cl.cam.ac.uk/research/srg/ne ... dmes/user/
Was hier steht und auf Grund meiner eigenen Erfahrungen mit Xen (ca 5 Monate)
steht für mich fest, dass hvm keine physikalischen Blockdevices akzeptiert.

Ich habe die Frage schon verstanden und meine Antwort bleibt immer die
gleiche. hvm funktioniert nur mit Images, ob mir das gefällt oder nicht.

Auf LVM mag ich ebenfalls nicht mehr verzichten. Handling und Flexibilität hat in
unserem Geschäft eine hohe Priorität. Die Schreib/Lesegeschwindigkeit auf unseren
Servern liegt über den erwarteten Minimalanforderungen.

Hier geht es aber um Thilos Bemühungen, um zu dem von ihm gewünschten Ergebnis zu
kommen. Da wäre ich auch stark daran interessiert