virt-v2v - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

virt-v2v - Konvertieren Sie einen Gast, um KVM zu verwenden

ZUSAMMENFASSUNG

virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest

virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest \
-o rhev -os rhev.nfs:/export_domain --network rhevm

virt-v2v -i libvirtxml gastdomäne.xml -o local -os / var / tmp

virt-v2v -i disk disk.img -o local -os / var / tmp

virt-v2v -i disk disk.img -o flüchtig

virt-v2v -ic qemu:///system qemu_guest --in-place

BESCHREIBUNG

Virt-v2v konvertiert Gäste von einem fremden Hypervisor zur Ausführung auf KVM. Es kann Linux lesen und
Windows-Gäste, die auf VMware, Xen, Hyper-V und einigen anderen Hypervisoren ausgeführt werden, und konvertieren
sie zu KVM, verwaltet von libvirt, OpenStack, oVirt, Red Hat Enterprise Virtualisation (RHEV)
oder mehrere andere Ziele.

Es gibt auch ein begleitendes Frontend namens virt-p2v(1) die als ISO, CD oder PXE kommt
Image, das auf physischen Maschinen gebootet werden kann, um diese Maschinen zu virtualisieren (physisch zu
virtuell oder p2v).

Diese Handbuchseite dokumentiert das neu geschriebene virt-v2v, das in libguestfs ≥ 1.28 enthalten ist.

SPEISUNG UND AUSGABE MODI

┌────────────┐ ┌─────────▶ -o null
-i Datenträger ────────────┐ │ │ ─┘┌───────▶ -o local
-i ova ──────────┐ └──▶ │ virt-v2v │ ──┘┌───────▶ -o qemu
└────▶ │ Konvertierung │ ───┘┌────────────┐
VMware─▶┌────────────┐ │ Server │ ────▶ -o libvirt │─▶ KVM
Xen ───▶│ -i libvirt ──▶ │ │ │ (Standard) │
... ───▶│ (Standard) │ │ │ ──┐ └────────────┘
└────────────┘ │ │ ─┐└──────▶ -o Blick
-i libvirtxml ─────────▶ │ │ ┐└─────────▶ -o rhev
└────────────┘ └──────────▶ -o vdsm

Virt-v2v verfügt über eine Reihe möglicher Eingabe- und Ausgabemodi, die mit den -i sowie -o
Optionen. Für jeden Durchlauf von virt-v2v kann nur ein Eingabe- und Ausgabemodus ausgewählt werden.

-i Scheibe wird zum Lesen von lokalen Disk-Images verwendet (hauptsächlich zum Testen).

-i libvirt wird zum Lesen aus einer beliebigen libvirt-Quelle verwendet. Da sich libvirt mit vielen verbinden kann
verschiedene Hypervisoren, es wird zum Lesen von Gästen von VMware, RHEL 5 Xen und mehr verwendet.
Das -NS Option wählt die genaue libvirt-Quelle aus.

-i libvirtxml wird verwendet, um aus libvirt-XML-Dateien zu lesen. Dies ist die Methode, die von verwendet wird
virt-p2v(1) Hinter den Kulissen.

-i Eizellen wird zum Lesen aus einer VMware-ova-Quelldatei verwendet.

-o flüchtiger blick wird zum Schreiben in OpenStack Glance verwendet.

-o libvirt wird zum Schreiben auf ein beliebiges libvirt-Ziel verwendet. Libvirt kann sich mit lokalen oder verbinden
Remote-KVM-Hypervisoren. Die -oc Option wählt das genaue libvirt-Ziel aus.

-o aus einer regionalen wird verwendet, um mit einer lokalen libvirt-Konfigurationsdatei auf ein lokales Disk-Image zu schreiben
(hauptsächlich zum Testen).

-o qemu schreibt auf ein lokales Disk-Image mit einem Shell-Skript zum Booten des Gastes direkt in
qemu (hauptsächlich zum Testen).

-o rev wird verwendet, um auf ein RHEV-M / oVirt-Ziel zu schreiben. -o vdsm wird nur verwendet, wenn virt-v2v
läuft unter VDSM-Steuerung.

--an Ort und Stelle weist virt-v2v an, das Gastbetriebssystem in der virtuellen Eingabemaschine anzupassen,
anstatt eine neue VM im Zielhypervisor zu erstellen.

Beispiele:

Konvertieren von VMware vCenter Server zu aus einer regionalen libvirt
Sie haben einen VMware vCenter-Server namens "vcenter.example.com", ein Rechenzentrum namens
"Datacenter" und ein ESXi-Hypervisor namens "esxi". Sie möchten einen Gast namens . konvertieren
"vmware_guest", um lokal unter libvirt zu laufen.

virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest

In diesem Fall müssen Sie virt-v2v höchstwahrscheinlich als "root" ausführen, da es sprechen muss
zum System-Libvirt-Daemon und kopieren Sie die Gastdisketten nach / var / lib / libvirt / images.

Weitere Informationen finden Sie unten unter "EINGABE VOM VMWARE VCENTER SERVER".

Konvertieren von VMware zu RHEV-M/oVirt
Dies ist das gleiche wie im vorherigen Beispiel, außer dass Sie den Gast zu einem RHEV-M schicken möchten
Exportieren Sie eine entfernte Speicherdomäne (über NFS) unter "rhev.nfs:/export_domain".
Wenn Sie sich bezüglich des Standorts der Exportspeicherdomäne nicht sicher sind, sollten Sie die
Einstellungen auf Ihrer RHEV-M-Verwaltungskonsole. Gast-Netzwerkschnittstelle(n) sind verbunden mit
das Zielnetzwerk namens "rhevm".

virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest \
-o rhev -os rhev.nfs:/export_domain --network rhevm

In diesem Fall fungiert der Host, auf dem virt-v2v ausgeführt wird, als Umwandlung Server.

