virt-v2v - Online nel cloud

PROGRAMMA:

NOME

virt-v2v - Converti un ospite per usare KVM

SINOSSI

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 dominio-ospite.xml -o local -os / Var / tmp

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

virt-v2v -i disco disk.img -o sguardo

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

DESCRIZIONE

Virt-v2v converte i guest da un hypervisor straniero per l'esecuzione su KVM. Può leggere Linux e
Ospiti Windows in esecuzione su VMware, Xen, Hyper-V e alcuni altri hypervisor e convertono
li a KVM gestiti da libvirt, OpenStack, oVirt, Red Hat Enterprise Virtualization (RHEV)
o diversi altri obiettivi.

C'è anche un front-end companion chiamato virt-p2v(1) che viene fornito come ISO, CD o PXE
immagine che può essere avviata su macchine fisiche per virtualizzare tali macchine (fisiche per
virtuale o p2v).

Questa pagina di manuale documenta il virt-v2v riscritto incluso in libguestfs ≥ 1.28.

INGRESSO E USCITA MODALITA '

┌────────────┐ ┌───────── ▶ -o null
-i disco ────────────┐ │ │ ─┘┌───────▶ -o local
-i ovuli ──────────┐ └──▶ │ virt-v2v │ ──┘┌───────▶ -o qemu
└────▶ │ conversione │ ───┘┌────────────┐
VMware─ ▶┌────────────┐ │ server │ ──── ▶ -o libvirt │─ ▶ KVM
Xen ───▶│ -i libvirt ──▶ │ │ │ (predefinito) │
... ───▶│ (predefinito) │ │ │ ──┐ └────────────┘
└────────────┘ │ │ ─┐└──────▶ -o sguardo
-i libvirtxml ───────── ▶ │ │ ┐└───────── ▶ -o rhev
└────────────┘ └───────────▶ -o vdsm

Virt-v2v ha un numero di possibili modalità di input e output, selezionate usando il -i e -o
opzioni. È possibile selezionare solo una modalità di input e output per ogni esecuzione di virt-v2v.

-i disco viene utilizzato per la lettura da immagini del disco locale (principalmente per i test).

-i libvirt è usato per leggere da qualsiasi sorgente libvirt. Poiché libvirt può connettersi a molti
diversi hypervisor, viene utilizzato per leggere gli ospiti da VMware, RHEL 5 Xen e altro.
. -circuito integrato l'opzione seleziona la sorgente libvirt precisa.

-i libvirtxml è usato per leggere da file XML di libvirt. Questo è il metodo usato da
virt-p2v(1) dietro le quinte.

-i ovuli viene utilizzato per leggere da un file sorgente VMware ova.

-o sguardo viene utilizzato per scrivere su OpenStack Glance.

-o libvirt è usato per scrivere su qualsiasi destinazione libvirt. Libvirt può connettersi a locale o
hypervisor KVM remoti. Il -oc l'opzione seleziona il target libvirt preciso.

-o locale è usato per scrivere su un'immagine del disco locale con un file di configurazione libvirt locale
(principalmente per il test).

-o whoa scrive su un'immagine del disco locale con uno script di shell per avviare il guest direttamente in
qemu (principalmente per i test).

-o revi viene utilizzato per scrivere su un target RHEV-M / oVirt. -o vdsm viene utilizzato solo quando virt-v2v
funziona sotto il controllo di VDSM.

--a posto indica a virt-v2v di personalizzare il sistema operativo guest nella macchina virtuale di input,
invece di creare una nuova macchina virtuale nell'hypervisor di destinazione.

ESEMPI

convertire da VMware vCenter server a locale libvirt
Hai un server VMware vCenter chiamato "vcenter.example.com", un datacenter chiamato
"Datacenter" e un hypervisor ESXi chiamato "esxi". Vuoi convertire un ospite chiamato
"vmware_guest" da eseguire localmente sotto libvirt.

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

In questo caso molto probabilmente dovrai eseguire virt-v2v come "root", poiché ha bisogno di parlare
al demone libvirt di sistema e copiare i dischi guest su / var / lib / libvirt / images.

Per ulteriori informazioni, vedere "INPUT DA VMWARE VCENTER SERVER" di seguito.

convertire da VMware a RHEV-M/oVirt
Questo è lo stesso dell'esempio precedente, tranne per il fatto che desideri inviare l'ospite a un RHEV-M
Export Storage Domain che si trova in remoto (su NFS) in "rhev.nfs:/export_domain".
Se non sei chiaro sulla posizione dell'Export Storage Domain dovresti controllare il
impostazioni sulla console di gestione di RHEV-M. Le interfacce di rete ospite sono collegate a
la rete di destinazione chiamata "rhevm".

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

In questo caso l'host che esegue virt-v2v funge da a conversione server.

Nota che dopo la conversione, il guest apparirà nel RHEV-M Export Storage Domain,
da dove sarà necessario importarlo utilizzando l'interfaccia utente RHEV-M. (Vedi "USCITA A
REV").

convertire disco Immagine a OpenStack sguardo
Data un'immagine del disco da un altro hypervisor che si desidera convertire per l'esecuzione su OpenStack
(solo OpenStack basato su KVM è supportato), puoi fare:

virt-v2v -i disco disk.img -o sguardo

Per controllare il nome dell'immagine in Glance, usa il -One opzione.

convertire disco Immagine a disco Immagine
Data un'immagine disco di un altro hypervisor che desideri convertire per l'esecuzione su KVM,
avere due opzioni. Il modo più semplice è provare:

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

dove virt-v2v indovina tutto sull'input disco.img e (in questo caso) scrive il
risultato convertito in / Var / tmp.

