Proxmox to Vmware Esxi 6.7u3

[pakuzaz]

Guten Morgen,

hat einer schonmal Proxmox Vms (Linux / Windows) nach VMware Esxi 6.7 importiert?

Der Vmware Converter geht leider nicht bei den Linux Kisten bekomm da immer eine Fehlermeldung das das neu Konfiguieren der Des. am schluss fehlschlägt.

Gruß

Pakuzaz

PS: Hier die fehlermeldung:

98% Fertig und dann = Error: Unable to reconfigure the destination virtual machine

FAILED: An error occurred during the conversion: ' * Looking for deps of module scsi_mod * * Looking for deps of module sd_mod * * Looking for deps of module mptspi * * Looking for deps of module mptscsih * * Looking for deps of module BusLogic * * Looking for deps of module ahci * * Looking for deps of module ide-disk * Cannot find in 4.9.0-11-amd64 module ide-disk * Looking for deps of module pcnet32 * fstab file is /mnt/p2v-src-root/etc/fstab * found root filesystem type as ext4 * Looking for deps of module ext4 * * found root filesystem mount options as errors=remount-ro * processed root filesystem mount options are errors=remount-ro * busybox mount options are * new root will not be mounted as read-only * printing module list: * /mnt/p2v-src-root/lib/modules/4.9.0-11-amd64/kernel/drivers/scsi/scsi_mod.ko * /mnt/p2v-src-root/lib/modules/4.9.0-11-amd64/kernel/drivers/scsi/sd_mod.ko * /mnt/p2v-src-root/lib/modules/4.9.0-11-amd64/kernel/drivers/message/fusion/mptspi.ko * /mnt/p2v-src-root/lib/modules/4.9.0-11-amd64/kernel/drivers/message/fusion/mptscsih.ko * /mnt/p2v-src-root/lib/modules/4.9.0-11-amd64/kernel/drivers/scsi/BusLogic.ko * /mnt/p2v-src-root/lib/modules/4.9.0-11-amd64/kernel/drivers/ata/ahci.ko * /mnt/p2v-src-root/lib/modules/4.9.0-11-amd64/kernel/drivers/net/ethernet/amd/pcnet32.ko * /mnt/p2v-src-root/lib/modules/4.9.0-11-amd64/kernel/fs/ext4/ext4.ko * got lib dir as lib64 * /mnt/p2v-src-root/lib64/libc.so.6 -> /mnt/p2v-src-root/tmp/initrd.f7OoUl/lib ERROR:
cannot find source file /mnt/p2v-src-root/lib64/libc.so.6 during file copy (return code 1)

[Dayworker]

Der Converter wird dir hier nur weiterhelfen, wenn die VM bereits auf dem ESXi liegt. Allerdings stehen bei 98% die Chancen bereits sehr gut, daß die VM lauffähig ist. Ansonsten kannst du die vDISK auch in Proxmox direkt in einer VMDK wandeln und legst hernach auf dem ESXi nur noch eine VM mit derselben Architektur wie unter Proxmox an.

[pakuzaz]

Hi,

das mit dem VMDK hab ich schon versucht da meckert der ESXI das dies nicht im richtigen Format wäre.

Und ja Sie starten haben aber massig fehler. Meine Idee wäre es nun per USB DISK und CloneZilla zu versuchen.

Gruß

Pakuzaz

PS. Wollte eigentlich eine Saubere lösung haben

[pakuzaz]

OK ich geb es mit ESXi auf es war mal ein gutes Produkt was schnell und einfach zu händeln war.

Auch hab ich die Erfahrung was die ältern Vmware produkte angeht aber so ein müll wie es nun ist... ohman

Gn8

Ich bleib erstmal bei Proxmox auch wenn das auch nicht das beste ist.

[~thc]

das mit dem VMDK hab ich schon versucht da meckert der ESXI das dies nicht im richtigen Format wäre

VMDK Formate gibt es leider einige und davon sind wiederum einige mit dem ESXi nicht kompatibel: https://sanbarrow.com/vmdk-basics.html

Und ja Sie starten haben aber massig fehler.

Da du durch den Hypervisor-Wechsel praktisch die gesamte virtuelle Hardware der VMs wechselst, ist das normal (Das ist dir wahrscheinlich bekannt).

Der Converter-Fehler beruht möglicherweise auf einer Eigenheit des vorhandenen Quell-Linux: Die für die InitRD notwendigen Kernel-Module zeigen eine Dependency für "/lib64/libc.so.6", die der Converter dann nicht finden kann (Defekter Link, ausgehängter Mountpunkt /usr/lib etc).

OK ich geb es mit ESXi auf es war mal ein gutes Produkt was schnell und einfach zu händeln war.
Auch hab ich die Erfahrung was die ältern Vmware produkte angeht aber so ein müll wie es nun ist... ohman

Das ist mir ein bisschen zu ungenau. "VMware Produkte" können ja auch die Workstation, der Player oder der alte Server (GSX) sein.

[pakuzaz]

HI,

früher war es gefüllt einfacher. Aber ich geb dir da recht ein Converter ist kein 100% Kopierer.

[Dayworker]

