Nach Migration von VMware zu PVE: SLES12SP4 Reihenfolge der Platten (Linux) undurchsichtig

[udo]

Hallo Udo, ich hab zuletzt jetzt nur die eine Platte eingebunden. Keine weitere. Und ich bin 100% sicher: die einzige Platte mit den 2 Partitionen ist die richtige. Auch die UUID passt zu dieser Partition.

und die Platte ist auch als scsi0 in der config definiert?!, weil dann hd0,msdos2 und die uuid passen sollte.
Hast Du im Grub-Menu noch die Möglichkeit eines anderen systemstart (debug/sicher/usw)?

 

[Falk R.]

Hi, ich dachte zuerst, ich bin auf dem richtigen Pfad, immerhin sucht er jetzt nur noch nach seiner UUID, aber weiterhin vergeblich.
Das meiste, was ich gesucht, gefunden, angepasst habe, hab ich in dem info.txt stehen. Dazu noch /etc/default/grub als scrnsht und den unendlichen suchvorgang. Ok, es wird nicht die ganze UUID gelistet, kann sich da iwo ein Sonderzeichen eingeschlichen haben?
Das ist doch blöd.
Ich werd heute abends mal die originale VM runterfahren und kopieren und hoffen, dass sich dadurch etwas verbessert.

Hi, wenn die originale vSphere VM noch existiert, wie migrierst du denn? Ich habe schon sehr viele VMs von vSphere nach PVE umgezogen, da gab es bei mir noch nie Probleme. Da war alles von FreeBSD über SLES, CentOS, Debian bis alle Windows Versionen dabei.
Kann ja nicht sein, dass sich deine VM nicht migrieren lässt.

 

[pmdk]

und die Platte ist auch als scsi0 in der config definiert?!, weil dann hd0,msdos2 und die uuid passen sollte.
Hast Du im Grub-Menu noch die Möglichkeit eines anderen systemstart (debug/sicher/usw)?

Hi, grub.cfg anbei; die Zuweisung scsi3 hab ich nicht erfunden.

 

[pmdk]

Hi, wenn die originale vSphere VM noch existiert, wie migrierst du denn? Ich habe schon sehr viele VMs von vSphere nach PVE umgezogen, da gab es bei mir noch nie Probleme. Da war alles von FreeBSD über SLES, CentOS, Debian bis alle Windows Versionen dabei.
Kann ja nicht sein, dass sich deine VM nicht migrieren lässt.

Ich habe bisher immer mit den vSphere-Clone-Sicherungen gearbeitet. Bis auf diese blöde Plattenzuweisung scheint ja auch alles zu funktionieren.
Wie migrierst Du denn so?
Ich hab es auch schon als Vorlage-Clone versucht, da ist aber IMHO keine Unterschied festzustellen. OVF-Export ist nur im ausgeschalteten Zustand möglich. Das werde ich heute abends probieren.

 

[Falk R.]

Ich nutze in der Regel 2 Methoden:
Methode1:
1. VMDK auf NFS Datastore migrieren und dann VM runter fahren.
2. NFS Mount an PVE und anhängen der VMDK an neue PVE VM
3. Snapshot der VM erzeugen und dann VM starten
in der Regel läuft alles und der Snapshot wird gelöscht vor dem migrieren der Disk auf Zieldatastore.

Methode2:
1. Veeam Backup ziehen (für Test geht auch ein älteres Backup) und nach shutdown der original VM noch mal ein Increment
2. Instant Restore an ESXi starten
3. NFS Mount des ESXi auf PVE übernehmen.
4. VMDK an VM hängen und starten.
5. Migration auf Zielstorage

Somit habe ich immer einen Konsistenten Zustand und es wurde nix durch eine 3rd Party Software verändert.

 

[pmdk]

Ich nutze in der Regel 2 Methoden:
Methode1:
1. VMDK auf NFS Datastore migrieren und dann VM runter fahren.
2. NFS Mount an PVE und anhängen der VMDK an neue PVE VM
3. Snapshot der VM erzeugen und dann VM starten
in der Regel läuft alles und der Snapshot wird gelöscht vor dem migrieren der Disk auf Zieldatastore.

"und anhängen der VMDK an neue PVE VM" - kein Import?
Bei dieser Maschine ist es wohl etwas verkorkst, weil 5 Platten dran hängen mit 6 partitionen und / liegt nicht auf der ersten Platte, sondern der dritten.

 

[Falk R.]

"und anhängen der VMDK an neue PVE VM" - kein Import?
Bei dieser Maschine ist es wohl etwas verkorkst, weil 5 Platten dran hängen mit 6 partitionen und / liegt nicht auf der ersten Platte, sondern der dritten.

Beim migrieren auf das zielstorage werden die Disks automatisch umgewandelt.
Bei mehreren Disks, hänge ich die in gleicher Reihenfolge wie in der vSphere VM ein. Bei Linux gab es bisher nie Probleme.

 

[udo]

Hi, grub.cfg anbei; die Zuweisung scsi3 hab ich nicht erfunden.