Un metodo più complesso è scrivere un XML libvirt che descriva il guest di input (se puoi
ottenere l'hypervisor di origine per fornire libvirt XML, quindi tanto meglio). Voi
può quindi fare:

virt-v2v -i libvirtxml dominio-ospite.xml -o local -os / Var / tmp

Dal dominio-ospite.xml contiene i percorsi delle immagini del disco guest che non sono necessarie
specificare il nome dell'immagine del disco sulla riga di comando.

Per convertire un'immagine del disco locale e avviarla immediatamente in qemu locale, eseguire:

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

SUPPORTO MATRIX

Hypervisor (Ingresso)
VMware ESXi
Deve essere gestito da VMware vCenter ≥ 5.0. Non gestito, l'input diretto da ESXi non lo è
supportato.

OVA esportato da VMware
Gli OVA di altri hypervisor non funzioneranno.

RHEL5Xen
Citrix Xen
Citrix Xen non è stato testato di recente.

Hyper-V
Non testato di recente. Richiede l'esportazione del disco o l'utilizzo virt-p2v(1) su Hyper-V.

Direttamente dalle immagini del disco
Solo immagini disco esportate da hypervisor supportati e utilizzando formati contenitore
supportato da qemu.

Macchine fisiche
Usando il virt-p2v(1) strumento.

Hypervisor (Produzione)
Solo QEMU e KVM.

Virtualization di riferimento (Produzione)
Sguardo OpenStack
Red Hat Enterprise Virtualization (RHEV) 2.2 e versioni successive
libvirt locale
E quindi vergognoso(1), virt manager(1) e strumenti simili.

Disco locale

Gli ospiti
Red Hat Enterprise Linux 3, 4, 5, 6, 7
Cent OS 3, 4, 5, 6, 7
Linux scientifico 3, 4, 5, 6, 7
Oracle Linux
Fedora
SLES 10 e superiori
OpenSUSE 10 e versioni successive
Da Windows XP a Windows 8.1/Windows Server 2012 R2
Usiamo i numeri di versione interni di Windows, vedi
https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

Attualmente sono supportati da NT 5.2 a NT 6.3.

Vedere "WINDOWS" di seguito per ulteriori note sulla conversione dei guest Windows.

GUEST firmware
BIOS o UEFI per tutti i tipi di guest (ma vedere "UEFI" di seguito).

VERSIONI

--Aiuto
Mostra aiuto.

-b ...
--ponte ...
See --Rete qua sotto.

--compresso
Scrivi un file di output compresso. Ciò è consentito solo se il formato di output è qcow2
(Vedi -Di sotto), ed è equivalente a -c possibilità di qemu-img(1).

--dcpath Cartella/Centro dati
NB: Non è necessario utilizzare questo parametro se si dispone di libvirt ≥ 1.2.20.

Per VMware vCenter, sovrascrivere il parametro "dcPath=..." utilizzato per selezionare il data center.
Virt-v2v di solito può calcolarlo dall'URI "vpx://", ma se si sbaglia,
quindi puoi sovrascriverlo usando questa impostazione. Vai all'interfaccia della cartella Web di vCenter,
per esempio. "https://vcenter.example.com/cartella" (senza una barra finale), ed esaminare il
parametro "dcPath=" negli URL che appaiono in questa pagina.

--debug-gc
Eseguire il debug di Garbage Collection e allocazione della memoria. Questo è utile solo durante il debug
problemi di memoria in virt-v2v o nei collegamenti OCaml libguestfs.

--debug-overlay
Salva i file overlay creati durante la conversione. Questa opzione è usata solo per
debugging virt-v2v e potrebbe essere rimosso in una versione futura.

-i disco
Imposta il metodo di immissione su disco.

In questa modalità puoi leggere un'immagine del disco di una macchina virtuale senza metadati. virt-v2v
cerca di indovinare i migliori metadati predefiniti. Questo di solito è adeguato ma puoi ottenerlo
controllo più preciso (ad es. di memoria e vCPU) utilizzando -i libvirtxml Invece. Solo ospiti
che utilizzano un singolo disco possono essere importati in questo modo.

-i libvirt
Imposta il metodo di immissione su libvirt. Questa è l'impostazione predefinita.

In questa modalità devi specificare un nome guest libvirt o un UUID sulla riga di comando.
Puoi anche specificare un URI di connessione libvirt (vedi -circuito integrato).

-i libvirtxml
Imposta il metodo di immissione su libvirtxml.

In questa modalità devi passare un file XML libvirt sulla riga di comando. Questo file è
leggere per ottenere i metadati sull'ospite di origine (come il nome, la quantità di
memoria) e anche per individuare i dischi di input. Vedere "XML MINIMO PER -i libvirtxml
OPZIONE" di seguito.

-i locale
Questo è lo stesso di -i disco.

-i ovuli
Imposta il metodo di immissione su ovuli.

In questa modalità puoi leggere un file ova VMware. Virt-v2v leggerà il file manifest ova
e controlla la validità dei volumi vmdk (checksum) e analizza il file ovf,
e quindi convertire l'ospite. Vedere "INPUT DA VMWARE OVA" di seguito

-circuito integrato libvirtURI
Specificare un URI di connessione libvirt da utilizzare durante la lettura del guest. Questo è usato solo
quando -i libvirt.

Solo connessioni libvirt locali, connessioni VMware vCenter o RHEL 5 Xen remote
è possibile utilizzare i collegamenti. Altre connessioni libvirt remote non funzioneranno in generale.

Vedere anche "INPUT DA VMWARE VCENTER SERVER", "INPUT FROM RHEL 5 XEN" di seguito.

-Se formato
Da -i disco solo, questo specifica il formato dell'immagine del disco di input. Per altri input
metodi è necessario specificare il formato di input nei metadati.

--a posto
Non creare una macchina virtuale di output nell'hypervisor di destinazione. Invece, regolare il
sistema operativo guest nella VM di origine da eseguire nell'hypervisor di input.

Questa modalità è pensata per l'integrazione con altri set di strumenti, che si assumono la responsabilità
di convertire la configurazione della VM, prevedendo il rollback in caso di errori,
trasformare il magazzino, ecc.

Conflitti con tutti -o * opzioni.

--leggibile dalla macchina
Questa opzione viene utilizzata per rendere l'output più adatto alla macchina quando viene analizzato da
altri programmi. Vedere "USCITA LEGGIBILI DALLA MACCHINA" di seguito.

-n dentro fuori
-n su
--Rete dentro fuori
--Rete su
-b dentro fuori
-b su
--ponte dentro fuori
--ponte su
Mappa la rete (o bridge) chiamata "in" alla rete (o bridge) chiamata "out". Se no "in:"
viene dato il prefisso, tutte le altre reti (o bridge) sono mappate su "out".

Vedere "RETI E PONTI" di seguito.

--no-copia
Non copiare i dischi. Invece, la conversione viene eseguita (e gettata via), e
vengono scritti i metadati, ma non vengono creati i dischi. Vedi anche la discussione su -o nullo qua sotto.

Questo è utile in due casi: vuoi testare se la conversione è probabile
avere successo, senza il lungo processo di copia. Oppure ti interessa solo guardare
i metadati.

Questa opzione non è compatibile con -o libvirt poiché creerebbe un ospite difettoso
(uno senza dischi).

Questa opzione non è compatibile con -o sguardo per motivi tecnici.