Beachten Sie, dass der Gast nach der Konvertierung in der RHEV-M Export Storage Domain angezeigt wird.
von wo aus Sie es über die RHEV-M-Benutzeroberfläche importieren müssen. (Siehe "AUSGABE AN
RHEV").

Konvertieren Scheibe Image zu OpenStack flüchtiger blick
Gegeben ein Disk-Image von einem anderen Hypervisor, das Sie konvertieren möchten, um auf OpenStack ausgeführt zu werden
(nur KVM-basiertes OpenStack wird unterstützt), können Sie Folgendes tun:

virt-v2v -i disk disk.img -o flüchtig

Um den Namen des Bildes in Glance zu steuern, verwenden Sie die -On .

Konvertieren Scheibe Image zu Scheibe Image
Bei einem Disk-Image von einem anderen Hypervisor, das Sie konvertieren möchten, um auf KVM ausgeführt zu werden,
haben zwei Möglichkeiten. Der einfachste Weg ist, es zu versuchen:

virt-v2v -i disk disk.img -o local -os / var / tmp

wobei virt-v2v alles über die Eingabe errät disk.img und schreibt (in diesem Fall) die
Ergebnis umgerechnet in / var / tmp.

Eine komplexere Methode besteht darin, libvirt-XML zu schreiben, die den Eingabegast beschreibt (wenn Sie können
holen Sie sich den Quell-Hypervisor, um Ihnen libvirt-XML zur Verfügung zu stellen, um so besser). Du
kann dann tun:

virt-v2v -i libvirtxml gastdomäne.xml -o local -os / var / tmp

Da Gast-Domain.xml enthält den/die Pfad(e) zu den Gast-Disk-Images, die Sie nicht benötigen
Geben Sie den Namen des Disk-Images in der Befehlszeile an.

Um ein lokales Festplatten-Image zu konvertieren und es sofort in lokalem qemu zu booten, gehen Sie wie folgt vor:

virt-v2v -i disk disk.img -o qemu -os / var / tmp --qemu-boot

SUPPORT MATRIX

Hypervisoren (Eingang)
VMware ESXi
Muss von VMware vCenter ≥ 5.0 verwaltet werden. Nicht verwaltete, direkte Eingabe von ESXi ist nicht
unterstützt.

Aus VMware exportierte OVA
OVAs von anderen Hypervisoren funktionieren nicht.

RHEL 5Xen
Citrix Xen
Citrix Xen wurde in letzter Zeit nicht getestet.

Hyper-V
Vor kurzem nicht getestet. Erfordert, dass Sie die Festplatte exportieren oder verwenden virt-p2v(1) auf Hyper-V.

Direkt von Disk-Images
Nur Disk-Images, die von unterstützten Hypervisoren exportiert wurden und Containerformate verwenden
unterstützt von qemu.

Physische Maschinen
Verwendung der virt-p2v(1) Werkzeug.

Hypervisoren (Ausgabe)
Nur QEMU und KVM.

Virtualisierung Management Systeme (Ausgabe)
OpenStack-Blick
Red Hat Enterprise Virtualization (RHEV) 2.2 und höher
Lokale libvirt
Und daher virsch(1) Virt-Manager(1) und ähnliche Werkzeuge.

Lokale Festplatte

Gäste
Red Hat Enterprise Linux 3, 4, 5, 6, 7
CentOS 3, 4, 5, 6, 7
Wissenschaftliches Linux 3, 4, 5, 6, 7
Oracle Linux
Fedora
SLES 10 und höher
OpenSUSE 10 und höher
Windows XP bis Windows 8.1 / Windows Server 2012 R2
Wir verwenden Windows-interne Versionsnummern, siehe
https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

Derzeit werden NT 5.2 bis NT 6.3 unterstützt.

Weitere Hinweise zum Konvertieren von Windows-Gästen finden Sie unten unter "WINDOWS".

GUEST Firmware
BIOS oder UEFI für alle Gasttypen (aber siehe "UEFI" unten).

OPTIONAL

--help
Hilfe anzeigen.

-b ...
--Brücke ...
Weitere Informationen finden Sie auch in den --Netzwerk unten mit.

--komprimiert
Schreiben Sie eine komprimierte Ausgabedatei. Dies ist nur erlaubt, wenn das Ausgabeformat qcow2 ist
(sehen -oder unten) und ist äquivalent zu dem -c Option qemu-img(1).

--dcpath Ordner/Rechenzentrum
NB: Sie brauchen diesen Parameter nicht zu verwenden, wenn Sie libvirt ≥ 1.2.20 haben.

Überschreiben Sie für VMware vCenter den Parameter "dcPath=...", der zum Auswählen des Rechenzentrums verwendet wird.
Virt-v2v kann dies normalerweise aus der "vpx://"-URI berechnen, aber wenn es falsch ist,
dann können Sie es mit dieser Einstellung überschreiben. Gehen Sie zu Ihrer vCenter-Webordnerschnittstelle,
z.B. "https://vcenter.example.com/folder" (ohne ein nachgestellter Schrägstrich) und untersuchen Sie die
Parameter "dcPath=" in den URLs, die auf dieser Seite angezeigt werden.

--debug-gc
Debuggen von Garbage Collection und Speicherzuweisung. Dies ist nur beim Debuggen nützlich
Speicherprobleme in virt-v2v oder den OCaml libguestfs-Bindungen.

--debug-overlays
Speichern Sie die während der Konvertierung erstellte(n) Overlay-Datei(en). Diese Option wird nur verwendet für
debugging virt-v2v und wird möglicherweise in einer zukünftigen Version entfernt.

-i Scheibe
Stellen Sie die Eingabemethode auf Scheibe.

In diesem Modus können Sie ein Festplatten-Image einer virtuellen Maschine ohne Metadaten lesen. virt-v2v
versucht, die besten Standardmetadaten zu erraten. Dies ist normalerweise ausreichend, aber Sie können es bekommen
feinere Kontrolle (z. B. von Speicher und vCPUs) durch Verwendung von -i libvirtxml stattdessen. Nur Gäste
die eine einzelne Festplatte verwenden, können auf diese Weise importiert werden.

-i libvirt
Stellen Sie die Eingabemethode auf libvirt. Dies ist die Standardeinstellung.

In diesem Modus müssen Sie in der Befehlszeile einen libvirt-Gastnamen oder eine UUID angeben.
Sie können auch eine libvirt-Verbindungs-URI angeben (siehe -NS).

-i libvirtxml
Stellen Sie die Eingabemethode auf libvirtxml.

In diesem Modus müssen Sie eine libvirt-XML-Datei auf der Kommandozeile übergeben. Diese Datei ist
lesen, um Metadaten über den Quellgast zu erhalten (wie Name, Anzahl der
Speicher) und auch zum Auffinden der Eingabedisketten. Siehe "MINIMAL XML FOR -i libvirtxml
OPTION" unten.

-i aus einer regionalen
Dies ist das gleiche wie -i Scheibe.

-i Eizellen
Stellen Sie die Eingabemethode auf Eizellen.

In diesem Modus können Sie eine VMware-ova-Datei lesen. Virt-v2v liest die ova-Manifestdatei
und die vmdk-Volumes auf Gültigkeit (Prüfsummen) prüfen sowie die ovf-Datei analysieren,
und dann den Gast konvertieren. Siehe "EINGABE VON VMWARE OVA" unten

-NS libvirtURI
Geben Sie einen libvirt-Verbindungs-URI an, der beim Lesen des Gasts verwendet werden soll. Das wird nur verwendet
wann -i libvirt.

Nur lokale libvirt-Verbindungen, VMware vCenter-Verbindungen oder RHEL 5 Xen Remote
Anschlüsse verwendet werden können. Andere entfernte libvirt-Verbindungen funktionieren im Allgemeinen nicht.

Siehe auch "EINGABE VON VMWARE VCENTER SERVER", "EINGABE VON RHEL 5 XEN" unten.

-wenn Format
Für -i Scheibe Dies gibt nur das Format des Eingabe-Disk-Image an. Für andere Eingaben
Methoden sollten Sie das Eingabeformat in den Metadaten angeben.

--an Ort und Stelle
Erstellen Sie keine virtuelle Ausgabemaschine im Zielhypervisor. Passen Sie stattdessen die
Gastbetriebssystem in der Quell-VM, das im Eingabe-Hypervisor ausgeführt werden soll.

Dieser Modus ist für die Integration mit anderen Toolsets gedacht, die die Verantwortung übernehmen
der Konvertierung der VM-Konfiguration, Rollback im Fehlerfall,
Umwandeln des Speichers usw.

Konflikte mit allen -o * nach.

--maschinenlesbar
Diese Option wird verwendet, um die Ausgabe maschinenfreundlicher zu machen, wenn sie von geparst wird
andere Programme. Siehe "MASCHINENLESBARE AUSGABE" unten.

-n rein: raus
-n
--Netzwerk rein: raus
--Netzwerk
-b rein: raus
-b
--Brücke rein: raus
--Brücke
Ordnen Sie das Netzwerk (oder die Bridge) mit dem Namen "in" dem Netzwerk (oder die Bridge) mit dem Namen "out" zu. Wenn kein "in:"
Präfix angegeben, werden alle anderen Netzwerke (oder Bridges) auf "out" abgebildet.

Siehe "NETZWERKE UND BRÜCKEN" unten.

--keine Kopie
Kopieren Sie die Disketten nicht. Stattdessen wird eine Konvertierung durchgeführt (und weggeworfen) und
Metadaten werden geschrieben, aber es werden keine Datenträger erstellt. Siehe auch Diskussion über -o null unten mit.

Dies ist in zwei Fällen nützlich: Entweder Sie möchten testen, ob eine Konvertierung wahrscheinlich ist
gelingen, ohne den langen Kopiervorgang. Oder Sie interessieren sich nur für das Anschauen
die Metadaten.

Diese Option ist nicht kompatibel mit -o libvirt da es einen fehlerhaften Gast erzeugen würde
(einer ohne Festplatten).

Diese Option ist nicht kompatibel mit -o flüchtiger blick aus technischen Gründen.

--no-trimmen alle
--no-trimmen mp[,mp...]
Standardmäßig läuft virt-v2v fstrim(8) um ​​die Datenmenge zu reduzieren, die benötigt wird
kopiert. Dies ist bekannt dafür, dass einige fehlerhafte Bootloader beschädigt werden, was nach dem Booten zu Fehlern führt
Konvertierung (siehe zum Beispiel https://bugzilla.redhat.com/show_bug.cgi?id=1141145#c27).

Sie können verwenden --no-trimmen alle um alle Trimmen zu deaktivieren. Beachten Sie, dass dies stark zunehmen wird
die Datenmenge, die kopiert werden muss, und kann dazu führen, dass virt-v2v viel langsamer läuft.

Sie können das Trimmen auch nur für ausgewählte Dateisysteme deaktivieren (angegeben durch ein Komma).
getrennte Liste ihrer Einhängepunkte im Gast). Normalerweise würden Sie verwenden
--no-trimmen / boot um den oben erwähnten Grub-Bug zu umgehen.

Sie können das Trimmen von Partitionen auch mit dem libguestfs-Namensschema für deaktivieren
Geräte, zB: --no-trimmen / dev / sdb2 bedeutet, die zweite Partition nicht auf der zweiten zu trimmen
Gerät blockieren. Verwenden virt-Dateisysteme(1) um Dateisystemnamen in einem Gast aufzulisten.

-o Scheibe
Dies ist das gleiche wie -o aus einer regionalen.

-o flüchtiger blick
Legen Sie die Ausgabemethode auf OpenStack Glance fest. In diesem Modus ist der konvertierte Gast
auf Glance hochgeladen. Sie können den Bildnamen steuern, indem Sie die -On .

-o libvirt
Setzen Sie die Ausgabemethode auf libvirt. Dies ist die Standardeinstellung.

In diesem Modus wird der konvertierte Gast als libvirt-Gast erstellt. Sie können auch angeben
eine libvirt-Verbindungs-URI (siehe -oc).

Siehe "AUSGABE IN LIBVIRT" unten.

-o aus einer regionalen
Setzen Sie die Ausgabemethode auf aus einer regionalen.

In diesem Modus wird der konvertierte Gast in ein lokales Verzeichnis geschrieben durch -Knochen
/dir (das Verzeichnis muss vorhanden sein). Die Datenträger des konvertierten Gasts werden wie folgt geschrieben:

/dir/name-sda
/dir/name-sdb
[Etc.]

und eine libvirt-XML-Datei wird erstellt, die Gast-Metadaten enthält:

/dir/name.xml

wobei "name" der Gastname ist.

-o null
Setzen Sie die Ausgabemethode auf null.

Der Gast wird konvertiert und kopiert (sofern Sie nicht auch angeben --keine Kopie), aber die Ergebnisse
werden weggeworfen und es werden keine Metadaten geschrieben.

-o ovirt
Dies ist das gleiche wie -o rev.

-o qemu
Setzen Sie die Ausgabemethode auf qemu.

Das ist ähnlich wie -o aus einer regionalen, außer dass ein Shell-Skript geschrieben wird, das Sie verwenden können
um den Gast in qemu zu booten. Die konvertierten Datenträger und das Shell-Skript werden in die Datei geschrieben
Verzeichnis angegeben von -Knochen.

Bei Verwendung dieses Ausgabemodus können Sie auch die --qemu-boot Option, die Stiefel
der Gast sofort unter qemu.

-o rev
Setzen Sie die Ausgabemethode auf rev.

Der konvertierte Gast wird in eine RHEV-Exportspeicherdomäne geschrieben. Die -Knochen Parameter
muss auch verwendet werden, um den Speicherort der Exportspeicherdomäne anzugeben. Beachten Sie dies
importiert den Gast nicht wirklich in RHEV. Das musst du später manuell machen
die Benutzeroberfläche verwenden.

Siehe "AUSGABE AN RHEV" unten.

-o vdsm
Setzen Sie die Ausgabemethode auf vdsm.

Dieser Modus ist ähnlich wie -o rev, aber der vollständige Pfad zur Datendomäne muss angegeben werden:
/rhev/rechenzentrum/ /. Dieser Modus wird nur verwendet, wenn
virt-v2v läuft unter VDSM-Steuerung.

-oa spärlich
-oa vorbelegt
Legen Sie den Zuordnungsmodus für die Ausgabedatei fest. Die Vorgabe ist "sparse".

-oc libvirtURI
Geben Sie eine libvirt-Verbindung an, die beim Schreiben des konvertierten Gasts verwendet werden soll. Das ist nur
verwendet wenn -o libvirt. Siehe "AUSGABE IN LIBVIRT" unten.

Es können nur lokale libvirt-Verbindungen verwendet werden. Remote-Libvirt-Verbindungen funktionieren nicht.

-oder Format
Wenn Sie den Gast konvertieren, konvertieren Sie die Datenträger in das angegebene Format.

Wenn nicht angegeben, wird das Eingabeformat verwendet.

-On Name
Benennen Sie den Gast beim Konvertieren um. Wenn diese Option nicht verwendet wird, wird der Ausgabename
ist mit dem Eingangsnamen identisch.

-Knochen Lagerung
Der Speicherort für den konvertierten Gast.

Für -o libvirt, dies ist ein libvirt-Verzeichnispool (siehe "virsh pool-list") oder eine Pool-UUID.

Für -o aus einer regionalen sowie -o qemu, dies ist ein Verzeichnisname. Das Verzeichnis muss vorhanden sein.

Für -o rev, dies kann ein NFS-Pfad der Export Storage Domain des Formulars sein
" : ", z.B:

rhev-storage.example.com:/rhev/export

Der NFS-Export muss für den Benutzer und Host, auf dem virt-v2v ausgeführt wird, mountbar und beschreibbar sein.
da das virt-v2v-Programm es tatsächlich mounten muss, wenn es ausgeführt wird. Also du wahrscheinlich
muss virt-v2v als "root" ausführen.

Oder: Sie können die Exportspeicherdomäne selbst mounten und zeigen -Knochen zum Mountpoint.
Beachten Sie, dass virt-v2v weiterhin in dieses Remote-Verzeichnis schreiben muss, also wird virt-v2v
muss noch als "root" ausgeführt werden.

Sie erhalten eine Fehlermeldung, wenn virt-v2v den Exportspeicher nicht mounten/schreiben kann
Domain.

--Passwort-Datei Datei
Anstatt interaktiv nach Passwörtern zu fragen, übergeben Sie das Passwort durch eine Datei.
Beachten Sie, dass die Datei das gesamte Passwort enthalten sollte, ohne für schleppend Neue ZeileUnd für
Sicherheit sollte die Datei den Modus 0600 haben, damit andere sie nicht lesen können.

--Druckquelle
Drucken Sie Informationen über den Quellgast und stoppen Sie. Diese Option ist nützlich, wenn Sie
Einrichten von Netzwerk- und Bridge-Maps. Siehe "NETZWERKE UND BRÜCKEN".

--qemu-boot
Beim Benutzen -o qemu nur bootet dies den Gast sofort, nachdem virt-v2v beendet ist.

-q
--ruhig
Dadurch werden Fortschrittsbalken und andere unnötige Ausgaben deaktiviert.

--Wurzel fragen
--Wurzel Single
--Wurzel zuerst
--Wurzel / dev / sdX
--Wurzel /dev/VG/LV
Wählen Sie das zu konvertierende Root-Dateisystem.

Wenn es sich bei der virtuellen Maschine um Dual-Boot oder Multi-Boot handelt oder die VM über
andere Dateisysteme, die wie Betriebssysteme aussehen, kann mit dieser Option ausgewählt werden
das Root-Dateisystem (auch bekannt als "C:" Laufwerk oder /) des Betriebssystems, das sein soll
umgewandelt. Die Windows-Wiederherstellungskonsole, bestimmte angeschlossene DVD-Laufwerke und Fehler in
libguestfs-Inspektionsheuristiken, können einen Gast wie einen Multi-Boot-Betrieb aussehen lassen
System.

Der Standard in virt-v2v ≤ 0.7.1 war --root-Single, wodurch virt-v2v stirbt, wenn a
Multi-Boot-Betriebssystem gefunden.

Seit virt-v2v ≥ 0.7.2 ist der Standard jetzt --root frage: Wenn festgestellt wird, dass die VM mehrere
booten, dann stoppt virt-v2v und listet die möglichen Root-Dateisysteme auf und fragt den Benutzer
welche zu verwenden. Dies erfordert, dass virt-v2v interaktiv ausgeführt wird.

--root zuerst bedeutet, bei einem Multi-Boot das erste Root-Gerät auszuwählen
Betriebssystem. Da dies eine Heuristik ist, kann sie manchmal die falsche auswählen.

Sie können auch ein bestimmtes Root-Gerät benennen, z. --root /dev/sda2 würde bedeuten, die zu verwenden
zweite Partition auf der ersten Festplatte. Wenn das benannte Root-Gerät nicht existiert oder
nicht als Root-Gerät erkannt wurde, schlägt virt-v2v fehl.

Beachten Sie, dass es einen Fehler in Grub gibt, der ein erfolgreiches Booten verhindert
Multiboot-System, wenn VirtIO aktiviert ist. Grub kann nur ein Betriebssystem booten
von der ersten VirtIO-Festplatte. Speziell, / boot muss sich auf der ersten VirtIO-Festplatte befinden, und
es kann ein Betriebssystem, das sich nicht auf der ersten VirtIO-Festplatte befindet, nicht verketten.

--vdsm-image-uuid UUID
--vdsm-vol-uuid UUID
--vdsm-vm-uuid UUID
--vdsm-ovf-Ausgabe
Normalerweise wählt der RHEV-Ausgabemodus zufällige UUIDs für den Zielgast. Jedoch VDSM
muss die UUIDs kontrollieren und übergibt diese Parameter, wenn virt-v2v unter VDSM läuft
Steuerung. Die Parameter steuern:

· das Image-Verzeichnis jeder Gastdiskette (--vdsm-image-uuid) (diese Option wird übergeben
einmal für jede Gastdiskette)

· UUIDs für jede Gastfestplatte (--vdsm-vol-uuid) (diese Option wird jeweils einmal übergeben
Gastdiskette)

· der OVF-Dateiname (--vdsm-vm-uuid).

· das OVF-Ausgabeverzeichnis (standardmäßiges aktuelles Verzeichnis) (--vdsm-ovf-Ausgabe).

Das Format der UUIDs ist: "12345678-1234-1234-1234-123456789abc" (jede Hex-Ziffer kann sein
"0-9" oder "af"), entsprechend OSF DCE 1.1.

Diese Optionen können nur mit verwendet werden -o vdsm.

-v
- ausführlich
Aktivieren Sie ausführliche Nachrichten zum Debuggen.

-V
--Version
Versionsnummer anzeigen und beenden.

--vmtyp Desktop
--vmtyp Server
Bei der -o rev or -o vdsm nur Ziele, geben Sie die Art des Gastes an. Das kannst du einstellen
auf "Desktop" oder "Server". Wenn die Option nicht angegeben ist, ist ein geeigneter Standardwert
basierend auf dem erkannten Gastbetriebssystem ausgewählt.

-x Aktivieren Sie die Ablaufverfolgung von libguestfs-API-Aufrufen.

XEN PARAVIRTUALISIERT GÄSTE

Ältere Versionen von virt-v2v könnten einen paravirtualisierten (PV) Xen-Gast in einen KVM-Gast verwandeln, indem
einen neuen Kernel installieren. Diese Version von virt-v2v funktioniert nicht Versuchen Sie, eine neue zu installieren
Kerne. Stattdessen erhalten Sie einen Fehler, wenn es vorhanden ist einzige Xen PV-Kernel verfügbar.

Daher sollten Sie vor der Konvertierung überprüfen, ob ein regulärer Kernel installiert ist. Für einige
älteren Linux-Distributionen bedeutet dies die Installation eines Kernels aus der folgenden Tabelle:

RHEL 3 (Gilt nicht, da kein Xen PV-Kernel vorhanden war)

RHEL 4 i686 mit > 10 GB RAM: 'kernel-hugemem' installieren
i686 SMP: 'kernel-smp' installieren
anderer i686: 'Kernel' installieren
x86-64 SMP mit > 8 CPUs: 'kernel-largesmp' installieren
x86-64 SMP: 'kernel-smp' installieren
anderes x86-64: 'Kernel' installieren

RHEL 5 i686: 'Kernel-PAE' installieren
x86-64: 'Kernel' installieren

SLES 10 i586 mit > 10 GB RAM: 'kernel-bigsmp' installieren
i586 SMP: 'kernel-smp' installieren
anderer i586: 'kernel-default' installieren
x86-64 SMP: 'kernel-smp' installieren
anderes x86-64: 'kernel-default' installieren

SLES 11+ i586: 'kernel-pae' installieren
x86-64: 'kernel-default' installieren

Windows (Gilt nicht, da kein Xen PV Windows-Kernel vorhanden ist)

AKTIVIEREN VIRTIO

"Virtio" ist der Name für eine Reihe von Treibern, die Festplatte (Blockgerät), Netzwerk und
andere Gastoperationen arbeiten auf KVM viel schneller.

Ältere Versionen von virt-v2v könnten diese Treiber für bestimmte Linux-Gäste installieren. Dies
Version von virt-v2v tut nicht versuchen, neue Linux-Kernel oder -Treiber zu installieren, werden aber
warnen Sie, wenn sie nicht bereits installiert sind.

Um virtio zu ermöglichen und damit die Leistung des Gastes nach der Konvertierung zu verbessern,
Sie sollten sicherstellen, dass die Minimum Versionen von Paketen sind installiert bevor Konvertierung,
indem Sie die Tabelle unten konsultieren.

RHEL 3 Es sind keine virtio-Treiber verfügbar

RHEL 4-Kernel >= 2.5.9-89.EL
lvm2 >= 2.02.42-5.el4
Gerätezuordnung >= 1.02.28-2.el4
selinux-policy-targeted >= 1.17.30-2.152.el4
policycoreutils >= 1.18.1-4.13

RHEL 5-Kernel >= 2.6.18-128.el5
lvm2 >= 2.02.40-6.el5
selinux-policy-targeted >= 2.4.6-203.el5

RHEL 6+ Alle Versionen unterstützen virtio

Fedora Alle Versionen unterstützen virtio

SLES 11+ Alle Versionen unterstützen virtio

SLES 10-Kernel >= 2.6.16.60-0.85.1

OpenSUSE 11+ Alle Versionen unterstützen virtio

OpenSUSE 10-Kernel >= 2.6.25.5-1.1

Windows-Treiber werden aus dem Verzeichnis installiert, auf das verweist
Umgebungsvariable "VIRTIO_WIN"
(standardmäßig /usr/share/virtio-win) falls vorhanden

RHEL 4

SELinux umbenennen erscheint zu hängen für immer
In RHEL ≤ 4.7 gab es einen Fehler, der dazu führte, dass das Relabeling von SELinux für immer hängen blieb
unter:

*** Warnung -- SELinux-Relabel ist erforderlich. ***
*** Deaktivieren der Sicherheitsdurchsetzung. ***
*** Die Umetikettierung kann sehr lange dauern, ***
*** abhängig von Dateisystemgröße. ***

In Wirklichkeit wartet es darauf, dass Sie eine Taste drücken (aber es gibt keine visuelle Anzeige von
Dies). Sie können entweder die "[Return]"-Taste drücken, an welcher Stelle der Gast fertig ist
Umbenennen und neu starten, oder Sie können policycoreutils ≥ 1.18.1-4.13 installieren, bevor Sie beginnen
die v2v-Konvertierung. Siehe auch https://bugzilla.redhat.com/show_bug.cgi?id=244636

FENSTER

Stiefel Fehler: 0x0000007B
Dieser Boot-Fehler wird dadurch verursacht, dass Windows den richtigen Festplattentreiber nicht finden oder laden kann
(z.B. viostor.sys). Wenn dieser Fehler auftritt, sollten Sie Folgendes überprüfen:

· Stellen Sie zunächst sicher, dass der Gast vor der Konvertierung auf dem Quell-Hypervisor bootet.

· Überprüfen Sie, ob die Windows virtio-Treiber verfügbar sind in /usr/share/virtio-win, Und das
virt-v2v hat keine Warnung ausgegeben, dass virtio-Treiber nicht installiert werden können.

Unter Red Hat Enterprise Linux 7 müssen Sie die verfügbaren signierten Treiber installieren
im Paket "virtio-win". Wenn Sie keinen Zugriff auf die signierten Treiber haben, dann
Sie müssen wahrscheinlich die Treiberanmeldung in den Startmenüs deaktivieren.

· Prüfen Sie, ob Sie eine virtio-blk-Oberfläche präsentieren (nicht virtio-scsi und nicht ide) zu
der Gast. Auf der qemu/KVM-Befehlszeile sollten Sie etwas Ähnliches sehen:

... -Laufwerkdatei=windows-sda,if=virtio ...

In libvirt-XML sollten Sie Folgendes sehen:



· Vergewissern Sie sich, dass die Windows-Gruppenrichtlinie die Installation des Treibers nicht verhindert oder
Gebraucht. Versuchen Sie, die Windows-Gruppenrichtlinie vor der Konvertierung zu löschen.

· Überprüfen Sie, ob kein Antivirenprogramm oder andere Software vorhanden ist, die Gruppenrichtlinien ähnlich implementiert
Verbote, neue Treiber zu installieren oder zu verwenden.

· Aktivieren Sie das Boot-Debugging und überprüfen Sie die viostor.sys Treiber wird geladen.

OpenStack sowie Windows Reaktivierung
OpenStack bietet Gästen keine stabilen Geräte-/PCI-Adressen. Jedes Mal, wenn es entsteht
oder einen Gast startet, regeneriert es die libvirt-XML für diesen Gast von Grund auf neu. Die
libvirt XML hat keine Felder. Libvirt weist dann Geräten Adressen zu,
in vorhersehbarer Weise. Adressen können sich ändern, wenn einer der folgenden Punkte zutrifft:

· Eine neue Festplatte oder ein neues Netzwerkgerät wurde dem Gast hinzugefügt oder entfernt.

· Die Version von OpenStack oder (möglicherweise) libvirt hat sich geändert.

Da Windows solche "Hardware"-Änderungen nicht mag, kann dies dazu führen, dass Windows
Reaktivierung.

Dies kann auch das Booten mit einem 7B-Fehler verhindern [siehe vorheriger Abschnitt], wenn der Gast
Gruppenrichtlinie, die "Einschränkungen bei der Geräteinstallation" enthält.

UEFI

VMware ermöglicht es Ihnen, Gästen UEFI-Firmware zu präsentieren (anstelle des normalen PC-BIOS).
Virt-v2v kann diese Gäste konvertieren, erfordert jedoch, dass UEFI vom Ziel unterstützt wird
Hypervisor.

Derzeit unterstützt KVM OVMF, eine teilweise Open-Source-UEFI-Firmware, und kann diese ausführen
Gästen.

Da die OVMF-Unterstützung erst vor kurzem zu KVM hinzugefügt wurde (in 2014/2015), sind nicht alle Ziel
Umgebungen unterstützen UEFI-Gäste noch:

UEFI auf libvirt, qemu
Unterstützt. Virt-v2v generiert automatisch das richtige libvirt-XML (Metadaten).
Beachten Sie jedoch, dass auf dem Konvertierungshost dieselbe Version von OVMF installiert sein muss wie sie ist
auf dem Ziel-Hypervisor installiert, andernfalls müssen Sie die Pfade im
Metadaten.

UEFI auf OpenStack
Nicht unterstützt.

UEFI auf RHEV
Nicht unterstützt.

NETZWERKE UND BRÜCKEN

Gäste sind normalerweise mit einem oder mehreren Netzwerken verbunden, und wenn sie in das Ziel konvertiert werden
Hypervisor Sie in der Regel diese Netzwerke am Ziel erneut verbinden möchten. Die Optionen
--Netzwerk sowie --Brücke erlaube dir das zu tun.

Wenn Sie sich nicht sicher sind, welche Netzwerke und Bridges auf dem Quellhypervisor verwendet werden, dann
Sie können die Quellmetadaten (libvirt XML, vCenter-Informationen usw.) untersuchen. Oder du kannst
virt-v2v mit dem ausführen --Druckquelle Option, die virt-v2v veranlasst, die
Informationen über den Gast an der Quelle und dann zum Beenden.

Im --Druckquelle Ausgabe sehen Sie einen Abschnitt mit der Netzwerkschnittstelle des Gastes
Karten (NICs):

$ virt-v2v [-i ...] --Name der Druckquelle
[...]
Netzwerkkarten:
Netzwerk "Standard"-Mac: 52:54:00:d0:cf:0e

Dies ist typisch für einen libvirt-Gast: Er hat eine einzige Netzwerkschnittstelle, die mit einem
Netzwerk namens "default".

Um ein bestimmtes Netzwerk einem Zielnetzwerk zuzuordnen, zum Beispiel "default" auf der Quelle zu
"rhevm" auf dem Ziel verwenden, verwenden Sie:

virt-v2v [...] --network default:rhevm

Um jedes Netzwerk einem Zielnetzwerk zuzuordnen, verwenden Sie:

virt-v2v [...] --network rhevm

Brücken werden auf die gleiche Weise gehandhabt, aber Sie müssen die --Brücke Option statt. Zum
Beispiel:

$ virt-v2v [-i ...] --Name der Druckquelle
[...]
Netzwerkkarten:
Brücke "br0"

$ virt-v2v [...] --bridge br0:zielbr

SPEISUNG AB VMWARE VCENTER SERVER

Virt-v2v kann Gäste von VMware vCenter Server importieren.

vCenter ≥ 5.0 ist erforderlich. Wenn Sie nicht über vCenter verfügen, wird stattdessen die Verwendung von OVA empfohlen
(siehe "EINGABE VON VMWARE OVA" unten), oder wenn dies nicht möglich ist, siehe "EINGABE VON
VMWARE ESXi HYPERVISOR".

Virt-v2v verwendet libvirt für den Zugriff auf vCenter, daher sollte der Eingabemodus -i
libvirt. Da dies die Standardeinstellung ist, müssen Sie sie nicht in der Befehlszeile angeben.

ZENTRUM: ENTFERNEN VMWARE TOOLS AB FENSTER GÄSTE
Für Windows-Gäste sollten Sie VMware-Tools vor der Konvertierung entfernen. Obwohl das ist
nicht unbedingt erforderlich, und der Gast kann trotzdem laufen, wenn Sie dies nicht tun
der bekehrte Gast wird sich bei jedem Boot beschweren. Die Werkzeuge können danach nicht entfernt werden
Konvertierung, da das Deinstallationsprogramm prüft, ob es auf VMware läuft und den Start verweigert
(was auch der Grund ist, dass virt-v2v sie nicht entfernen kann).

Dies ist für Linux-Gäste nicht erforderlich, da virt-v2v VMware-Tools entfernen kann.

ZENTRUM: URI
Der libvirt-URI eines vCenter-Servers sieht etwa so aus:

vpx://user@server/Datacenter/esxi

wo:

"Benutzer@"
ist der (optionale, aber empfohlene) Benutzer, als der die Verbindung hergestellt werden soll.

Wenn der Benutzername einen umgekehrten Schrägstrich enthält (z. B. "DOMAIN\USER"), müssen Sie URI-
Escape dieses Zeichen mit %5c: "DOMAIN%5cUSER" (5c ist der hexadezimale ASCII-Code für
Backslash.) Andere Satzzeichen müssen möglicherweise ebenfalls mit Escapezeichen versehen werden.

"Server"
ist der vCenter-Server (nicht Hypervisor).

"Rechenzentrum"
ist der Name des Rechenzentrums.

Wenn der Name ein Leerzeichen enthält, ersetzen Sie es durch den URI-Escape-Code %20.

"esxi"
ist der Name des ESXi-Hypervisors, der den Gast ausführt.

Wenn die VMware-Bereitstellung Ordner verwendet, müssen diese möglicherweise zum URI hinzugefügt werden, z. B.:

vpx://user@server/Ordner/Datacenter/esxi

Ausführliche Informationen zu libvirt-URIs finden Sie unter: http://libvirt.org/drvesx.html

Typische Fehler von libvirt / virsh bei falscher URI sind:

· Konnte Datenzentrum nicht finden, das in [...]

· Es konnte keine Rechenressource gefunden werden, die in [...]

· Pfad [...] gibt keine Rechenressource an

· Pfad [...] gibt kein Hostsystem an

· Konnte Host-System nicht finden, das in [...]

ZENTRUM: TESTEN LIBVIRT CONNECTION TO VCENTER
Verwenden Sie das virsch(1) Befehl zum Auflisten der Gäste auf dem vCenter Server wie folgt:

$virsh -c 'vpx://[E-Mail geschützt] /Datacenter/esxi' list --all
Geben Sie das Root-Passwort für vcenter.example.com ein: ***

ID-Namensstatus
-------------------------------------------------- -
- Fedora 20 ausgeschaltet
- Windows 2003 ausgeschaltet

Wenn Sie eine Fehlermeldung erhalten "Peer-Zertifikat kann nicht mit angegebenen CA-Zertifikaten authentifiziert werden"
oder ähnlich, dann können Sie entweder das Zertifikat des vCenter-Hosts importieren oder die Signatur umgehen
Überprüfung durch Hinzufügen des Flags "?no_verify=1":

$virsh -c 'vpx://[E-Mail geschützt] /Datacenter/esxi?no_verify=1' list --all

Sie sollten auch versuchen, die Metadaten von jedem Gast auf Ihrem Server wie folgt auszugeben:

$virsh -c 'vpx://[E-Mail geschützt] /Datacenter/esxi' dumpxml "Windows 2003"

Windows 2003
[...]


If die oben Befehle do nicht zu arbeiten, dann virt-v2v is nicht gehen zu Arbeit entweder. Repariere deine
libvirt-Konfiguration und/oder Ihren VMware vCenter Server, bevor Sie fortfahren.

ZENTRUM: IMPORTIEREN A GUEST
So importieren Sie einen bestimmten Gast von vCenter Server:

$ virt-v2v -ic 'vpx://[E-Mail geschützt] /Datacenter/esxi?no_verify=1' \
"Windows 2003" \
-o lokal -os / var / tmp

wobei "Windows 2003" der Name des Gastes ist (der heruntergefahren werden muss).

Beachten Sie, dass Sie möglicherweise nach dem vCenter-Passwort gefragt werden zweimal. Das passiert einmal, weil
libvirt braucht es, und ein zweites Mal, weil virt-v2v sich direkt mit dem verbindet
Server. Verwenden --Passwort-Datei um ein Passwort über eine Datei bereitzustellen.

In diesem Fall werden die Ausgabe-Flags gesetzt, um den konvertierten Gast auf ein temporäres . zu schreiben
Verzeichnis, da dies nur ein Beispiel ist, aber Sie können auch in libvirt oder jedes andere schreiben
unterstütztes Ziel.

ZENTRUM: NICHT-ADMINISTRATOR ROLLE
Anstatt die vCenter-Administratorrolle zu verwenden, können Sie einen benutzerdefinierten Nicht-Administrator erstellen
Rolle, um die Konvertierung durchzuführen. Sie müssen jedoch einen Mindestsatz von
Berechtigungen wie folgt:

1. Erstellen Sie eine benutzerdefinierte Rolle in vCenter.

2. Aktivieren (prüfen) Sie die folgenden Objekte:

Datenspeicher:
- Datenspeicher durchsuchen
- Dateioperationen auf niedriger Ebene

Session:
- Sitzung validieren

Virtuelle Maschine:
Bereitstellung:
- Festplattenzugriff zulassen
- Schreibgeschützten Festplattenzugriff zulassen
- Verwaltung des Gastbetriebssystems durch VIX API

SPEISUNG AB VMWARE OVA

Virt-v2v kann Gäste aus VMwares OVA-Dateien (Open Virtualization Appliance) importieren.
Nur aus VMware vSphere exportierte OVAs funktionieren.

EIZELLEN: ENTFERNEN VMWARE TOOLS AB FENSTER GÄSTE
Für Windows-Gäste sollten Sie VMware-Tools vor der Konvertierung entfernen. Obwohl das ist
nicht unbedingt erforderlich, und der Gast kann trotzdem laufen, wenn Sie dies nicht tun
der bekehrte Gast wird sich bei jedem Boot beschweren. Die Werkzeuge können danach nicht entfernt werden
Konvertierung, da das Deinstallationsprogramm prüft, ob es auf VMware läuft und den Start verweigert
(was auch der Grund ist, dass virt-v2v sie nicht entfernen kann).

Dies ist für Linux-Gäste nicht erforderlich, da virt-v2v VMware-Tools entfernen kann.

EIZELLEN: CREATE OVA
Um eine OVA in vSphere zu erstellen, verwenden Sie die Option "OVF-Vorlage exportieren" (aus dem VM-Kontext
Menü oder über das Menü Datei). Entweder "Ordner der Dateien" (OVF) oder "Einzelne Datei" (OVA) wird
funktionieren, aber OVA ist wahrscheinlich einfacher zu handhaben. OVA-Dateien sind wirklich nur unkomprimiertes Tar
Dateien, sodass Sie Befehle wie "tar tf VM.ova" verwenden können, um deren Inhalt anzuzeigen.

Kreation OVA mit ovftool

Sie können auch das proprietäre "ovftool" von VMware verwenden:

ovftool --noSSLVerify \
vi://BENUTZER:[E-Mail geschützt] /VM \
VM.ova

So stellen Sie eine Verbindung zu vCenter her:

ovftool --noSSLVerify \
vi://BENUTZER:[E-Mail geschützt] /DATACENTER-NAME/vm/VM \
VM.ova

Für eine Active Directory-fähige Authentifizierung müssen Sie das Zeichen "@" im
Form seines ASCII-Hex-Codes (%5c):

vi://DOMÄNE%5cBENUTZER:PASSWORT@...

EIZELLEN: IMPORTIEREN A GUEST
So importieren Sie eine OVA-Datei namens VM.ova, tun;

$ virt-v2v -i ova VM.ova -o local -os / var / tmp

Wenn Sie den Gast als "Dateiordner" exportiert haben, or wenn Sie den OVA-Tarball ausgepackt haben
selbst, dann können Sie virt-v2v auf das Verzeichnis zeigen, das die Dateien enthält:

$ virt-v2v -i ova /path/to/files -o local -os / var / tmp

SPEISUNG AB VMWARE ESXi HYPERVISOR

Virt-v2v kann nicht direkt auf einen ESXi-Hypervisor zugreifen. Sie sollten die obige OVA-Methode verwenden
(siehe "INPUT VON VMWARE OVA") wenn möglich, da es viel schneller ist und viel weniger benötigt
Speicherplatz als die in diesem Abschnitt beschriebene Methode.

Sie können die Verwendung virt-v2v-kopieren-nach-lokal(1) Tool zum Kopieren des Gasts vom Hypervisor in ein
lokale Datei, und konvertieren Sie sie dann.

ESXi: ENTFERNEN VMWARE TOOLS AB FENSTER GÄSTE
Für Windows-Gäste sollten Sie VMware-Tools vor der Konvertierung entfernen. Obwohl das ist
nicht unbedingt erforderlich, und der Gast kann trotzdem laufen, wenn Sie dies nicht tun
der bekehrte Gast wird sich bei jedem Boot beschweren. Die Werkzeuge können danach nicht entfernt werden
Konvertierung, da das Deinstallationsprogramm prüft, ob es auf VMware läuft und den Start verweigert
(was auch der Grund ist, dass virt-v2v sie nicht entfernen kann).

Dies ist für Linux-Gäste nicht erforderlich, da virt-v2v VMware-Tools entfernen kann.

ESXi: URI
Der libvirt-URI für VMware ESXi-Hypervisor sieht ungefähr so ​​​​aus:

esx://[E-Mail geschützt] ?no_verify=1

Der Parameter "?no_verify=1" deaktiviert die TLS-Zertifikatsprüfung.

ESXi: TESTEN LIBVIRT CONNECTION TO ESXi HYPERVISOR
Verwenden Sie das virsch(1) Befehl zum Testen der URI und Auflisten der verfügbaren Remote-Gäste:

$virsh -c esx://[E-Mail geschützt] ?no_verify=1 Liste --all
Geben Sie das Root-Passwort für esxi.example.com ein: ***
ID-Namensstatus
-------------------------------------------------- -
- Gästeabschaltung

ESXi: COPY GUEST TO LOCAL MACHINE
Verwenden der libvirt-URI als -NS kopieren Sie einen der Gäste auf den lokalen Computer:

$ virt-v2v-copy-to-local -ic esx://[E-Mail geschützt] ?no_verify=1 Gast

Dies schafft gast.xml, Gast-Festplatte1...

ESXi: DO VIRT-V2V UMWANDLUNG
Führen Sie die Konvertierung des Gastes mit virt-v2v durch:

$ virt-v2v -i libvirtxml guest.xml -o local -os / var / tmp

ESXi: REINIGEN UP
Entferne das gast.xml sowie Gast-Disk* Dateien.

SPEISUNG AB RHEL 5 XEN

Virt-v2v kann Xen-Gäste von RHEL 5-Xen-Hosts importieren.

Virt-v2v verwendet libvirt für den Zugriff auf den entfernten Xen-Host und damit den Eingabemodus
sollte sein -i libvirt. Da dies die Standardeinstellung ist, müssen Sie sie nicht im Befehl angeben
Linie.

XEN: SET UP SSH-AGENT ACCESS TO XEN HOST
Derzeit müssen Sie den passwortlosen SSH-Zugriff auf den Remote-Xen-Host von virt-v2v . aktivieren
Konvertierungsserver.

Sie müssen auch ssh-agent verwenden und Ihren öffentlichen ssh-Schlüssel hinzufügen zu /root/.ssh/authorized_keys (auf
der Xen-Host).

Danach sollten Sie überprüfen, ob der passwortlose Zugriff vom virt-v2v-Server aus funktioniert
zum Xen-Host. Zum Beispiel:

$ ssh [E-Mail geschützt]
[ loggt sich direkt in die Shell ein, es wird kein Passwort verlangt ]

Beachten Sie, dass passwortinteraktiver und Kerberos-Zugriff nicht unterstützt. Du haben einrichten
ssh-Zugriff mit ssh-agent und authorisierten_keys.

XEN: TESTEN LIBVIRT CONNECTION TO REMOTE XEN HOST
Verwenden Sie das virsch(1) Befehl zum Auflisten der Gäste auf dem Remote-Xen-Host:

$virsh -c xen+ssh://[E-Mail geschützt] Liste alle auf
ID-Namensstatus
-------------------------------------------------- -
0 Domain-0 läuft
- rhel49-x86_64-pv abgeschaltet

Sie sollten auch versuchen, die Metadaten von jedem Gast auf Ihrem Server wie folgt auszugeben:

$virsh -c xen+ssh://[E-Mail geschützt] dumpxml rhel49-x86_64-pv

rhel49-x86_64-pv
[...]


If die oben Befehle do nicht zu arbeiten, dann virt-v2v is nicht gehen zu Arbeit entweder. Repariere deine
libvirt-Konfiguration oder den Remote-Server, bevor Sie fortfahren.

If die Gast Festplatten sind located on a Gastgeber Schutzmassnahmen bei Gerät, dann schlägt die Konvertierung fehl. Sehen
"XEN- ODER SSH-KONVERSIONEN VON BLOCKGERÄTEN" unten für eine Problemumgehung.

XEN: IMPORTIEREN A GUEST
So importieren Sie einen bestimmten Gast von einem Xen-Server:

$ virt-v2v -ic 'xen+ssh://[E-Mail geschützt] '\
rhel49-x86_64-pv \
-o lokal -os / var / tmp

wobei "rhel49-x86_64-pv" der Name des Gastes ist (der heruntergefahren werden muss).

In diesem Fall werden die Ausgabe-Flags gesetzt, um den konvertierten Gast auf ein temporäres . zu schreiben
Verzeichnis, da dies nur ein Beispiel ist, aber Sie können auch in libvirt oder jedes andere schreiben
unterstütztes Ziel.

XEN OR SSH Umrechnungen AB BLOCK GERÄTE
Derzeit kann virt-v2v nicht direkt auf einen Xen-Gast (oder einen Gast, der sich remote über
ssh), wenn sich die Festplatten dieses Gastes auf Hostblockgeräten befinden.

Um festzustellen, ob ein Xen-Gast Host-Block-Geräte verwendet, sehen Sie sich die Gast-XML an. Du wirst sehen:


...


wobei "type='block'", "source dev=" und "/dev/..." allesamt Anzeichen dafür sind, dass die Festplatte
befindet sich auf einem Host-Block-Gerät.

Dies geschieht, weil der qemu ssh-Blocktreiber, den wir für den Zugriff auf Remote-Festplatten verwenden, die
ssh sftp-Protokoll, und dieses Protokoll kann die Größe des Hostblocks nicht richtig erkennen
Geräte.

Die Problemumgehung besteht darin, den Gast mit dem separaten . auf den Konvertierungsserver zu kopieren
virt-v2v-kopieren-nach-lokal(1) Tool, gefolgt von der Ausführung von virt-v2v. Sie benötigen ausreichend
Speicherplatz auf dem Konvertierungsserver, um eine vollständige Kopie des Gasts zu speichern.

virt-v2v-copy-to-local -ic xen+ssh://[E-Mail geschützt] Gast
virt-v2v -i libvirtxml guest.xml -o local -os / var / tmp
rm guest.xml Gastdisk*

AUSGABE TO LIBVIRT

Das -o libvirt -Option können Sie den konvertierten Gast auf einen von libvirt verwalteten Host hochladen.
Es gibt mehrere Einschränkungen:

· Sie können nur eine lokale libvirt-Verbindung verwenden [siehe unten, um dies zu umgehen].

· Das -Knochen Pool Option muss einen Verzeichnispool angeben, nichts Exotischeres wie
iSCSI [aber siehe unten].

· Sie können nur auf einen KVM-Hypervisor hochladen.

Zu Möglichkeiten für das Ausgangssignal: zu a entfernt libvirt Instanz und / oder a Nicht-Verzeichnis Lagerung Pool du musst verwenden
folgende Problemumgehung:

1. Verwenden Sie virt-v2v in -o aus einer regionalen Modus zum Konvertieren der Gastdisketten und Metadaten in ein lokales
Temporäres Verzeichnis:

virt-v2v [...] -o local -os / var / tmp

Dies erstellt zwei (oder mehr) Dateien in / var / tmp namens:

/var/tmp/NAME.xml # die libvirt-XML (Metadaten)
/var/tmp/NAME-sda # die erste Festplatte des Gastes

(für "NAME" den Namen des Gastes ersetzen).

2. Laden Sie die konvertierte(n) Festplatte(n) in den Speicherpool namens "POOL" hoch:

size=$(stat -c%s /var/tmp/NAME-sda)
virsh vol-create-as POOLNAME-sda $size --format raw
virsh vol-upload --pool POOLNAME-sda /var/tmp/NAME-sda

3. Bearbeiten /var/tmp/NAME.xml zu ändern /var/tmp/NAME-sda zum Poolnamen. Mit anderen Worten,
Suchen Sie das folgende XML-Bit:







und ändern Sie zwei Dinge: Das Attribut "type='file'" muss in "type='volume'" geändert werden,
und der " "-Element muss so geändert werden, dass es die Attribute "pool" und "volume" enthält:


...

...


4. Definieren Sie den letzten Gast in libvirt:

virsh definieren /var/tmp/NAME.xml

AUSGABE TO rhev

Dieser Abschnitt gilt nur für -o rev Ausgabemodus. Wenn Sie virt-v2v aus dem RHEV-M . verwenden
Benutzeroberfläche, dann wird der Import hinter den Kulissen von VDSM über die -o vdsm
Ausgabemodus (den Endbenutzer nicht direkt verwenden sollten).

Sie müssen angeben -o rev und ein -Knochen Option, die auf den RHEV-M Export Storage verweist
Domain. Sie können entweder den NFS-Server und den Mountpoint angeben, z.
"-os rhev-storage:/rhev/export", oder du kannst das zuerst mounten und auf das Verzeichnis zeigen
wo es montiert ist, z. "-os /tmp/mnt". Achten Sie darauf, nicht auf den Datenspeicher zu zeigen
Domain aus Versehen, da das nicht funktioniert.

Nach erfolgreichem Abschluss hat virt-v2v den neuen Gast in den Export Storage geschrieben
Domain, aber sie ist noch nicht laufbereit. Es muss über die Benutzeroberfläche in RHEV importiert werden
bevor es verwendet werden kann.

In RHEV ≥ 2.2 erfolgt dies über die Registerkarte Speicher. Wählen Sie die Exportdomäne aus, die der Gast war
geschrieben an. Unterhalb der Speicherdomänenliste erscheint ein Fenster mit mehreren
Registerkarten, von denen eine "VM-Import" ist. Der konvertierte Gast wird hier aufgelistet. Wähle aus
entsprechenden Gast ein Klick auf "Importieren". Weitere Details finden Sie in der RHEV-Dokumentation.

Wenn Sie mehrere Gäste exportieren, können Sie sie alle gleichzeitig über das
UI

RESSOURCE VORAUSSETZUNGEN

Netzwerk
Die wichtigste Ressource für virt-v2v scheint die Netzwerkbandbreite zu sein. Virt-v2v sollte
in der Lage sein, Gastdaten mit Gigabit-Ethernet-Geschwindigkeiten oder höher zu kopieren.

Stellen Sie sicher, dass die Netzwerkverbindungen zwischen Servern (Konvertierungsserver, NFS-Server,
vCenter, Xen) sind so schnell und möglichst latenzarm.

Festplatten Raum
Virt-v2v legt potenziell große temporäre Dateien in $TMPDIR ab (was / var / tmp wenn du
nicht einstellen). Die Verwendung von tmpfs ist eine schlechte Idee.

Für jede Gastfestplatte wird temporär ein Overlay gespeichert. Dies speichert die vorgenommenen Änderungen
während der Konvertierung und wird als Cache verwendet. Die Überlagerungen sind nicht besonders groß - Zehner
oder niedrige Hunderte von Megabyte pro Festplatte sind typisch. Zusätzlich zu dem/den Overlay(s), Eingabe
und Ausgabemethoden können Speicherplatz belegen, wie in der folgenden Tabelle beschrieben.

-i Eizellen
Dadurch wird vorübergehend eine vollständige Kopie der unkomprimierten Quelldatenträger in $TMPDIR abgelegt.

-o flüchtiger blick
Dadurch wird vorübergehend eine vollständige Kopie der Ausgabedisketten in $TMPDIR abgelegt.

-o aus einer regionalen
-o qemu
Sie müssen sicherstellen, dass im Ausgabeverzeichnis genügend Platz für die konvertierten
Gast.

-o null
Dadurch wird vorübergehend eine vollständige Kopie der Ausgabedisketten in $TMPDIR abgelegt.

VMware vCenter RESSOURCEN
Das Kopieren von VMware vCenter ist derzeit ziemlich langsam, aber wir glauben, dass dies ein Problem ist
mit VMware. Sicherstellen, dass der VMware ESXi-Hypervisor und das vCenter auf schneller Hardware ausgeführt werden
mit viel Speicher sollte dies lindern.

Berechnen Werkzeuge sowie RAM
Virt-v2v ist nicht besonders rechen- oder RAM-intensiv. Wenn Sie viele parallel laufen
Konvertierungen, dann können Sie in Erwägung ziehen, einen CPU-Kern und zwischen 512 MB und 1 GB an
RAM pro ausgeführter Instanz.

Virt-v2v kann in einer virtuellen Maschine ausgeführt werden.

NACH DER KONVERTIERUNG AUFTRÄGE

GUEST Netzwerk Konfiguration
Virt-v2v kann derzeit die Netzwerkkonfiguration eines Gasts nicht neu konfigurieren. Wenn der konvertierte
Gast nicht mit demselben Subnetz wie die Quelle verbunden ist, kann seine Netzwerkkonfiguration
müssen aktualisiert werden. Siehe auch virt-anpassen(1).

weiterverarbeitende Industrie a Windows Gast
Beim Konvertieren eines Windows-Gasts wird der Konvertierungsprozess in zwei Phasen unterteilt:

1. Offline-Konvertierung.

2. Erster Start.

Der Gast ist nach der Offline-Konvertierungsphase bootfähig, hat aber noch nicht alle
notwendigen Treiber installiert, um richtig zu funktionieren. Diese werden automatisch installiert
zum ersten Mal die Gaststiefel.

NB Achten Sie darauf, die automatische Treiberinstallation beim Anmelden nicht zu unterbrechen
zum ersten Mal an den Gast, da dies den Gast am späteren Booten hindern kann
korrekt.

KOSTENLOS SPACE FÜR UMWANDLUNG

Virt-v2v prüft, ob im Gastdateisystem genügend freier Speicherplatz vorhanden ist, um die
Wandlung. Derzeit prüft es:

Linux-Root-Dateisystem oder Windows-Laufwerk "C:"
Mindestfreier Speicherplatz: 20 MB

Linux / boot
Mindestfreier Speicherplatz: 50 MB

Dies liegt daran, dass wir für einige Enterprise-Linux ein neues initramfs erstellen müssen
Konvertierungen.

Jedes andere einhängbare Dateisystem
Mindestfreier Speicherplatz: 10 MB

LAUFEN VIRT-V2V AS ROOT OR NICHT GEROOTED

Nichts in virt-v2v benötigt von Natur aus Root-Zugriff und es läuft problemlos als Nicht-Root
Benutzer. Bestimmte externe Funktionen erfordern jedoch möglicherweise entweder Root oder einen speziellen Benutzer:

Mounten der Exportspeicherdomäne
Beim Benutzen -o rev -Knochen server:/esd virt-v2v muss über ausreichende Berechtigungen für NFS verfügen
Mounten Sie die Export Storage Domain von "server".

Sie können es vermeiden, hier root zu benötigen, indem Sie es selbst mounten, bevor Sie virt-v2v ausführen, und
Bestehen -Knochen /Einhängepunkt Lesen Sie stattdessen zuerst den nächsten Abschnitt ...

Schreiben in die Exportspeicherdomäne als 36:36
RHEV-M kann keine Dateien und Verzeichnisse aus der Exportspeicherdomäne lesen, es sei denn, sie
haben UID:GID 36:36. Wenn UID:GID nicht korrekt ist, werden VM-Importprobleme angezeigt.

Wenn Sie virt-v2v . ausführen -o rev als root versucht virt-v2v Dateien zu erstellen und
Verzeichnisse mit den richtigen Eigentümern. Wenn Sie virt-v2v als Nicht-Root ausführen, wird es
funktioniert wahrscheinlich immer noch, aber Sie müssen den Besitzer manuell ändern, nachdem virt-v2v gestartet wurde
fertig.

Schreiben an libvirt
Beim Benutzen -o libvirt, müssen Sie möglicherweise virt-v2v als root ausführen, damit es schreiben kann
die libvirt-Systeminstanz (z. B. "qemu:///system") und zum Standardspeicherort für
Disk-Images (normalerweise / var / lib / libvirt / images).

Sie können dies vermeiden, indem Sie die libvirt-Verbindungsauthentifizierung einrichten, siehe
http://libvirt.org/auth.html. Alternativ verwenden Sie -oc qemu:///session, was wird
Schreiben Sie in Ihre benutzerspezifische libvirt-Instanz.

Schreiben auf einen Blick
Dies tut nicht brauchen root (tatsächlich wird es wahrscheinlich nicht funktionieren), aber kann entweder a
spezieller Benutzer und/oder für Sie, um ein Skript zu erstellen, das die Authentifizierungsumgebung festlegt
Variablen. Schlagen Sie in der Glance-Dokumentation nach.

FEHLERBEHEBUNG RHEV-M EINFÜHREN AUSFÄLLE

Wenn Sie in die RHEV-M-Exportspeicherdomäne exportieren und dann diesen Gast importieren über
der RHEV-M-Benutzeroberfläche, kann ein Importfehler auftreten. Die Diagnose dieser Fehler ist
ärgerlich schwierig, da die Benutzeroberfläche im Allgemeinen den wahren Grund für den Fehler verbirgt.

Es gibt zwei Protokolldateien von Interesse. Der erste wird auf dem RHEV-M-Server selbst gespeichert, und
wird genannt /var/log/ovirt-engine/engine.log

Die zweite Datei, die am nützlichsten ist, befindet sich auf dem SPM-Host (SPM steht für
"Speicherpool-Manager"). Dies ist ein RHEV-Knoten, der für alle Metadaten ausgewählt wurde
Änderungen im Rechenzentrum, wie Image- oder Snapshot-Erstellung. Du kannst herausfinden
welcher Host der aktuelle SPM ist, aus der Registerkarte "Hosts" Spalte "Spm-Status". Sobald du hast
habe das SPM gefunden, logge dich ein und nimm die Datei /var/log/vdsm/vdsm.log die enthalten wird
detaillierte Fehlermeldungen von Low-Level-Befehlen.

MINIMAL XML FÜR -i libvirtxml zur Auswahl

Bei Verwendung der -i libvirtxml Option müssen Sie libvirt-XML bereitstellen. Das schreiben
von Grund auf ist schwer, daher ist die folgende Vorlage hilfreich.

Hinweis fehlen uns die Worte. sollte einzige be benutzt für testing und / oder woher Sie kennt was du bist tun! Wenn Sie
libvirt-Metadaten für den Gast haben, verwenden Sie stattdessen immer diese.


NAME
1048576
2

hvm














<mac address='52:54:00:01:02:03'/>

MACHINE LESBAR AUSGABE

Das --maschinenlesbar Option kann verwendet werden, um die Ausgabe maschinenfreundlicher zu machen, was
ist nützlich beim Aufrufen von virt-v2v aus anderen Programmen, GUIs etc.

Es gibt zwei Möglichkeiten, diese Option zu verwenden.

Verwenden Sie zunächst die Option allein, um die Fähigkeiten der Binärdatei virt-v2v abzufragen.
Eine typische Ausgabe sieht so aus:

$ virt-v2v --maschinenlesbar
virt-v2v
libguestfs-rewrite
Eingabe: Festplatte
[...]
Ausgabe: lokal
[...]
convert:Enterprise-Linux
konvertieren: Windows

Eine Liste von Funktionen wird gedruckt, eine pro Zeile, und das Programm wird mit dem Status 0 beendet.

Die Funktionen "input:" und "output:" beziehen sich auf -i sowie -o (Eingabe- und Ausgabemodus) Optionen
von dieser Binärdatei unterstützt. Die "convert:"-Funktionen beziehen sich auf Gasttypen, die diese Binärdatei
weiß, wie man umwandelt.

Zweitens verwenden Sie die Option in Verbindung mit anderen Optionen, um das reguläre Programm zu erstellen
Ausgabe maschinenfreundlicher.

Das bedeutet im Moment:

1. Fortschrittsbalkennachrichten können von stdout aus geparst werden, indem Sie nach diesem regulären suchen
Ausdruck:

^[0-9]+/[0-9]+$

2. Das aufrufende Programm sollte an stdout gesendete Nachrichten behandeln (außer Fortschrittsbalken
Meldungen) als Statusmeldungen. Sie können protokolliert und/oder dem Benutzer angezeigt werden.

3. Das aufrufende Programm sollte Nachrichten, die an stderr gesendet werden, als Fehlermeldungen behandeln. In
Außerdem wird virt-v2v mit einem Statuscode ungleich Null beendet, wenn ein schwerwiegender Fehler aufgetreten ist.

Virt-v2v ≤ 0.9.1 hat das nicht unterstützt --maschinenlesbar Option überhaupt. Die Option war
hinzugefügt, als virt-v2v 2014 neu geschrieben wurde.

Verwenden Sie virt-v2v online mit den onworks.net-Diensten