Der ESXi ist weiterhin gut handzuhaben, unterstützt jedoch inzwischen einige auf seinen Desktop-Produkten verwendete VMDK-Typen nicht mehr und genau das scheint beim vDISK-Export aus Proxmox das eigentliche Problem gewesen zu sein. Allerdings schwören ja Linuxer gerne auf ihre ba$h-Fähigkeiten und ein simples dd-Image hätte hier zumindest für ein lauffähiges Format gesorgt. Einfach ein Live-Linux oder notfalls DSL starten und das Image zurückspielen - falls man das Image nicht netcat direkt in eine VM "beamen" will - sind ja für Linuxer kein Hexenwerk. Die vorher zu erwartenden Lib-Probleme hätte man auch lösen können, denn die bei VMware genutzte HW baut weiterhin auf dem vom uralten Pentium3 bekannten Chipsatz BX440 auf.

[irix]

Also mein Admin "beamt" das von LiveCD zu LiveCD. Hinterher ein bisschen etc/fstab und grub Gefrickel und schwupps schon bootet es und funktioniert. Der bekommt nie einen 7B BSOD zu Gesicht

Gruss
Joerg

[pakuzaz]

Danke für eure Antworten,

ich bin langsam vom Proxmox Hype genervt und mit der Neusten Version ist es auch nicht mehr Performant.

Daher will ich die Tage mal schauen wie ich das ganze angehen. Vielleicht hat ja einer lust abends nebenher was dazu zuverdienen.

Gruß

Pakuzaz

[Dayworker]

Mein Rat wäre erstmal die Proxmox-vDISK in eine VMDK umzuwandeln (qemu-img convert disk.qcow2 disk.vmdk), dann im Desktop-Produkt Workstation-Pro eine VM mit gleichem OS/vDISK-Grösse anzulegen und der VM als neue vDISK zu verkaufen. Wenn das erstmal läuft, würde ich mich um die Netzwerkgeschichte kümmern, die sich bei Desktop und Server nur geringfügig unterscheiden. Lediglich die farbigen Teile sind wirklich unterschiedlich, werden aber vom jeweils anderen Produkt ignoriert und können daher in der VMX-Datei verbleiben. Nur so als Hinweis, eine VMX-Datei ist eine reine ASCII-Datei und darf keinerlei Formatierungen enthalten oder sie wird ungültig.

ethernet0.addressType = "generated"
ethernet0.connectionType = "bridged"
ethernet0.generatedAddress = "00:0c:29:08:52:45"
ethernet0.generatedAddressOffset = "0"
ethernet0.networkName = "VMnet0"
ethernet0.pciSlotNumber = "32"
ethernet0.present = "TRUE"
ethernet0.virtualDev = "vmxnet3"
ethernet0.vnet = "VMnet0"

Läuft das in der Workstation, würde ich auf dem ESXi eine neue Portgruppe mit dem Namen VMnet0 anlegen. Dann sollte die VM auch auf dem ESXi ins Netzwerk kommen. Abschließend kann man dann mit der Workstation-Pro die VM auf den ESXi hochladen und bekommt die vDISK auch gleich in ein dem ESXi bekanntes vDISK-Format gewandelt. Es macht also immer Sinn, die System-vDISK eines potentiellen Gastes vorher auf eine erträgliche Grösse zu schrumpfen. Die Daten-vDISK würde ich auf dem Ziel-Virtualisierer direkt neu anlegen und dann vom Gast aus über Netzwerk kopieren. Das dürfte schneller gehen, als erst noch mit irgendwelchen Images rumzuhantieren.

[pakuzaz]

Danke für deine Erklärung .

Auch wenn ich die Standart Antwort schon kenne aber ich hätte noch paar alte Blade Server der Generation 7/8 von HP hier liegen mit 128GB Ram. Nur der CPU läuft unter der neuen ESXi Version nicht mehr. Soll ich lieber das ganze Verkaufen oder gibt es eine Möglichkeit diese CPU Prüfung zu übergehen / alte Version einsetzten und fertig?

Alte Version wäre 5.5 oder 6.0 wobei ich die Webgui uns so eh nicht benötige.

[Dayworker]

Auch wenn die jetzt bei dir rumliegen, würde ich die nie wieder einsetzen. Die Knackpunkte dabei für mich wären Bladeserver und dann die alten Generationen 7 und 8. HPE unterstützt meines Wissens maximal 2 Generationen zurück und HPE ist aktuell schon länger bei der 10. Platz- und Energieverbrauch (Lüfterlärm) ist deine Baustelle, aber selbst Intel fixt nicht alle CPU-Reihen gegen Spectre/Meltdown...

Beim ESXi sehe ich das genauso allerdings mit einem Unterschied und der betrifft ausschließlich die ungleichen Geschwister 6.5 und 6.7. Der 6.5er konnte schon etwas länger reifen und spielt meiner begrenzten Erfahrung nach besser mit älterer HW zusammen. Da beim 6.7er auch wieder alte HW rausgeworfen wurde und beide den gleichen Supportzeitraum haben, würde ich ausprobieren, womit die eigene HW besser harmoniert. Hinsichtlich 5.5 und 6.0 sei dir gesagt, daß ersterer bereits aus dem Support ist und der 6.0er fällt meiner Erinnerung nach im März raus.

Die HTML5-Oberfläche als Ersatz für den alten Fat-/Win-Client fand ich damals auch auf dem 5.5er schon schick, auch wenn er damals noch große Löcher im Funktionsumfang hatte. Bei 6.5er gibt es mit dem Funktionsumfang für Normalsterbliche keine Probleme mehr. Zumindest bin ich da auf keine gestossen und das trotz per PCI-Passstrough an einen Gast durchgereichter Karte.