Du kannst entweder die Disk über die gui detachen und dann erneut hinzufügen. Dann ist es scsi0 (wenn es die einzige disk ist).
Dann must Du natürlich die disk auch wieder als boot-device aussuchen.
Oder einfach kurz zu Fuß editieren ( vi /etc/pve/qemu-server/103.conf ) - darf halt nur eine Disk scsi0 sein. Auch dann die Boot-disk aktualisieren.
Ob das eine Änderung macht, weiss ich nicht. Kann auf jeden Fall nicht schaden.

Udo

 

[pmdk]

Das Glück ist mir nicht hold. Gestern diesen OVF-Vorlage-exportieren mit ausgeschalteter VMware-VM.
Heute wollte ich nach Anleitung importieren: https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE#VMware_vCenter_Settings

root@wkst01:/mnt/pve/nas15.10G/venus# qm importovf 119 ./support-venus.ovf SSD-Pool1
qemu-img: Could not open '/mnt/pve/nas15.10G/venus/support-venus-4.vmdk': Invalid footer
could not parse qemu-img info command output for '/mnt/pve/nas15.10G/venus/support-venus-4.vmdk' - malformed JSON string, neither tag, array, obj
ect, number, string or atom, at character offset 0 (before "(end of string)") at /usr/share/perl5/PVE/Storage/Plugin.pm line 946.
error parsing /mnt/pve/nas15.10G/venus/support-venus-4.vmdk, cannot determine file size
root@wkst01:/mnt/pve/nas15.10G/venus# ls -lh
total 35G
-rw------- 1 root root 309 Sep 6 22:31 nohup.out
-rw-r--r-- 1 1000 1000 16G Sep 6 20:04 support-venus-1.vmdk
-rw-r--r-- 1 1000 1000 4.5G Sep 6 19:02 support-venus-2.vmdk
-rw-r--r-- 1 1000 1000 3.9G Sep 6 18:48 support-venus-3.vmdk
-rw-r--r-- 1 1000 1000 3.8G Sep 6 18:47 support-venus-4.vmdk
-rw-r--r-- 1 1000 1000 7.2G Sep 6 18:59 support-venus-5.vmdk
-rw-r--r-- 1 1000 1000 8.5K Sep 6 18:34 support-venus-6.nvram
-rw-r--r-- 1 1000 1000 663 Sep 6 20:06 support-venus.mf
-rw-r--r-- 1 1000 1000 9.6K Sep 6 18:35 support-venus.ovf
Die Clone sind normalerweise so 80G groß, die Summe der Plattengrößen lt. vSphere: 180G, siehe scrnsht.

Na gut, da gibt es ja noch den Hinweis auf den Direktexport über das ovftool:
root@wkst01:/mnt/pve/nas15.10G# mkdir venus.ovf2
root@wkst01:/mnt/pve/nas15.10G# cd venus.ovf2/
root@wkst01:/mnt/pve/nas15.10G/venus.ovf2# ovftool vi://root@10.56.12.88/support-venus .
Enter login information for source vi://10.56.12.88/
Username: root
Password: ***********
Opening VI source: vi://root@10.56.12.88:443/support-venus
Error: Message is: Received SOAP response fault from [<SSL(<io_obj p:0x00007fb314019878, h:7, <TCP '10.56.17.201 : 40022'>, <TCP '10.56.12.88 : 4
43'>>), /sdk>]: exportVm
The operation is not allowed in the current state.,
Fault cause: vim.fault.InvalidState
Completed with errors

Das war übrigens ganz viel früher mal ein SLES11.
Ich glaub, ich bau besser ne neue VM. pDNS und otrs. Mit debian.

 

[Falk R.]

Die Clone sind normalerweise so 80G groß, die Summe der Plattengrößen lt. vSphere: 180G, siehe scrnsht.

Das ist zu erwarten. vSphere zeigt dir die Größe der VMDKs an und im OVF Export sind die VMDK thin provisioned, damit man nicht so viele Nullen kopieren muss.
Wenn du die VMDKs einfach kopierst oder aus einem Backup wiederherstellst, einfach mal die VMDKs direkt an die VM hängen ohne Konvertierung.
Wenn das nicht funktioniert, hast du ein echtes Problem mit der Ursprungs VM.

 

[pmdk]

Das ist zu erwarten. vSphere zeigt dir die Größe der VMDKs an und im OVF Export sind die VMDK thin provisioned, damit man nicht so viele Nullen kopieren muss.
Wenn du die VMDKs einfach kopierst oder aus einem Backup wiederherstellst, einfach mal die VMDKs direkt an die VM hängen ohne Konvertierung.
Wenn das nicht funktioniert, hast du ein echtes Problem mit der Ursprungs VM.

Wie hänge ich eine vmdk direkt, ohne Konvertierung, an eine VM?
So wie im scrnsht lege ich ja nur ne neue an als vmdk.

 

[Falk R.]

Wenn du eine VMDK auf einem Datastore liegen hast, kannst du per qm set die VMDK einhängen, wie sonst auch eine physikalische Disk.