--nessun taglio contro tutti i
--nessun taglio mp[,mp...]
Per impostazione predefinita viene eseguito virt-v2v FSTR(8) per ridurre la quantità di dati che deve essere
copiato. Questo è noto per rompere alcuni bootloader difettosi che causano errori di avvio dopo
conversione (vedi ad esempio https://bugzilla.redhat.com/show_bug.cgi?id=1141145#c27).

Puoi usare --nessun taglio contro tutti i per disabilitare tutti i tagli. Nota che questo aumenterà notevolmente
la quantità di dati che deve essere copiata e può far funzionare virt-v2v molto più lentamente.

Puoi anche disabilitare il taglio solo su filesystem selezionati (specificato da una virgola-
elenco separato dei punti di montaggio nel guest). Normalmente useresti
--nessun taglio /avvio per aggirare il bug di grub menzionato sopra.

Puoi anche disabilitare il taglio sulle partizioni usando lo schema di denominazione libguestfs per
dispositivi, ad esempio: --nessun taglio / dev / sdb2 significa non tagliare la seconda partizione sulla seconda
dispositivo di blocco. Utilizzo filesystem-virt(1) per elencare i nomi del filesystem in un guest.

-o disco
Questo è lo stesso di -o locale.

-o sguardo
Imposta il metodo di output su OpenStack Glance. In questa modalità l'ospite convertito è
caricato su Glance. È possibile controllare il nome dell'immagine impostando il -One opzione.

-o libvirt
Imposta il metodo di output su libvirt. Questa è l'impostazione predefinita.

In questa modalità, il guest convertito viene creato come guest libvirt. Puoi anche specificare
un URI di connessione libvirt (vedi -oc).

Vedere "OUTPUT A LIBVIRT" di seguito.

-o locale
Imposta il metodo di output su locale.

In questa modalità, il guest convertito viene scritto in una directory locale specificata da Hong osseo
/dir (la directory deve esistere). I dischi del guest convertito sono scritti come:

/dir/nome-sda
/dir/nome-sdb
[eccetera]

e viene creato un file XML libvirt contenente i metadati del guest:

/dir/nome.xml

dove "nome" è il nome dell'ospite.

-o nullo
Imposta il metodo di output su nullo.

L'ospite viene convertito e copiato (a meno che non specifichi anche tu --no-copia), ma i risultati
vengono gettati via e non vengono scritti metadati.

-o ovirt
Questo è lo stesso di -o revi.

-o whoa
Imposta il metodo di output su whoa.

Questo è simile a -o locale, tranne per il fatto che è scritto uno script di shell che puoi usare
per avviare il guest in qemu. I dischi convertiti e lo script della shell vengono scritti nel
directory specificata da Hong osseo.

Quando si utilizza questa modalità di output, è anche possibile specificare il --qemu-boot opzione che stivali
l'ospite sotto qemu immediatamente.

-o revi
Imposta il metodo di output su revi.

Il guest convertito viene scritto in un RHEV Export Storage Domain. Il Hong osseo parametro
deve essere utilizzato anche per specificare la posizione dell'Export Storage Domain. Nota questo
non importa effettivamente il guest in RHEV. Devi farlo manualmente più tardi
utilizzando l'interfaccia utente.

Vedere "USCITA A RHEV" di seguito.

-o vdsm
Imposta il metodo di output su vdsm.

Questa modalità è simile a -o revi, ma deve essere fornito il percorso completo al dominio dei dati:
/rhev/data-center/ /. Questa modalità viene utilizzata solo quando
virt-v2v viene eseguito sotto il controllo di VDSM.

-oh scarso
-oh preallocato
Imposta la modalità di allocazione del file di output. L'impostazione predefinita è "sparsa".

-oc libvirtURI
Specificare una connessione libvirt da utilizzare durante la scrittura del guest convertito. Questo è solo
usato quando -o libvirt. Vedere "OUTPUT A LIBVIRT" di seguito.

È possibile utilizzare solo connessioni libvirt locali. Le connessioni libvirt remote non funzioneranno.

-Di formato
Quando si converte il guest, convertire i dischi nel formato specificato.

Se non specificato, viene utilizzato il formato di input.

-One Nome
Rinominare il guest durante la conversione. Se questa opzione non viene utilizzata, il nome dell'output
è uguale al nome di input.

Hong osseo conservazione
La posizione dell'archiviazione per l'ospite convertito.

Da -o libvirt, questo è un pool di directory libvirt (vedi "virsh pool-list") o UUID del pool.

Da -o locale e -o whoa, questo è un nome di directory. La directory deve esistere.

Da -o revi, questo può essere un percorso NFS dell'Export Storage Domain del modulo
" : ", per esempio:

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

L'esportazione NFS deve essere montabile e scrivibile dall'utente e dall'host che esegue virt-v2v,
poiché il programma virt-v2v deve effettivamente montarlo quando viene eseguito. Quindi probabilmente
devi eseguire virt-v2v come "root".

Oppure: Puoi montare tu stesso il dominio di archiviazione di esportazione e puntare Hong osseo al punto di montaggio.
Nota che virt-v2v dovrà comunque scrivere in questa directory remota, quindi virt-v2v lo farà
deve ancora essere eseguito come "root".

Riceverai un errore se virt-v2v non è in grado di montare/scrivere nell'archivio di esportazione
Dominio.

--file-password filetto
Invece di chiedere le password in modo interattivo, passa la password attraverso un file.
Nota che il file dovrebbe contenere l'intera password, senza in qualsiasi finale nuova linea, E per
sicurezza il file dovrebbe avere la modalità 0600 in modo che altri non possano leggerlo.

--print-source
Stampa le informazioni sull'ospite di origine e fermati. Questa opzione è utile quando lo sei
creazione di mappe di rete e bridge. Vedi "RETI E PONTI".

--qemu-boot
Quando si usa -o whoa solo, questo avvia il guest immediatamente dopo che virt-v2v finisce.

-q
--silenzioso
Questo disabilita le barre di avanzamento e altri output non necessari.

--radice chiedere
--radice singolo
--radice prima di tutto
--radice / Dev / sdX
--radice /dev/VG/LV
Scegli il filesystem di root da convertire.

Nel caso in cui la macchina virtuale sia dual-boot o multi-boot, o dove la VM abbia
altri filesystem che sembrano sistemi operativi, questa opzione può essere usata per selezionare
il filesystem di root (noto anche come unità "C:" o /) del sistema operativo che deve essere
convertito. La Console di ripristino di emergenza di Windows, alcune unità DVD collegate e i bug in
L'euristica dell'ispezione di libguestfs può far sembrare un ospite un multi-boot operativo
.

L'impostazione predefinita in virt-v2v ≤ 0.7.1 era --root singolo, che fa morire virt-v2v se a
viene trovato il sistema operativo ad avvio multiplo.

Poiché virt-v2v ≥ 0.7.2 l'impostazione predefinita è ora --root ask: se la VM risulta essere multi-
boot, quindi virt-v2v si fermerà ed elencherà i possibili filesystem di root e chiederà all'utente
quale usare. Ciò richiede che virt-v2v venga eseguito in modo interattivo.

--root prima significa scegliere il primo dispositivo root in caso di multi-boot
sistema operativo. Poiché si tratta di un'euristica, a volte può scegliere quella sbagliata.

Puoi anche nominare un dispositivo root specifico, ad es. --root /dev/sda2 significherebbe usare il
seconda partizione sul primo disco rigido. Se il dispositivo root indicato non esiste o
non è stato rilevato come dispositivo root, quindi virt-v2v avrà esito negativo.

Nota che c'è un bug in grub che gli impedisce di avviare con successo a
sistema multiboot se VirtIO è abilitato. Grub è in grado di avviare solo un sistema operativo
dal primo disco VirtIO. Nello specifico, /avvio deve essere sul primo disco VirtIO e
non può caricare in catena un sistema operativo che non si trova nel primo disco VirtIO.

--vdsm-immagine-uuid UUID
--vdsm-vol-uuid UUID
--vdsm-vm-uuid UUID
--vdsm-ovf-uscita
Normalmente la modalità di output RHEV sceglie UUID casuali per il guest di destinazione. Tuttavia VDSM
ha bisogno di controllare gli UUID e passa questi parametri quando virt-v2v viene eseguito sotto VDSM
controllo. I parametri controllano:

· la directory delle immagini di ogni disco ospite (--vdsm-immagine-uuid) (questa opzione è passata
una volta per ogni disco ospite)

· UUID per ogni disco ospite (--vdsm-vol-uuid) (questa opzione viene passata una volta per ciascuno
disco ospite)

· il nome del file OVF (--vdsm-vm-uuid).

· la directory di output OVF (directory corrente predefinita) (--vdsm-ovf-uscita).

Il formato degli UUID è: "12345678-1234-1234-1234-123456789abc" (ogni cifra esadecimale può essere
"0-9" o "af"), conforme a OSF DCE 1.1.

Queste opzioni possono essere utilizzate solo con -o vdsm.

-v
--verboso
Abilita messaggi dettagliati per il debug.

-V
--versione
Visualizza il numero di versione ed esci.

--vmtipo tavolo
--vmtipo server
Per la -o revi or -o vdsm solo target, specificare il tipo di ospite. Puoi impostare questo
su "desktop" o "server". Se l'opzione non viene data, allora un valore predefinito adatto è
scelto in base al sistema operativo guest rilevato.

-x Abilita la traccia delle chiamate API libguestfs.

XEN PARAVIRTUALIZZATO OSPITI

Le versioni precedenti di virt-v2v potrebbero trasformare un ospite paravirtualizzato (PV) Xen in un ospite KVM
installazione di un nuovo kernel. Questa versione di virt-v2v lo fa non è un tentare di installare qualsiasi nuovo
kernel. Invece ti darà un errore se ci sono esclusivamente Disponibili kernel fotovoltaici Xen.

Quindi prima della conversione dovresti controllare che sia installato un kernel regolare. Per alcuni
distribuzioni Linux precedenti, questo significa installare un kernel dalla tabella seguente:

RHEL 3 (Non si applica, poiché non c'era il kernel Xen PV)

RHEL 4 i686 con > 10 GB di RAM: installa 'kernel-hugemem'
i686 SMP: installa 'kernel-smp'
altro i686: installa 'kernel'
x86-64 SMP con > 8 CPU: installa 'kernel-largesmp'
x86-64 SMP: installa 'kernel-smp'
altro x86-64: installa 'kernel'

RHEL 5 i686: installa 'kernel-PAE'
x86-64: installa 'kernel'

SLES 10 i586 con > 10 GB di RAM: installa 'kernel-bigsmp'
i586 SMP: installa 'kernel-smp'
altro i586: installa 'kernel-default'
x86-64 SMP: installa 'kernel-smp'
altro x86-64: installa 'kernel-default'

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

Windows (non si applica, poiché non esiste un kernel Windows Xen PV)

ABILITARE VIRTÙ

"Virtio" è il nome di un insieme di driver che rendono il disco (dispositivo a blocchi), la rete e
altre operazioni guest funzionano molto più velocemente su KVM.

Le versioni precedenti di virt-v2v potrebbero installare questi driver per determinati guest Linux. Questo
la versione di virt-v2v lo fa non è un tenterà di installare nuovi kernel o driver Linux, ma lo farà
avvisarti se non sono già installati.

Al fine di abilitare virtio, e quindi migliorare le prestazioni dell'ospite dopo la conversione,
dovresti assicurarti che ordine le versioni dei pacchetti sono installate prima conversione,
consultando la tabella sottostante.

RHEL 3 Non sono disponibili driver virtio

RHEL 4 kernel >= 2.5.9-89.EL
lvm2 >= 2.02.42-5.el4
dispositivo mappatore >= 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+ Tutte le versioni supportano virtio

Fedora Tutte le versioni supportano virtio

SLES 11+ Tutte le versioni supportano virtio

SLES 10 kernel >= 2.6.16.60-0.85.1

OpenSUSE 11+ Tutte le versioni supportano virtio

kernel OpenSUSE 10 >= 2.6.25.5-1.1

I driver di Windows vengono installati dalla directory puntata da
Variabile d'ambiente "VIRTIO_WIN"
(/usr/share/virtio-win per impostazione predefinita) se presente

RHEL 4

SELinux rietichettare appare a appendere per sempre
In RHEL ≤ 4.7 c'era un bug che faceva sembrare che la rietichettatura di SELinux si bloccasse per sempre
al seguente indirizzo:

*** Avvertenza: è richiesta la rietichettatura di SELinux. ***
*** Disabilitazione dell'applicazione della sicurezza. ***
*** La rietichettatura potrebbe richiedere molto tempo, ***
*** a seconda delle dimensioni del file system. ***

In realtà sta aspettando che tu prema un tasto (ma non c'è nessuna indicazione visiva di
questo). Puoi premere il tasto "[Invio]", a quel punto l'ospite finirà
rietichettatura e riavviare, oppure è possibile installare policycoreutils ≥ 1.18.1-4.13 prima di iniziare
la conversione v2v. Vedi anche https://bugzilla.redhat.com/show_bug.cgi?id=244636

FINESTRE

stivale fallimento: 0x0000007B
Questo errore di avvio è causato dal fatto che Windows non è in grado di trovare o caricare il driver del disco corretto
(per esempio. viostor.sys). Se riscontri questo errore, ecco alcune cose da controllare:

· Innanzitutto assicurarsi che il guest si avvii sull'hypervisor di origine prima della conversione.

· Verifica di avere i driver virtio di Windows disponibili in /usr/share/virtio-win, e quello
virt-v2v non ha stampato alcun avviso sull'impossibilità di installare i driver virtio.

Su Red Hat Enterprise Linux 7, dovrai installare i driver firmati disponibili
nel pacchetto "virtio-win". Se non hai accesso ai driver firmati, allora
probabilmente dovrai disabilitare la firma del driver nei menu di avvio.

· Verificare di presentare un'interfaccia virtio-blk (non è un virtio-scsi e non è un ide) a
l'ospite. Sulla riga di comando qemu/KVM dovresti vedere qualcosa di simile a questo:

... -drive file=windows-sda,if=virtio ...

In libvirt XML, dovresti vedere:



· Verificare che i Criteri di gruppo di Windows non impediscano l'installazione del driver o
Usato. Prova a eliminare i Criteri di gruppo di Windows prima della conversione.

· Verificare che non siano presenti antivirus o altri software che implementano criteri di gruppo simili
divieti di installazione o utilizzo di nuovi driver.

· Abilita il debug di avvio e controlla il viostor.sys il driver è in fase di caricamento.

OpenStack e Windows riattivazione
OpenStack non offre indirizzi PCI/dispositivi stabili agli ospiti. Ogni volta che crea
o avvia un guest, rigenera da zero l'XML di libvirt per quel guest. Il
libvirt XML non avrà campi. Libvirt assegnerà quindi gli indirizzi ai dispositivi,
in maniera prevedibile. Gli indirizzi possono cambiare se si verifica una delle seguenti condizioni:

· Un nuovo disco o dispositivo di rete è stato aggiunto o rimosso dal guest.

· La versione di OpenStack o (possibilmente) di libvirt è cambiata.

Poiché a Windows non piacciono le modifiche "hardware" di questo tipo, potrebbe attivare Windows
riattivazione.

Questo può anche impedire l'avvio con un errore 7B [vedi sezione precedente] se il guest ha
criteri di gruppo contenenti "Restrizioni per l'installazione del dispositivo".

UEFI

VMware consente di presentare il firmware UEFI ai guest (invece del normale BIOS del PC).
Virt-v2v può convertire questi guest, ma richiede che UEFI sia supportato dal target
ipervisore.

Attualmente KVM supporta OVMF, un firmware UEFI parzialmente open source, e può eseguirli
ospiti.

Poiché il supporto OVMF è stato aggiunto solo di recente a KVM (nel 2014/2015), non tutti gli obiettivi
gli ambienti supportano ancora gli ospiti UEFI:

UEFI su libvirt, qemu
Supportato. Virt-v2v genererà automaticamente il corretto XML libvirt (metadati),
ma tieni presente che la stessa versione di OVMF deve essere installata sull'host di conversione così com'è
installato sull'hypervisor di destinazione, altrimenti dovrai regolare i percorsi nel
metadati.

UEFI su OpenStack
Non supportato.

UEFI su RHEV
Non supportato.

NETWORKS E Colmare il divario

Gli ospiti sono generalmente connessi a una o più reti e quando vengono convertiti nel target
hypervisor di solito si desidera riconnettere quelle reti nella destinazione. Le opzioni
--Rete e --ponte ti permetta di farlo.

Se non sei sicuro di quali reti e bridge siano in uso sull'hypervisor di origine, allora
puoi esaminare i metadati di origine (libvirt XML, informazioni vCenter, ecc.). O puoi
eseguire virt-v2v con il --print-source opzione che fa in modo che virt-v2v stampi la
le informazioni che ha sull'ospite sulla fonte e poi esci.

Nel --print-source output vedrai una sezione che mostra l'interfaccia di rete del guest
Schede (NIC):

$ virt-v2v [-i ...] --print-nome sorgente
[...]
NIC:
Rete "predefinita" mac: 52:54:00:d0:cf:0e

Questo è tipico di un guest libvirt: ha un'unica interfaccia di rete connessa a a
rete denominata "predefinita".

Per mappare una rete specifica su una rete di destinazione, ad esempio "predefinito" sull'origine per
"rhevm" sul bersaglio, usa:

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

Per mappare ogni rete a una rete di destinazione, utilizzare:

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

I bridge sono gestiti allo stesso modo, ma devi usare il --ponte opzione invece. Per
esempio:

$ virt-v2v [-i ...] --print-nome sorgente
[...]
NIC:
Ponte "br0"

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

INGRESSO DA VMWARE VENTER SERVER

Virt-v2v è in grado di importare ospiti da VMware vCenter Server.

È richiesto vCenter ≥ 5.0. Se non disponi di vCenter, ti consigliamo di utilizzare OVA
(vedi "INPUT FROM VMWARE OVA" di seguito), o se ciò non è possibile, vedi "INPUT FROM
VMWARE ESXi HYPERVISOR".

Virt-v2v utilizza libvirt per l'accesso a vCenter e quindi la modalità di input dovrebbe essere -i
libvirt. Poiché questa è l'impostazione predefinita, non è necessario specificarla nella riga di comando.

VCENTRO: RIMUOVERE VMWARE TOOLS DA FINESTRE OSPITI
Per i guest Windows, è necessario rimuovere gli strumenti VMware prima della conversione. Anche se questo è
non strettamente necessario, e l'ospite sarà comunque in grado di correre, se non lo fai allora
l'ospite convertito si lamenterà ad ogni avvio. Gli strumenti non possono essere rimossi dopo
conversione perché il programma di disinstallazione controlla se è in esecuzione su VMware e si rifiuta di avviarsi
(che è anche il motivo per cui virt-v2v non può rimuoverli).

Questo non è necessario per i guest Linux, poiché virt-v2v è in grado di rimuovere gli strumenti VMware.

VCENTRO: URI
L'URI libvirt di un server vCenter è simile a questo:

vpx://utente@server/Datacenter/esxi

dove:

"utente@"
è l'utente (facoltativo, ma consigliato) con cui connettersi.

Se il nome utente contiene una barra rovesciata (es. "DOMINIO\UTENTE"), sarà necessario URI-
sfuggire a quel carattere usando %5c: "DOMAIN%5cUSER" (5c è il codice ASCII esadecimale per
barra rovesciata.) Potrebbe essere necessario sfuggire anche ad altri segni di punteggiatura.

"server"
è il server vCenter (non è un ipervisore).

"Banca dati"
è il nome del datacenter.

Se il nome contiene uno spazio, sostituiscilo con il codice di escape URI %20.

"esxi"
è il nome dell'hypervisor ESXi che esegue il guest.

Se la distribuzione VMware utilizza cartelle, potrebbe essere necessario aggiungerle all'URI, ad esempio:

vpx://utente@server/Cartella/Datacenter/esxi

Per i dettagli completi sugli URI di libvirt, vedere: http://libvirt.org/drvesx.html

Errori tipici da libvirt / virsh quando l'URI è sbagliato includono:

· Impossibile trovare il data center specificato [...]

· Impossibile trovare la risorsa di calcolo specificata [...]

· Il percorso [...] non specifica una risorsa di calcolo

· Il percorso [...] non specifica un sistema host

· Impossibile trovare il sistema host specificato [...]

VCENTRO: TEST LIBVIRTA COLLEGAMENTO A VENTER
Usa il vergognoso(1) comando per elencare i guest sul vCenter Server in questo modo:

$ virsh -c 'vpx://[email protected]/Datacenter/esxi' list --all
Inserisci la password di root per vcenter.example.com: ***

ID Nome Stato
-------------------------------------------------- -
- Fedora 20 spento
- Windows 2003 spento

Se ricevi un errore "Il certificato peer non può essere autenticato con determinati certificati CA"
o simili, puoi importare il certificato dell'host vCenter o ignorare la firma
verifica aggiungendo il flag "?no_verify=1":

$ virsh -c 'vpx://[email protected]/Datacenter/esxi?no_verify=1' list --all

Dovresti anche provare a scaricare i metadati da qualsiasi guest sul tuo server, in questo modo:

$ virsh -c 'vpx://[email protected]/Datacenter/esxi' dumpxml "Windows 2003"

Windows 2003
[...]


If , il sopra comandi do non è un lavoro, poi virt-v2v is non è un andando a lavoro o. Ripara il tuo
configurazione di libvirt e/o il tuo server VMware vCenter prima di continuare.

VCENTRO: IMPORTAZIONE A OSPITE
Per importare un particolare guest da vCenter Server, procedi nel seguente modo:

$ virt-v2v -ic 'vpx://[email protected]/Datacenter/esxi?no_verify=1' \
"Windows 2003" \
-o locale -os / Var / tmp

dove "Windows 2003" è il nome del guest (che deve essere spento).

Tieni presente che potrebbe essere richiesta la password di vCenter due volte. Questo succede una volta perché
libvirt ne ha bisogno, e una seconda volta perché virt-v2v stesso si connette direttamente al
server. Utilizzo --file-password per fornire una password tramite un file.

In questo caso i flag di output sono impostati per scrivere il guest convertito in un temporaneo
directory in quanto questo è solo un esempio, ma puoi anche scrivere su libvirt o qualsiasi altro
obiettivo supportato.

VCENTRO: NON AMMINISTRATORE RUOLO
Invece di utilizzare il ruolo di vCenter Administrator, puoi creare un non amministratore personalizzato
ruolo per eseguire la conversione. Dovrai comunque dargli un set minimo di
autorizzazioni come segue:

1. Creare un ruolo personalizzato in vCenter.

2. Abilitare (selezionare) i seguenti oggetti:

Archivio dati:
- Sfoglia l'archivio dati
- Operazioni sui file di basso livello

Sessione:
- Convalida sessione

Macchina virtuale:
Approvvigionamento:
- Consenti l'accesso al disco
- Consenti l'accesso al disco in sola lettura
- Gestione del sistema operativo ospite tramite API VIX

INGRESSO DA VMWARE OVA

Virt-v2v è in grado di importare guest dai file OVA (Open Virtualization Appliance) di VMware.
Funzioneranno solo gli OVA esportati da VMware vSphere.

OAV: RIMUOVERE VMWARE TOOLS DA FINESTRE OSPITI
Per i guest Windows, è necessario rimuovere gli strumenti VMware prima della conversione. Anche se questo è
non strettamente necessario, e l'ospite sarà comunque in grado di correre, se non lo fai allora
l'ospite convertito si lamenterà ad ogni avvio. Gli strumenti non possono essere rimossi dopo
conversione perché il programma di disinstallazione controlla se è in esecuzione su VMware e si rifiuta di avviarsi
(che è anche il motivo per cui virt-v2v non può rimuoverli).

Questo non è necessario per i guest Linux, poiché virt-v2v è in grado di rimuovere gli strumenti VMware.

OAV: CREA OVA
Per creare un OVA in vSphere, usa l'opzione "Esporta modello OVF" (dal contesto VM
menu o dal menu File). O "Cartella di file" (OVF) o "File singolo" (OVA) sarà
lavoro, ma OVA è probabilmente più facile da affrontare. I file OVA sono in realtà solo tar non compressi
file, quindi puoi usare comandi come "tar tf VM.ova" per visualizzare il loro contenuto.

Creare OVA con strumento

Puoi anche utilizzare "ovftool" proprietario di VMware:

ovftool --noSSLVerify \
vi://UTENTE:[email protected]/VM\
VM.ova

Per connettersi a vCenter:

ovftool --noSSLVerify \
vi://UTENTE:[email protected]/NOME-CENTRO DATI/vm/VM \
VM.ova

Per l'autenticazione basata su Active Directory, è necessario esprimere il carattere "@" nel
forma del suo codice esadecimale ascii (%5c):

vi://DOMINIO%5cUTENTE:PASSWORD@...

OAV: IMPORTAZIONE A OSPITE
Per importare un file OVA chiamato VM.ova, fare;

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

Se hai esportato il guest come "Cartella di file", or se hai decompresso il tarball OVA
te stesso, quindi puoi puntare virt-v2v nella directory contenente i file:

$ virt-v2v -i ova /percorso/ai/file -o local -os / Var / tmp

INGRESSO DA VMWARE ESXi IPERVISORE

Virt-v2v non può accedere direttamente a un hypervisor ESXi. Dovresti usare il metodo OVA sopra
(vedi "INPUT DA VMWARE OVA") se possibile, in quanto è molto più veloce e richiede molto meno
spazio su disco rispetto al metodo descritto in questa sezione.

È possibile utilizzare il virt-v2v-copia-in-locale(1) strumento per copiare il guest dall'hypervisor in a
file locale, quindi convertirlo.

ESXi: RIMUOVERE VMWARE TOOLS DA FINESTRE OSPITI
Per i guest Windows, è necessario rimuovere gli strumenti VMware prima della conversione. Anche se questo è
non strettamente necessario, e l'ospite sarà comunque in grado di correre, se non lo fai allora
l'ospite convertito si lamenterà ad ogni avvio. Gli strumenti non possono essere rimossi dopo
conversione perché il programma di disinstallazione controlla se è in esecuzione su VMware e si rifiuta di avviarsi
(che è anche il motivo per cui virt-v2v non può rimuoverli).

Questo non è necessario per i guest Linux, poiché virt-v2v è in grado di rimuovere gli strumenti VMware.

ESXi: URI
L'URI libvirt per gli hypervisor VMware ESXi sarà simile a questo:

esx://[email protected]?no_verify=1

Il parametro "?no_verify=1" disabilita il controllo del certificato TLS.

ESXi: TEST LIBVIRTA COLLEGAMENTO A ESXi IPERVISORE
Usa il vergognoso(1) comando per testare l'URI ed elencare i guest remoti disponibili:

$ versh -c esx://[email protected]?no_verify=1 lista --all
Inserisci la password di root per esxi.example.com: ***
ID Nome Stato
-------------------------------------------------- -
- ospite spento

ESXi: COPIA IL OSPITE A IL LOCALE MACCHINA
Usando l'URI libvirt come -circuito integrato opzione, copiare uno dei guest sulla macchina locale:

$ virt-v2v-copia-in-locale -ic esx://[email protected]?no_verify=1 ospite

Questo crea ospite.xml, disco-ospite1...

ESXi: DO IL VIRT-V2V CONVERSIONE
Esegui la conversione del guest usando virt-v2v:

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

ESXi: PULIZIA UP
Rimuovi il ospite.xml e disco-ospite* File.

INGRESSO DA RHEL 5 XEN

Virt-v2v è in grado di importare guest Xen da host RHEL 5 Xen.

Virt-v2v utilizza libvirt per l'accesso all'host Xen remoto, e quindi la modalità di input
dovrebbe essere -i libvirt. Poiché questa è l'impostazione predefinita, non è necessario specificarla nel comando
linea.

XENE: SET UP SSH-AGENTE ACCESSO A XEN HOST
Attualmente è necessario abilitare l'accesso SSH senza password all'host Xen remoto da virt-v2v
server di conversione.

Devi anche usare ssh-agent e aggiungere la tua chiave pubblica ssh a /root/.ssh/chiavi_autorizzate (sopra
l'ospite Xen).

Dopo averlo fatto, dovresti controllare che l'accesso senza password funzioni dal server virt-v2v
all'ospite Xen. Per esempio:

$ ssh [email protected]
[ accede direttamente alla shell, non viene richiesta alcuna password ]

Nota che l'accesso interattivo con password e Kerberos è non è un supportato. Voi avere impostare
accesso ssh utilizzando ssh-agent e authorized_keys.

XENE: TEST LIBVIRTA COLLEGAMENTO A REMOTE XEN HOST
Usa il vergognoso(1) comando per elencare i guest sull'host Xen remoto:

$ virsh -c xen+ssh://[email protected] lista --tutto
ID Nome Stato
-------------------------------------------------- -
0 Dominio-0 in esecuzione
- rhel49-x86_64-pv spento

Dovresti anche provare a scaricare i metadati da qualsiasi guest sul tuo server, in questo modo:

$ virsh -c xen+ssh://[email protected] dumpxml rhel49-x86_64-pv

rhel49-x86_64-pv
[...]


If , il sopra comandi do non è un lavoro, poi virt-v2v is non è un andando a lavoro o. Ripara il tuo
configurazione di libvirt o il server remoto prima di continuare.

If , il ospite dischi sono collocato on a host bloccare dispositivo, la conversione avrà esito negativo. Vedere
"CONVERSIONI XEN O SSH DA DISPOSITIVI A BLOCCO" di seguito per una soluzione alternativa.

XENE: IMPORTAZIONE A OSPITE
Per importare un particolare guest da un server Xen, fai:

$ virt-v2v -ic 'xen+ssh://[email protected]'\
rhel49-x86_64-pv \
-o locale -os / Var / tmp

dove "rhel49-x86_64-pv" è il nome del guest (che deve essere spento).

In questo caso i flag di output sono impostati per scrivere il guest convertito in un temporaneo
directory in quanto questo è solo un esempio, ma puoi anche scrivere su libvirt o qualsiasi altro
obiettivo supportato.

XEN OR SSH CONVERSIONI DA BLOCCO DISPOSITIVI
Attualmente virt-v2v non può accedere direttamente a un guest Xen (oa qualsiasi guest situato in remoto su
ssh) se i dischi di quel guest si trovano su dispositivi a blocchi host.

Per sapere se un guest Xen utilizza dispositivi a blocchi host, guarda l'XML del guest. Vedrai:


...


dove "type='block'", "source dev=" e "/dev/..." sono tutte indicazioni che il disco è
situato su un dispositivo a blocchi host.

Questo accade perché il driver qemu ssh block che usiamo per accedere ai dischi remoti usa il
ssh protocollo sftp e questo protocollo non è in grado di rilevare correttamente la dimensione del blocco host
dispositivi.

La soluzione alternativa consiste nel copiare il guest sul server di conversione, utilizzando il separato
virt-v2v-copia-in-locale(1) strumento, seguito dall'esecuzione di virt-v2v. Avrai bisogno di abbastanza
spazio sul server di conversione per memorizzare una copia completa del guest.

virt-v2v-copia-in-locale -ic xen+ssh://[email protected] ospite
virt-v2v -i libvirtxml guest.xml -o local -os / Var / tmp
rm guest.xml disco-ospite*

USCITA A LIBVIRTA

. -o libvirt L'opzione ti consente di caricare il guest convertito su un host gestito da libvirt.
Ci sono diverse limitazioni:

· È possibile utilizzare solo una connessione libvirt locale [vedi sotto per come aggirare questo problema].

· Il Hong osseo pool l'opzione deve specificare un pool di directory, non qualcosa di più esotico come
iSCSI [ma vedi sotto].

· È possibile caricare solo su un hypervisor KVM.

A produzione a a a distanza libvirt esempio e / o a non directory conservazione pool devi usare
la seguente soluzione alternativa:

1. Usa virt-v2v in -o locale modalità per convertire i dischi guest e i metadati in un locale
cartella temporanea:

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

Questo crea due (o più) file in / Var / tmp chiamato:

/var/tmp/NAME.xml # XML di libvirt (metadati)
/var/tmp/NAME-sda # il primo disco del guest

(per "NOME" sostituire il nome dell'ospite).

2. Caricare i dischi convertiti nello storage pool chiamato "POOL":

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

3. modificare /var/tmp/NOME.xml cambiare /var/tmp/NOME-sda al nome della piscina. In altre parole,
individuare il seguente bit di XML:







e cambia due cose: l'attributo "type='file'" deve essere cambiato in "type='volume'",
e il " " elemento deve essere modificato per includere gli attributi "pool" e "volume":


...

...


4. Definire l'ospite finale in libvirt:

virsh definisce /var/tmp/NAME.xml

USCITA A rev

Questa sezione si applica solo a -o revi modalità di uscita. Se usi virt-v2v dal RHEV-M
interfaccia utente, quindi dietro le quinte l'importazione è gestita da VDSM utilizzando il -o vdsm
modalità di output (che gli utenti finali non dovrebbero provare a utilizzare direttamente).

Devi specificare -o revi e Hong osseo opzione che punta all'archivio di esportazione RHEV-M
Dominio. Puoi specificare il server NFS e il punto di montaggio, ad es.
"-os rhev-storage:/rhev/export", oppure puoi montarlo prima e puntare alla directory
dove è montato, ad es. "-os /tmp/mnt". Fare attenzione a non puntare al Data Storage
Dominio per caso in quanto non funzionerà.

In caso di completamento con successo, virt-v2v avrà scritto il nuovo ospite nell'archivio di esportazione
Dominio, ma non sarà ancora pronto per l'esecuzione. Deve essere importato in RHEV utilizzando l'interfaccia utente
prima che possa essere usato.

In RHEV ≥ 2.2 questo viene fatto dalla scheda Archiviazione. Seleziona il dominio di esportazione dell'ospite
scritto a. Apparirà un riquadro sotto l'elenco dei domini di archiviazione che ne mostra diversi
schede, una delle quali è "Importazione VM". L'ospite convertito verrà elencato qui. Seleziona il
ospite appropriato fare clic su "Importa". Vedere la documentazione RHEV per ulteriori dettagli.

Se esporti più ospiti, puoi importarli tutti contemporaneamente tramite il
UI.

RISORSE REQUISITI

Network
La risorsa più importante per virt-v2v sembra essere la larghezza di banda della rete. Virt-v2v dovrebbe
essere in grado di copiare i dati degli ospiti a velocità Gigabit Ethernet o superiori.

Assicurarsi che le connessioni di rete tra i server (server di conversione, server NFS,
vCenter, Xen) sono più veloci e a bassa latenza possibile.

Disco spazio
Virt-v2v inserisce file temporanei potenzialmente grandi in $TMPDIR (che è / Var / tmp se tu
non impostarlo). Usare tmpfs è una cattiva idea.

Per ogni disco ospite viene memorizzato temporaneamente un overlay. Questo memorizza le modifiche apportate
durante la conversione e viene utilizzato come cache. Le sovrapposizioni non sono particolarmente grandi - decine
o poche centinaia di megabyte per disco è tipico. Oltre alla/e sovrapposizione/e, input
e i metodi di output possono utilizzare lo spazio su disco, come indicato nella tabella seguente.

-i ovuli
Questo inserisce temporaneamente una copia completa dei dischi di origine non compressi in $TMPDIR.

-o sguardo
Questo inserisce temporaneamente una copia completa dei dischi di output in $TMPDIR.

-o locale
-o whoa
Devi assicurarti che ci sia spazio sufficiente nella directory di output per il convertito
ospite.

-o nullo
Questo inserisce temporaneamente una copia completa dei dischi di output in $TMPDIR.

VMware vCenter risorse
La copia da VMware vCenter è attualmente piuttosto lenta, ma riteniamo che questo sia un problema
con VMware. Garantire che l'hypervisor VMware ESXi e vCenter siano in esecuzione su hardware veloce
con molta memoria dovrebbe alleviare questo.

Calcolare energia e RAM
Virt-v2v non è particolarmente impegnativo per il calcolo o la RAM. Se stai eseguendo molti paralleli
conversioni, allora potresti prendere in considerazione l'allocazione di un core della CPU e tra 512 MB e 1 GB di
RAM per istanza in esecuzione.

Virt-v2v può essere eseguito in una macchina virtuale.

POST-CONVERSIONE COMPITI

GUEST network configurazione
Virt-v2v non può attualmente riconfigurare la configurazione di rete di un ospite. Se il convertito
guest non è connesso alla stessa sottorete della sorgente, la sua configurazione di rete potrebbe
devono essere aggiornati. Guarda anche virt-personalizzare(1).

Conversione a Windows ospite
Quando si converte un guest Windows, il processo di conversione è suddiviso in due fasi:

1. Conversione offline.

2. Primo avvio.

Il guest sarà avviabile dopo la fase di conversione offline, ma non avrà ancora tutto
driver necessari installati per funzionare correttamente. Questi verranno installati automaticamente il
prima volta che l'ospite si avvia.

NB Fare attenzione a non interrompere il processo di installazione automatica del driver durante l'accesso
all'ospite per la prima volta, in quanto ciò potrebbe impedire l'avvio successivo dell'ospite
correttamente.

FREE SPACE PER CONVERSIONE

Virt-v2v controlla che ci sia spazio libero sufficiente nel filesystem ospite per eseguire il
conversione. Attualmente controlla:

File system root di Linux o unità "C:" di Windows
Spazio libero minimo: 20 MB

Linux /avvio
Spazio libero minimo: 50 MB

Questo perché abbiamo bisogno di creare un nuovo initramfs per alcuni Enterprise Linux
conversioni.

Qualsiasi altro filesystem montabile
Spazio libero minimo: 10 MB

JOGGING vs RUNNING VIRT-V2V AS ROOT OR NON RADICE

Niente in virt-v2v necessita intrinsecamente dell'accesso root e funzionerà bene come non root
utente. Tuttavia, alcune funzionalità esterne potrebbero richiedere l'utente root o un utente speciale:

Montaggio del dominio di archiviazione di esportazione
Quando si usa -o revi Hong osseo server:/esd virt-v2v deve avere privilegi sufficienti per NFS
montare il dominio di archiviazione di esportazione da "server".

Puoi evitare di aver bisogno di root qui montandolo tu stesso prima di eseguire virt-v2v e
di passaggio Hong osseo /punto di montaggio invece, ma prima di tutto leggi la sezione successiva...

Scrittura nel dominio di archiviazione di esportazione come 36:36
RHEV-M non può leggere file e directory da Export Storage Domain a meno che non
avere UID:GID 36:36. Vedrai problemi di importazione della VM se l'UID: GID non è corretto.

Quando esegui virt-v2v -o revi come root, virt-v2v tenta di creare file e
directory con la corretta proprietà. Se esegui virt-v2v come non root, lo farà
probabilmente funzionerà ancora, ma dovrai cambiare manualmente la proprietà dopo che virt-v2v ha
finito.

Scrivere su libvirt
Quando si usa -o libvirt, potrebbe essere necessario eseguire virt-v2v come root in modo che possa scrivere su
l'istanza di sistema libvirt (es. "qemu:///system") e nella posizione predefinita per
immagini del disco (di solito / var / lib / libvirt / images).

Puoi evitarlo impostando l'autenticazione della connessione libvirt, vedi
http://libvirt.org/auth.html. In alternativa, usa -oc qemu:///sessione, che volontà
scrivi sulla tua istanza libvirt per utente.

Scrivere allo sguardo
Questo fa non è un bisogno di root (in effetti probabilmente non funzionerà), ma potrebbe richiedere sia a
utente speciale e/o per l'origine di uno script che imposta l'ambiente di autenticazione
variabili. Consulta la documentazione di Glance.

DEBUG RHEV-M IMPORTARE GUASTI

Quando esporti nel RHEV-M Export Storage Domain e poi importi quel guest attraverso
nell'interfaccia utente di RHEV-M, potresti riscontrare un errore di importazione. La diagnosi di questi guasti è
esasperantemente difficile poiché l'interfaccia utente generalmente nasconde la vera ragione del fallimento.

Ci sono due file di registro di interesse. Il primo è memorizzato sul server RHEV-M stesso e
è chiamato /var/log/ovirt-engine/engine.log

Il secondo file, che è il più utile, si trova sull'host SPM (SPM sta per
"Gestore del pool di archiviazione"). Questo è un nodo RHEV che viene scelto per eseguire tutti i metadati
modifiche nel data center, come la creazione di immagini o istantanee. Puoi scoprirlo
quale host è l'SPM corrente dalla colonna "Stato Spm" della scheda "Host". una volta che hai
individuato l'SPM, accedi e prendi il file /var/log/vdsm/vdsm.log che conterrà
messaggi di errore dettagliati dai comandi di basso livello.

MINIMAL XML PER -i libvirtxml OPZIONE

Quando si utilizza la -i libvirtxml opzione, devi fornire un po' di XML libvirt. scrivendo questo
da zero è difficile, quindi il modello qui sotto è utile.

Note: questo dovrebbero esclusivamente be utilizzato da analisi e / o where Tu sapere che cosa sei facendo! Se hai
avere i metadati libvirt per il guest, usa sempre quello.


NOME
1048576
2

hvm














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

MACCHINA LEGGIBILE USCITA

. --leggibile dalla macchina l'opzione può essere utilizzata per rendere l'output più adatto alla macchina, il che
è utile quando si chiama virt-v2v da altri programmi, GUI ecc.

Esistono due modi per utilizzare questa opzione.

Per prima cosa usa l'opzione da sola per interrogare le capacità del binario virt-v2v.
L'output tipico è simile a questo:

$ virt-v2v --leggibile dalla macchina
virt-v2v
riscrittura libguestfs
input:disco
[...]
uscita: locale
[...]
converti: enterprise-linux
convertire: finestre

Viene stampato un elenco di funzioni, una per riga, e il programma esce con lo stato 0.

Le funzioni "input:" e "output:" si riferiscono a -i e -o (modalità ingresso e uscita) opzioni
supportato da questo binario. Le funzionalità "convert:" si riferiscono ai tipi di ospiti che questo binario
sa convertire.

In secondo luogo usa l'opzione insieme ad altre opzioni per creare il programma normale
output più adatto alla macchina.

Al momento questo significa:

1. I messaggi della barra di avanzamento possono essere analizzati da stdout cercando questo normale
espressione:

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

2. Il programma chiamante dovrebbe trattare i messaggi inviati a stdout (eccetto per la barra di avanzamento
messaggi) come messaggi di stato. Possono essere registrati e/o visualizzati dall'utente.

3. Il programma chiamante dovrebbe trattare i messaggi inviati a stderr come messaggi di errore. In
inoltre, virt-v2v esce con un codice di stato diverso da zero se si è verificato un errore fatale.

Virt-v2v ≤ 0.9.1 non supportava il --leggibile dalla macchina opzione a tutti. L'opzione era
aggiunto quando virt-v2v è stato riscritto nel 2014.

Usa virt-v2v online utilizzando i servizi onworks.net