Mein Unternehmen muss die Erstellung neuer VMs mit unserer proprietären Lösung automatisieren. Dazu möchten wir das Produkt entweder in einem standardisierten Format ausliefern (OVA scheint der einzige „Standard“ auf dem Markt zu sein) oder in der Lage sein, von derselben Maschine in verschiedene Virtualisierungstypen zu konvertieren.
Bisher wird dies manuell durchgeführt, d. h. wenn ein Kunde eine HyperV-VM möchte, müssen wir diese auf einem internen HyperV-Server erstellen, VMWare auf VMWare usw. Unser Ziel ist es, dies zu automatisieren.
Bessere Erklärung: Geplant ist, einen KVM-Server zu haben, die VM bereitzustellen und sie nach der Bereitstellung in ein OVA-Format zu exportieren, möglicherweise als zusätzlichen Service für unsere Kunden auf dem Hypervisor ihrer Wahl.
Ich kann die Datenträger problemlos mit „qemu-img convert“ konvertieren, allerdings gelingt mir die Konvertierung der Maschinendefinition (XML) in die von anderen Hypervisoren benötigten Formate nicht.
Ich kann keine geeigneten Tools hierfür finden. Vorschläge?
Hinweis: Wir haben keinen Zugriff auf den Hypervisor, auf dem diese installiert werden, daher müssen wir sie als OVA/TAR usw. exportieren.
Antwort1
Leider verspricht OVA viel mehr, als es halten kann. Bestenfalls ist es ein Standardformat zum Verteilen von Disk-Images, aber es leistet sehr wenig, wenn überhaupt, um sicherzustellen, dass ein Disk-Image nahtlos auf mehreren Hypervisoren gebootet werden kann. Jeder Hypervisor emuliert einen anderen Satz virtueller Hardware, sodass Gastbetriebssysteme für jeden Hypervisor unterschiedliche Treiber installieren müssen. Einige Betriebssysteme wie Linux sind einigermaßen gut darin, mit beliebiger Hardware zu booten und Treiber automatisch zu erkennen, die zu dem passen, was sie finden, aber selbst dann kann man leicht Fehler machen oder es zum Absturz bringen. Wenn Sie beispielsweise /etc/fstab„/“ als auf der Festplatte befindlich auflisten /dev/vda1(für den virtio-blk-Festplattentreiber von QEMU), funktioniert das nicht, wenn Sie auf VMWare mit einer SCSI-Festplatte booten, die als erscheint /dev/sda1. Windows lässt sich nur schwer an unterschiedliche Hardware anpassen, da es gerne bestimmte Treiber eng an jede Festplatte/NIC/usw. bindet.
Es besteht auch das Problem, dass jeder Hypervisor sein eigenes bevorzugtes Disk-Image-Format hat – VMWare bevorzugt vmdk, QEMU mag idealerweise raw oder qcow2, VirtualBox hat ein anderes usw. usw. OVA unternimmt nichts, um diese schwierigen Probleme zu lösen.
Diese Art von Problemen sind der Grund, warum Tools wie virt-v2v (http://libguestfs.org/virt-v2v.1.html) gibt es, die ein Disk-Image für einen Hypervisor erstellen und das Gastbetriebssystem so neu konfigurieren, dass es auf einem anderen Hypervisor funktioniert, wobei sich gleichzeitig das Disk-Format ändert.
Selbst wenn Sie irgendwie ein Disk-Image erstellen, von dem Sie meinen, dass es auf allen funktioniert, müssen Sie es dennoch einem vollständigen QA-Testzyklus unterziehen, um sicherzustellen, dass es tatsächlich ordnungsgemäß funktioniert.
Meiner Meinung nach ist es viel einfacher, einfach für jeden Hypervisor ein dediziertes Disk-Image zu erstellen.