virt-v2v - Online în cloud

PROGRAM:

NUME

virt-v2v - Convertiți un oaspete pentru a utiliza KVM

REZUMAT

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 guest-domain.xml -o local -os / var / tmp

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

virt-v2v -i disc disk.img -o privire

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

DESCRIERE

Virt-v2v convertește oaspeții dintr-un hypervisor străin pentru a rula pe KVM. Poate citi Linux și
Oaspeții Windows care rulează pe VMware, Xen, Hyper-V și alți hipervizoare și convertesc
pe KVM gestionat de libvirt, OpenStack, oVirt, Red Hat Enterprise Virtualisation (RHEV)
sau alte câteva ținte.

Există, de asemenea, un front-end însoțitor numit virt-p2v(1) care vine ca ISO, CD sau PXE
imagine care poate fi pornită pe mașinile fizice pentru a virtualiza acele mașini (fizic pentru
virtual sau p2v).

Această pagină de manual documentează virt-v2v rescris inclus în libguestfs ≥ 1.28.

INTRARE AND REZULTATE MODURI

┌────────────┐ ┌─────────▶ -o nul
-i disc ────────────┐ │ │ ─┘┌───────▶ -o local
-i ova ──────────┐ └──▶ │ virt-v2v │ ──┘┌─────────┶ -──┶
└────▶ │ conversie │ ───┘┌────────────┐
VMware─▶┌────────────┐ │ server │ ────▶ -o libvirt │─▶ KVM
Xen ───▶│ -i libvirt ──▶ │ │ │ (implicit) │
... ───▶│ (implicit) │ │ │ ──┐ └────────────┘
└────────────┘ │ │ ─┐└──────▶ -o privire
-i libvirtxml ─────────▶ │ │ ┐└─────────▶ -o rhev
└────────────┘ └──────────▶ -o vdsm

Virt-v2v are un număr de moduri posibile de intrare și ieșire, selectate folosind -i si -o
Opțiuni. Numai un mod de intrare și ieșire poate fi selectat pentru fiecare rulare a virt-v2v.

-i disc este folosit pentru citirea imaginilor de pe disc locale (în principal pentru testare).

-i libvirt este folosit pentru citirea din orice sursă libvirt. Deoarece libvirt se poate conecta la multe
diferite hipervizoare, este folosit pentru citirea invitaților din VMware, RHEL 5 Xen și multe altele.
-IC opțiunea selectează sursa libvirt precisă.

-i libvirtxml este folosit pentru a citi din fișierele XML libvirt. Aceasta este metoda folosită de
virt-p2v(1) în culise.

-i icre este utilizat pentru citirea dintr-un fișier sursă VMware ova.

-o privire este folosit pentru scrierea în OpenStack Glance.

-o libvirt este folosit pentru scrierea în orice țintă libvirt. Libvirt se poate conecta la local sau
hipervizoare KVM la distanță. The -oc opțiunea selectează ținta libvirt precisă.

-o local este folosit pentru a scrie pe o imagine de disc locală cu un fișier de configurare libvirt local
(în principal pentru testare).

-o whoa scrie pe o imagine de disc locală cu un script shell pentru pornirea directă a invitatului
qemu (în principal pentru testare).

-o rhev este folosit pentru a scrie într-o țintă RHEV-M / oVirt. -o vdsm este folosit numai când virt-v2v
rulează sub control VDSM.

--la loc instruiește virt-v2v să personalizeze sistemul de operare invitat în mașina virtuală de intrare,
în loc să creeze un nou VM în hypervisorul țintă.

EXEMPLE

Converti din VMware vCenter serverul la local libvirt
Aveți un server VMware vCenter numit „vcenter.example.com”, un centru de date numit
„Datacenter” și un hypervisor ESXi numit „esxi”. Doriți să convertiți un invitat numit
„vmware_guest” să ruleze local sub libvirt.

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

În acest caz, cel mai probabil va trebui să rulați virt-v2v ca „rădăcină”, deoarece trebuie să vorbească
la demonul libvirt de sistem și copiați discurile invitate pe / var / lib / libvirt / images.

Pentru mai multe informații, consultați „INTRAREA DE LA SERVERUL VMWARE VCENTER” de mai jos.

Converti din VMware la RHEV-M/oVirt
Acesta este același cu exemplul anterior, cu excepția faptului că doriți să trimiteți oaspetele la un RHEV-M
Exportați domeniul de stocare care este situat la distanță (prin NFS) la „rhev.nfs:/export_domain”.
Dacă nu sunteți clar locația domeniului de stocare de export, ar trebui să verificați
setările de pe consola dvs. de management RHEV-M. La care sunt conectate interfețele de rețea pentru invitați
rețeaua țintă numită „rhevm”.

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

În acest caz, gazda care rulează virt-v2v acționează ca un convertire serverul.

Rețineți că după conversie, invitatul va apărea în domeniul de stocare de export RHEV-M,
de unde va trebui să-l importați folosind interfața de utilizator RHEV-M. (Consultați „IEȘIRE LA
RHEV").

Converti disc imagine la OpenStack privire
Având o imagine de disc de la un alt hypervisor pe care doriți să o convertiți pentru a rula pe OpenStack
(este acceptat doar OpenStack bazat pe KVM), puteți face:

virt-v2v -i disc disk.img -o privire

Pentru a controla numele imaginii în Glance, utilizați -pe opțiune.

Converti disc imagine la disc imagine
Având în vedere o imagine de disc de la un alt hypervisor pe care doriți să o convertiți pentru a rula pe KVM, dvs
au doua variante. Cel mai simplu mod este să încerci:

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

unde virt-v2v ghicește totul despre intrare disc.img și (în acest caz) scrie
rezultat convertit în / var / tmp.

O metodă mai complexă este să scrieți niște libvirt XML care să descrie invitatul de intrare (dacă puteți
obțineți hypervisor-ul sursă să vă ofere libvirt XML, atunci cu atât mai bine). Tu
apoi pot face:

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

Întrucât guest-domain.xml conține calea (căile) către imaginea (imaginile) de disc oaspete de care nu aveți nevoie
specificați numele imaginii de disc pe linia de comandă.

Pentru a converti o imagine de disc locală și a o porni imediat în qemu local, faceți:

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

SUPORT MATRIX

Hypervisorii (Intrare)
VMware ESXi
Trebuie să fie gestionat de VMware vCenter ≥ 5.0. Intrarea directă negestionată de la ESXi nu este
sprijinit.

OVA exportat din VMware
OVA-urile de la alți hipervizori nu vor funcționa.

RHEL 5 Xen
Citrix Xen
Citrix Xen nu a fost testat recent.

Hyper-V
Nu a fost testat recent. Necesită să exportați discul sau să utilizați virt-p2v(1) pe Hyper-V.

Direct de pe imagini de pe disc
Numai imagini de disc exportate de la hipervizoare acceptate și folosind formate container
sprijinit de qemu.

Mașini fizice
Utilizarea virt-p2v(1) unealtă.

Hypervisorii (Ieșire)
Doar QEMU și KVM.

virtualizare administrare sisteme (Ieșire)
OpenStack Glance
Red Hat Enterprise Virtualization (RHEV) 2.2 și versiuni ulterioare
libvirt local
Și, prin urmare Virsh(1), virt-manager(1) și instrumente similare.

Disc local

Oaspeți
Red Hat Enterprise Linux 3, 4, 5, 6, 7
CentOS 3, 4, 5, 6, 7
Linux științific 3, 4, 5, 6, 7
Oracle Linux
Fedora
SLES 10 și mai sus
OpenSUSE 10 și versiuni ulterioare
De la Windows XP la Windows 8.1 / Windows Server 2012 R2
Folosim numerele de versiune interne Windows, vezi
https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

În prezent, sunt acceptate NT 5.2 până la NT 6.3.

Consultați „WINDOWS” de mai jos pentru note suplimentare despre conversia oaspeților Windows.

Oaspete firmware
BIOS sau UEFI pentru toate tipurile de invitați (dar consultați „UEFI” de mai jos).

OPŢIUNI

--Ajutor
Afișează ajutor.

-b ...
--pod ...
Vedea --reţea de mai jos.

--comprimat
Scrieți un fișier de ieșire comprimat. Acest lucru este permis numai dacă formatul de ieșire este qcow2
(A se vedea -de de mai jos), și este echivalent cu -c opțiunea de a qemu-img(1).

--dcpath Dosar/Centru de date
NB: Nu trebuie să utilizați acest parametru dacă aveți libvirt ≥ 1.2.20.

Pentru VMware vCenter, suprascrieți parametrul „dcPath=...” utilizat pentru a selecta centrul de date.
Virt-v2v poate calcula de obicei acest lucru din URI-ul „vpx://”, dar dacă se înțelege greșit,
apoi îl puteți suprascrie folosind această setare. Accesați interfața folderului web vCenter,
de exemplu. „https://vcenter.example.com/folder” (fără o bară oblică) și examinați
Parametrul „dcPath=" din adresele URL care apar pe această pagină.

--debug-gc
Depanați colectarea gunoiului și alocarea memoriei. Acest lucru este util doar la depanare
probleme de memorie în virt-v2v sau legăturile OCaml libguestfs.

--debug-overlays
Salvați fișierele suprapuse create în timpul conversiei. Această opțiune este folosită doar pentru
depanarea virt-v2v și poate fi eliminată într-o versiune viitoare.

-i disc
Setați metoda de introducere la disc.

În acest mod puteți citi o imagine de disc a unei mașini virtuale fără metadate. virt-v2v
încearcă să ghicească cele mai bune metadate implicite. Acest lucru este de obicei adecvat, dar puteți obține
control mai fin (de ex. al memoriei și vCPU-urilor) prin utilizarea -i libvirtxml in schimb. Doar oaspeți
care folosesc un singur disc pot fi importate în acest fel.

-i libvirt
Setați metoda de introducere la libvirt. Aceasta este valoarea implicită.

În acest mod, trebuie să specificați un nume de invitat libvirt sau UUID pe linia de comandă.
De asemenea, puteți specifica un URI de conexiune libvirt (vezi -IC).

-i libvirtxml
Setați metoda de introducere la libvirtxml.

În acest mod, trebuie să treceți un fișier XML libvirt pe linia de comandă. Acest fișier este
citiți pentru a obține metadate despre oaspetele sursă (cum ar fi numele acestuia, cantitatea de
memorie), precum și pentru a localiza discurile de intrare. Consultați „XML MINIMAL PENTRU -i libvirtxml
OPȚIUNE” de mai jos.

-i local
Aceasta este la fel ca -i disc.

-i icre
Setați metoda de introducere la icre.

În acest mod puteți citi un fișier VMware ova. Virt-v2v va citi fișierul manifest ova
și verificați validitatea volumelor vmdk (sume de verificare), precum și analiza fișierului ovf,
și apoi convertiți oaspetele. Vedeți „INTRAREA DIN VMWARE OVA” de mai jos

-IC libvirtURI
Specificați un URI de conexiune libvirt pe care să îl utilizați când citiți invitatul. Acesta este folosit doar
cand -i libvirt.

Doar conexiuni locale libvirt, conexiuni VMware vCenter sau la distanță RHEL 5 Xen
pot fi folosite conexiuni. Alte conexiuni libvirt la distanță nu vor funcționa în general.

Vezi, de asemenea, „INPUT FROM VMWARE VCENTER SERVER”, „INPUT FROM RHEL 5 XEN” de mai jos.

-dacă format
Pentru -i disc numai, aceasta specifică formatul imaginii de disc de intrare. Pentru alte intrări
metode ar trebui să specificați formatul de intrare în metadate.

--la loc
Nu creați o mașină virtuală de ieșire în hypervisorul țintă. În schimb, ajustați
OS invitat în VM sursă pentru a rula în hypervisorul de intrare.

Acest mod este conceput pentru integrarea cu alte seturi de instrumente, care își asumă responsabilitatea
de conversie a configurației VM, oferind rollback în caz de erori,
transformarea depozitului etc.

Conflicte cu toți -o * opțiuni.

--citit de mașină
Această opțiune este folosită pentru a face ieșirea mai prietenoasă cu mașina atunci când este analizată de
alte programe. Vezi mai jos „IEȘIRE CITBILĂ DE MAȘINĂ”.

-n în afară
-n afară
--reţea în afară
--reţea afară
-b în afară
-b afară
--pod în afară
--pod afară
Hartă rețeaua (sau puntea) numită „înăuntru” la rețea (sau puntea) numită „out”. Dacă nu există „în:”
prefixul este dat, toate celelalte rețele (sau poduri) sunt mapate la „out”.

Vezi mai jos „REȚELE ȘI PODURI”.

--fără-copie
Nu copiați discurile. În schimb, conversia este efectuată (și aruncată) și
metadatele sunt scrise, dar nu sunt create discuri. Vezi și discuția despre -o nul de mai jos.

Acest lucru este util în două cazuri: fie doriți să testați dacă conversia este probabil să o facă
reuși, fără un proces lung de copiere. Sau te interesează doar să te uiți
metadatele.

Această opțiune nu este compatibilă cu -o libvirt deoarece ar crea un oaspete defect
(unul fără discuri).

Această opțiune nu este compatibilă cu -o privire din motive tehnice.

--fără-tăiere toate
--fără-tăiere mp[,mp...]
În mod implicit, virt-v2v rulează fstrim(8) pentru a reduce cantitatea de date care trebuie să fie
copiat. Se știe că acest lucru rupe unele încărcătoare de încărcare cu erori care provoacă erori de pornire după
conversie (vezi de exemplu https://bugzilla.redhat.com/show_bug.cgi?id=1141145#c27).

Poți să folosești --fără-tăiere toate pentru a dezactiva toate tăierea. Rețineți că acest lucru va crește foarte mult
cantitatea de date care trebuie copiată și poate face virt-v2v să ruleze mult mai lent.

De asemenea, puteți dezactiva tăierea numai pe sistemele de fișiere selectate (specificate printr-o virgulă-
listă separată a punctelor lor de montare în invitat). De obicei ai folosi
--fără-tăiere / boot pentru a rezolva problema grub menționată mai sus.

De asemenea, puteți dezactiva tăierea pe partiții folosind schema de denumire libguestfs pentru
dispozitive, de exemplu: --fără-tăiere / dev / sdb2 înseamnă că nu tăiați a doua partiție pe a doua
blocarea dispozitivului. Utilizare virt-sisteme de fișiere(1) pentru a lista numele sistemelor de fișiere într-un oaspete.

-o disc
Aceasta este la fel ca -o local.

-o privire
Setați metoda de ieșire la OpenStack Glance. În acest mod, oaspetele convertit este
încărcat pe Glance. Puteți controla numele imaginii setând -pe opțiune.

-o libvirt
Setați metoda de ieșire la libvirt. Aceasta este valoarea implicită.

În acest mod, invitatul convertit este creat ca oaspete libvirt. De asemenea, puteți specifica
un URI de conexiune libvirt (vezi -oc).

Vedeți „IEȘIRE LA LIBVIRT” de mai jos.

-o local
Setați metoda de ieșire la local.

În acest mod, oaspetele convertit este scris într-un director local specificat de -tu
/dir (directorul trebuie să existe). Discurile invitatului convertit sunt scrise ca:

/dir/nume-sda
/dir/name-sdb
[etc]

și este creat un fișier XML libvirt care conține metadate pentru invitați:

/dir/name.xml

unde „nume” este numele invitatului.

-o zero
Setați metoda de ieșire la zero.

Invitatul este convertit și copiat (dacă nu specificați și dvs --fără-copie), dar rezultatele
sunt aruncate și nu sunt scrise metadate.

-o ovirt
Aceasta este la fel ca -o rhev.

-o whoa
Setați metoda de ieșire la whoa.

Acest lucru este similar cu -o local, cu excepția faptului că este scris un script shell pe care îl puteți folosi
pentru a porni invitatul în qemu. Discurile convertite și scriptul shell sunt scrise în
director specificat de -tu.

Când utilizați acest mod de ieșire, puteți, de asemenea, specifica --qemu-boot opțiunea care cizme
oaspete sub qemu imediat.

-o rhev
Setați metoda de ieșire la rhev.

Oaspetele convertit este scris într-un domeniu de stocare de export RHEV. The -tu parametru
trebuie de asemenea folosit pentru a specifica locația domeniului de stocare de export. Rețineți acest lucru
nu importă de fapt oaspetele în RHEV. Trebuie să faci asta manual mai târziu
folosind UI.

Consultați „IEȘIRE LA RHEV” de mai jos.

-o vdsm
Setați metoda de ieșire la vdsm.

Acest mod este similar cu -o rhev, dar calea completă către domeniul de date trebuie să fie dată:
/rhev/data-center/ /. Acest mod este utilizat numai când
virt-v2v rulează sub control VDSM.

-oa rar
-oa prealocate
Setați modul de alocare a fișierelor de ieșire. Valoarea implicită este „sparse”.

-oc libvirtURI
Specificați o conexiune libvirt pe care să o utilizați când scrieți invitatul convertit. Aceasta este numai
folosit când -o libvirt. Vedeți „IEȘIRE LA LIBVIRT” de mai jos.

Pot fi utilizate numai conexiunile locale libvirt. Conexiunile la distanță libvirt nu vor funcționa.

-de format
Când convertiți invitatul, convertiți discurile în formatul dat.

Dacă nu este specificat, atunci este utilizat formatul de intrare.

-pe nume
Redenumiți invitatul când îl convertiți. Dacă această opțiune nu este utilizată, atunci numele de ieșire
este același cu numele de intrare.

-tu depozitare
Locația depozitului pentru oaspetele convertit.

Pentru -o libvirt, acesta este un pool de directoare libvirt (vezi „listă-pool virsh”) sau un UUID de pool.

Pentru -o local si -o whoa, acesta este un nume de director. Directorul trebuie să existe.

Pentru -o rhev, aceasta poate fi o cale NFS a domeniului de stocare de export al formularului
" : ", de exemplu:

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

Exportul NFS trebuie să poată fi montat și scris de către utilizator și gazdă care rulează virt-v2v,
deoarece programul virt-v2v trebuie să-l monteze de fapt când rulează. Deci probabil tu
trebuie să ruleze virt-v2v ca „rădăcină”.

Sau: Puteți monta singur domeniul de stocare de export și puteți indica -tu până la punctul de montare.
Rețineți că virt-v2v va trebui să scrie în acest director la distanță, așa că virt-v2v va avea nevoie
mai trebuie să ruleze ca „rădăcină”.

Veți primi o eroare dacă virt-v2v nu se poate monta/scrie în Export Storage
Domeniu.

--parola-fișier fişier
În loc să cereți parola(e) în mod interactiv, treceți parola printr-un fișier.
Rețineți că fișierul ar trebui să conțină întreaga parolă, fără Orice adulmecător linie nouă, Și pentru
securitate, fișierul ar trebui să aibă modul 0600, astfel încât alții să nu îl poată citi.

--print-source
Imprimați informații despre oaspetele sursă și opriți. Această opțiune este utilă atunci când sunteți
crearea de hărți de rețea și poduri. Vezi „REȚELE ȘI PODURI”.

--qemu-boot
Atunci când se utilizează -o whoa numai, aceasta cizme oaspete imediat după terminarea virt-v2v.

-q
--Liniște
Acest lucru dezactivează barele de progres și alte rezultate inutile.

--rădăcină cere
--rădăcină singur
--rădăcină primul
--rădăcină / dev / sdX
--rădăcină /dev/VG/LV
Alegeți sistemul de fișiere rădăcină care trebuie convertit.

În cazul în care mașina virtuală este dual-boot sau multi-boot, sau unde VM-ul are
alte sisteme de fișiere care arată ca sisteme de operare, această opțiune poate fi folosită pentru a selecta
sistemul de fișiere rădăcină (alias unitatea „C:” sau /) a sistemului de operare care urmează să fie
convertit. Consola de recuperare Windows, anumite unități DVD atașate și erori
euristica de inspecție libguestfs, poate face ca un oaspete să arate ca o operare multi-boot
sistemului.

Valoarea implicită în virt-v2v ≤ 0.7.1 a fost --root single, ceea ce face ca virt-v2v să moară dacă a
este găsit sistemul de operare multi-boot.

Deoarece virt-v2v ≥ 0.7.2, implicit este acum --root intreaba: Dacă se constată că VM-ul este multi-
boot, apoi virt-v2v se va opri și va lista sistemele de fișiere rădăcină posibile și va întreba utilizatorul
pe care să-l folosească. Acest lucru necesită ca virt-v2v să fie rulat interactiv.

--rădăcină mai întâi înseamnă să alegeți primul dispozitiv rădăcină în cazul unui boot multiplu
sistem de operare. Deoarece aceasta este o euristică, uneori poate alege cea greșită.

De asemenea, puteți numi un anumit dispozitiv rădăcină, de ex. --root /dev/sda2 ar însemna să folosești
a doua partiție pe primul hard disk. Dacă dispozitivul rădăcină numit nu există sau
nu a fost detectat ca dispozitiv rădăcină, atunci virt-v2v va eșua.

Rețineți că există o eroare în grub care îl împiedică să pornească cu succes a
sistem multiboot dacă VirtIO este activat. Grub este capabil să pornească doar un sistem de operare
de pe primul disc VirtIO. Specific, / boot trebuie să fie pe primul disc VirtIO și
nu poate încărca în lanț un sistem de operare care nu se află pe primul disc VirtIO.

--vdsm-image-uuid UUID
--vdsm-vol-uuid UUID
--vdsm-vm-uuid UUID
--vdsm-ovf-output
În mod normal, modul de ieșire RHEV alege UUID-uri aleatorii pentru oaspetele țintă. Cu toate acestea, VDSM
trebuie să controleze UUID-urile și să transmită acești parametri atunci când virt-v2v rulează sub VDSM
Control. Controlul parametrilor:

· directorul de imagini al fiecărui disc invitat (--vdsm-image-uuid) (această opțiune este trecută
o dată pentru fiecare disc invitat)

· UUID-uri pentru fiecare disc invitat (--vdsm-vol-uuid) (această opțiune este trecută o dată pentru fiecare
disc invitat)

· numele fișierului OVF (--vdsm-vm-uuid).

· directorul de ieșire OVF (directorul curent implicit) (--vdsm-ovf-output).

Formatul UUID-urilor este: „12345678-1234-1234-1234-123456789abc” (fiecare cifră hexadecimală poate fi
„0-9” sau „af”), în conformitate cu OSF DCE 1.1.

Aceste opțiuni pot fi utilizate numai cu -o vdsm.

-v
--verbos
Activați mesajele detaliate pentru depanare.

-V
--versiune
Afișați numărul versiunii și ieșiți.

--vmtype desktop
--vmtype serverul
Pentru -o rhev or -o vdsm numai ținte, specificați tipul de oaspete. Puteți seta asta
la „desktop” sau „server”. Dacă opțiunea nu este dată, atunci este o valoare implicită adecvată
ales pe baza sistemului de operare invitat detectat.

-x Activați urmărirea apelurilor API libguestfs.

XEN PARAVIRTUALIZAT VIZITATORI

Versiunile mai vechi de virt-v2v ar putea transforma un invitat Xen paravirtualizat (PV) într-un invitat KVM prin
instalarea unui nou nucleu. Această versiune de virt-v2v face nu încercați să instalați orice nou
miezuri. În schimb, vă va da o eroare dacă există nuclee Xen PV disponibile.

Prin urmare, înainte de conversie, ar trebui să verificați dacă este instalat un nucleu obișnuit. Pentru unii
distribuții Linux mai vechi, aceasta înseamnă instalarea unui nucleu din tabelul de mai jos:

RHEL 3 (Nu se aplică, deoarece nu a existat un nucleu Xen PV)

RHEL 4 i686 cu > 10 GB de RAM: instalați „kernel-hugemem”
i686 SMP: instalați „kernel-smp”
alt i686: instalați „kernel”
x86-64 SMP cu > 8 procesoare: instalați „kernel-largesmp”
x86-64 SMP: instalați „kernel-smp”
altele x86-64: instalați „kernel”

RHEL 5 i686: instalați „kernel-PAE”
x86-64: instalați „kernel”

SLES 10 i586 cu > 10 GB de RAM: instalați „kernel-bigsmp”
i586 SMP: instalați „kernel-smp”
alt i586: instalați „kernel-default”
x86-64 SMP: instalați „kernel-smp”
alt x86-64: instalați „kernel-default”

SLES 11+ i586: instalați „kernel-pae”
x86-64: instalați „kernel-default”

Windows (Nu se aplică, deoarece nu există kernel Xen PV Windows)

ACTIVARE VIRTIO

„Virtio” este numele unui set de drivere care fac disc (dispozitiv de bloc), rețea și
alte operațiuni pentru oaspeți funcționează mult mai rapid pe KVM.

Versiunile mai vechi de virt-v2v ar putea instala aceste drivere pentru anumiți invitați Linux. Acest
versiunea de virt-v2v face nu încercați să instalați noi nuclee sau drivere Linux, dar o va face
vă avertizează dacă nu sunt deja instalate.

Pentru a activa virtio și, prin urmare, pentru a îmbunătăți performanța oaspetelui după conversie,
ar trebui să vă asigurați că minim sunt instalate versiuni ale pachetelor înainte conversie,
prin consultarea tabelului de mai jos.

RHEL 3 Nu sunt disponibile drivere virtio

Nucleu RHEL 4 >= 2.5.9-89.EL
lvm2 >= 2.02.42-5.el4
device-mapper >= 1.02.28-2.el4
selinux-policy-targeted >= 1.17.30-2.152.el4
policycoreutils >= 1.18.1-4.13

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

RHEL 6+ Toate versiunile acceptă virtio

Fedora Toate versiunile acceptă virtio

SLES 11+ Toate versiunile acceptă virtio

Nucleu SLES 10 >= 2.6.16.60-0.85.1

OpenSUSE 11+ Toate versiunile acceptă virtio

Nucleul OpenSUSE 10 >= 2.6.25.5-1.1

Driverele Windows sunt instalate din directorul indicat de
Variabila de mediu „VIRTIO_WIN”.
(/usr/share/virtio-win în mod implicit) dacă este prezent

RHEL 4

SELinux reetichetați apare la atârna pentru totdeauna
În RHEL ≤ 4.7 a existat o eroare care face ca reetichetarea SELinux să pară să se blocheze pentru totdeauna
la:

*** Avertisment -- Este necesară reetichetarea SELinux. ***
*** Dezactivarea aplicării securității. ***
*** Reetichetarea ar putea dura foarte mult timp, ***
*** în funcție de dimensiunea sistemului de fișiere. ***

În realitate, așteaptă să apăsați o tastă (dar nu există nicio indicație vizuală despre
acest). Puteți apăsa fie tasta „[Return]”, moment în care oaspetele va termina
reetichetare și repornire, sau puteți instala policycoreutils ≥ 1.18.1-4.13 înainte de a începe
conversia v2v. Vezi și https://bugzilla.redhat.com/show_bug.cgi?id=244636

WINDOWS

Boot eșec: 0x0000007B
Această eroare de pornire este cauzată de faptul că Windows nu poate găsi sau încărca driverul de disc corect
(de exemplu. viostor.sys). Dacă întâmpinați această eroare, iată câteva lucruri de verificat:

· Asigurați-vă mai întâi că oaspetele pornește pe hypervisor-ul sursă înainte de conversie.

· Verificați dacă aveți driverele Windows virtio disponibile în /usr/share/virtio-win, și asta
virt-v2v nu a tipărit niciun avertisment despre imposibilitatea de a instala drivere virtio.

Pe Red Hat Enterprise Linux 7, va trebui să instalați driverele semnate disponibile
în pachetul „virtio-win”. Dacă nu aveți acces la driverele semnate, atunci
probabil că va trebui să dezactivați semnarea driverului în meniurile de pornire.

· Verificați dacă prezentați o interfață virtio-blk (nu virtio-scsi si nu ide) să
oaspetele. Pe linia de comandă qemu/KVM ar trebui să vedeți ceva similar cu acesta:

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

În libvirt XML, ar trebui să vedeți:



· Verificați dacă Politica de grup Windows nu împiedică instalarea driverului sau
folosit. Încercați să ștergeți politica de grup Windows înainte de conversie.

· Verificați că nu există antivirus sau alt software care să implementeze politica de grup
interdicții privind instalarea sau utilizarea driverelor noi.

· Activați depanarea de pornire și verificați viostor.sys driverul este în curs de încărcare.

OpenStack si ferestre din reactivare
OpenStack nu oferă oaspeților adrese stabile pentru dispozitive/PCI. De fiecare dată când creează
sau pornește un oaspete, regenerează XML-ul libvirt pentru acel oaspete de la zero. The
libvirt XML va avea nr câmpuri. Libvirt va atribui apoi adrese dispozitivelor,
într-o manieră previzibilă. Adresele se pot schimba dacă oricare dintre următoarele este adevărată:

· Un nou disc sau dispozitiv de rețea a fost adăugat sau eliminat de la invitat.

· Versiunea OpenStack sau (posibil) libvirt sa schimbat.

Deoarece Windows nu-i plac modificările „hardware” de acest fel, poate declanșa Windows
reactivare.

Acest lucru poate preveni, de asemenea, pornirea cu o eroare 7B [vezi secțiunea anterioară] dacă oaspete a făcut-o
politica de grup care conține „Restricții de instalare a dispozitivului”.

UEFI

VMware vă permite să prezentați firmware-ul UEFI oaspeților (în loc de BIOS-ul obișnuit al computerului).
Virt-v2v poate converti acești invitați, dar necesită ca UEFI să fie acceptat de țintă
hipervizor.

În prezent, KVM acceptă OVMF, un firmware UEFI cu sursă deschisă parțial și le poate rula
vizitatori.

Deoarece suportul OVMF a fost adăugat recent la KVM (în 2014/2015), nu toate țintă
mediile acceptă încă oaspeții UEFI:

UEFI pe libvirt, qemu
Sprijinit. Virt-v2v va genera automat libvirt XML (metadatele) corecte,
dar rețineți că aceeași versiune de OVMF trebuie instalată pe gazda de conversie așa cum este
instalat pe hypervisorul țintă, altfel va trebui să ajustați căile în
metadate.

UEFI pe OpenStack
Nu sunt acceptate.

UEFI pe RHEV
Nu sunt acceptate.

REȚELE AND PODURI

Oaspeții sunt de obicei conectați la una sau mai multe rețele și atunci când sunt convertiți la țintă
hypervisor, de obicei doriți să reconectați acele rețele la destinație. Opțiunile
--reţea si --pod iti permit sa faci asta.

Dacă nu sunteți sigur de ce rețele și punți sunt utilizate pe hypervisorul sursă, atunci
puteți examina metadatele sursă (libvirt XML, informații vCenter etc.). Sau puteți
rulați virt-v2v cu --print-source opțiunea care face ca virt-v2v să imprime fișierul
informațiile pe care le are despre oaspete pe sursă și apoi ieșire.

În --print-source ieșire veți vedea o secțiune care arată interfața de rețea a oaspetelui
Carduri (NIC-uri):

$ virt-v2v [-i ...] --print-source name
[...]
NIC-uri:
Rețea „implicit” mac: 52:54:00:d0:cf:0e

Acest lucru este tipic pentru un oaspete libvirt: are o singură interfață de rețea conectată la un
reţea numită „implicit”.

Pentru a mapa o anumită rețea la o rețea țintă, de exemplu „implicit” pe sursa către
„rhevm” pe țintă, utilizați:

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

Pentru a mapa fiecare rețea la o rețea țintă, utilizați:

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

Podurile sunt tratate în același mod, dar trebuie să utilizați --pod opțiune în schimb. Pentru
exemplu:

$ virt-v2v [-i ...] --print-source name
[...]
NIC-uri:
Podul „br0”

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

INTRARE DIN vmware VCENTER SERVER

Virt-v2v poate importa oaspeți de pe VMware vCenter Server.

Este necesar vCenter ≥ 5.0. Dacă nu aveți vCenter, se recomandă utilizarea OVA
(vezi „INTRAREA DE LA VMWARE OVA” de mai jos), sau dacă acest lucru nu este posibil, consultați „INTRAREA DE LA
HYPERVISOR VMWARE ESXi”.

Virt-v2v folosește libvirt pentru acces la vCenter și, prin urmare, modul de intrare ar trebui să fie -i
libvirt. Deoarece acesta este implicit, nu trebuie să îl specificați pe linia de comandă.

VCENTER: ELIMINA vmware UNELTE DIN WINDOWS VIZITATORI
Pentru oaspeții Windows, ar trebui să eliminați instrumentele VMware înainte de conversie. Deși aceasta este
nu este strict necesar, iar oaspetele va putea în continuare să alerge, dacă nu faci asta atunci
oaspetele convertit se va plânge la fiecare cizmă. Uneltele nu pot fi îndepărtate după
conversie deoarece programul de dezinstalare verifică dacă rulează pe VMware și refuză să pornească
(care este și motivul pentru care virt-v2v nu le poate elimina).

Acest lucru nu este necesar pentru oaspeții Linux, deoarece virt-v2v poate elimina instrumentele VMware.

VCENTER: URI
URI-ul libvirt al unui server vCenter arată cam așa:

vpx://user@server/Datacenter/esxi

în cazul în care:

"utilizator@"
este utilizatorul (opțional, dar recomandat) pentru a se conecta ca.

Dacă numele de utilizator conține o bară oblică inversă (de ex. „DOMENIU\UTILIZATOR”), atunci va trebui să URI-
scăpați de acel caracter folosind %5c: „DOMAIN%5cUSER” (5c este codul ASCII hexazecimal pentru
bară oblică inversă.) S-ar putea ca și alte semne de punctuație să fie scăpate.

"Server"
este serverul vCenter (nu hipervizor).

"Centru de date"
este numele centrului de date.

Dacă numele conține un spațiu, înlocuiți-l cu codul de escape URI %20.

"esxi"
este numele hypervisorului ESXi care rulează oaspetele.

Dacă implementarea VMware utilizează foldere, atunci acestea ar putea trebui adăugate la URI, de exemplu:

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

Pentru detalii complete despre URI-urile libvirt, consultați: http://libvirt.org/drvesx.html

Erorile tipice de la libvirt / virsh atunci când URI-ul este greșit includ:

· Nu s-a putut găsi centrul de date specificat în [...]

· Nu s-a putut găsi resursa de calcul specificată în [...]

· Calea [...] nu specifică o resursă de calcul

· Calea [...] nu specifică un sistem gazdă

· Nu s-a putut găsi sistemul gazdă specificat în [...]

VCENTER: TEST LIBVIRT CONEXIUNEA LA VCENTER
Folosește Virsh(1) comandă pentru a lista invitații pe serverul vCenter astfel:

$ virsh -c 'vpx://[e-mail protejat]/Datacenter/esxi' list --all
Introduceți parola root pentru vcenter.example.com: ***

Id Nume Stat
-------------------------------------------------- -
- Fedora 20 oprit
- Windows 2003 oprit

Dacă primiți o eroare „Certificatul peer nu poate fi autentificat cu certificatele CA date”
sau similar, atunci puteți fie să importați certificatul gazdei vCenter, fie să ocoliți semnătura
verificare prin adăugarea indicatorului „?no_verify=1”:

$ virsh -c 'vpx://[e-mail protejat]/Datacenter/esxi?no_verify=1' list --all

De asemenea, ar trebui să încercați să descărcați metadatele de la orice invitat de pe serverul dvs., astfel:

$ virsh -c 'vpx://[e-mail protejat]/Datacenter/esxi' dumpxml „Windows 2003”

Windows 2003
[...]


If il mai sus comenzi do nu muncă, apoi virt-v2v is nu merge la muncă oricare. Remediați-vă
configurația libvirt și/sau serverul VMware vCenter înainte de a continua.

VCENTER: IMPORTARE A PENSIUNEA
Pentru a importa un anumit invitat de pe vCenter Server, faceți:

$ virt-v2v -ic 'vpx://[e-mail protejat]/Datacenter/esxi?no_verify=1' \
„Windows 2003” \
-o local -os / var / tmp

unde „Windows 2003” este numele oaspetelui (care trebuie închis).

Rețineți că vi se poate cere parola vCenter de două ori. Acest lucru se întâmplă o dată pentru că
libvirt are nevoie de el și a doua oară pentru că virt-v2v însuși se conectează direct la
Server. Utilizare --parola-fișier pentru a furniza o parolă printr-un fișier.

În acest caz, steagurile de ieșire sunt setate să scrie oaspetele convertit într-un temporar
director, deoarece acesta este doar un exemplu, dar puteți scrie și în libvirt sau în oricare altul
tinta sustinuta.

VCENTER: NEADMINISTRAT ROL
În loc să utilizați rolul de administrator vCenter, puteți crea un non-administrator personalizat
rolul de a efectua conversia. Cu toate acestea, va trebui să îi oferiți un set minim de
permisiuni după cum urmează:

1. Creați un rol personalizat în vCenter.

2. Activați (bifați) următoarele obiecte:

Magazin de date:
- Răsfoiți depozitul de date
- Operațiuni cu fișiere de nivel scăzut

Sesiune:
- Validați sesiunea

Mașină virtuală:
Provizionare:
- Permite accesul la disc
- Permite accesul la disc doar pentru citire
- Gestionarea sistemului de operare pentru invitați prin VIX API

INTRARE DIN vmware OVA

Virt-v2v este capabil să importe oaspeți din fișierele OVA (Open Virtualization Appliance) ale VMware.
Numai OVA-urile exportate din VMware vSphere vor funcționa.

OVA: ELIMINA vmware UNELTE DIN WINDOWS VIZITATORI
Pentru oaspeții Windows, ar trebui să eliminați instrumentele VMware înainte de conversie. Deși aceasta este
nu este strict necesar, iar oaspetele va putea în continuare să alerge, dacă nu faci asta atunci
oaspetele convertit se va plânge la fiecare cizmă. Uneltele nu pot fi îndepărtate după
conversie deoarece programul de dezinstalare verifică dacă rulează pe VMware și refuză să pornească
(care este și motivul pentru care virt-v2v nu le poate elimina).

Acest lucru nu este necesar pentru oaspeții Linux, deoarece virt-v2v poate elimina instrumentele VMware.

OVA: CREATE OVA
Pentru a crea un OVA în vSphere, utilizați opțiunea „Export OVF Template” (din contextul VM
sau din meniul Fișier). Fie „Folder of files” (OVF), fie „Single file” (OVA).
de lucru, dar OVA este probabil mai ușor de tratat. Fișierele OVA sunt de fapt doar gudron necomprimat
fișiere, astfel încât să puteți utiliza comenzi precum „tar tf VM.ova” pentru a le vizualiza conținutul.

Crează OVA cu ovftool

De asemenea, puteți utiliza „ovftool” proprietar al VMware:

ovftool --noSSLVerify \
vi://USER:[e-mail protejat]/VM \
VM.ova

Pentru a vă conecta la vCenter:

ovftool --noSSLVerify \
vi://USER:[e-mail protejat]/DATACENTER-NAME/vm/VM \
VM.ova

Pentru autentificarea compatibilă cu Active Directory, trebuie să exprimați caracterul „@” în
forma codului său hex ASCII (%5c):

vi://DOMAIN%5cUSER:PAROLA@...

OVA: IMPORTARE A PENSIUNEA
Pentru a importa un fișier OVA numit VM.ova, face;

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

Dacă ați exportat invitatul ca „Folder de fișiere”, or dacă ați despachetat tarball-ul OVA
dvs., atunci puteți indica virt-v2v către directorul care conține fișierele:

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

INTRARE DIN vmware ESXi HIPERVIZITOR

Virt-v2v nu poate accesa direct un hypervisor ESXi. Ar trebui să utilizați metoda OVA de mai sus
(vezi „INTRAREA DIN VMWARE OVA”) dacă este posibil, deoarece este mult mai rapid și necesită mult mai puțin
spațiu pe disc decât metoda descrisă în această secțiune.

Aveți posibilitatea să utilizați virt-v2v-copy-to-local(1) instrument pentru a copia invitatul de pe hypervisor într-un
fișier local, apoi convertiți-l.

ESXi: ELIMINA vmware UNELTE DIN WINDOWS VIZITATORI
Pentru oaspeții Windows, ar trebui să eliminați instrumentele VMware înainte de conversie. Deși aceasta este
nu este strict necesar, iar oaspetele va putea în continuare să alerge, dacă nu faci asta atunci
oaspetele convertit se va plânge la fiecare cizmă. Uneltele nu pot fi îndepărtate după
conversie deoarece programul de dezinstalare verifică dacă rulează pe VMware și refuză să pornească
(care este și motivul pentru care virt-v2v nu le poate elimina).

Acest lucru nu este necesar pentru oaspeții Linux, deoarece virt-v2v poate elimina instrumentele VMware.

ESXi: URI
URI-ul libvirt pentru hypervisorii VMware ESXi va arăta cam așa:

esx://[e-mail protejat]?no_verify=1

Parametrul „?no_verify=1” dezactivează verificarea certificatelor TLS.

ESXi: TEST LIBVIRT CONEXIUNEA LA ESXi HIPERVIZITOR
Folosește Virsh(1) comandă pentru a testa URI-ul și a lista oaspeții la distanță disponibili:

$ virsh -c esx://[e-mail protejat]?no_verify=1 listă --all
Introduceți parola root pentru esxi.example.com: ***
Id Nume Stat
-------------------------------------------------- -
- oaspeți oprit

ESXi: COPIE THE PENSIUNEA LA THE LOCAL MAȘINĂRIE
Folosind libvirt URI ca -IC opțiunea, copiați unul dintre invitați pe computerul local:

$ virt-v2v-copy-to-local -ic esx://[e-mail protejat]?no_verify=1 invitat

Acest lucru creează guest.xml, guest-disk1, ...

ESXi: DO THE VIRT-V2V CONVERSIE
Efectuați conversia invitatului folosind virt-v2v:

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

ESXi: CURAT UP
Scoateți guest.xml si disc-oaspete* fișiere.

INTRARE DIN RHEL 5 XEN

Virt-v2v poate importa oaspeți Xen de pe gazdele RHEL 5 Xen.

Virt-v2v folosește libvirt pentru acces la gazda Xen de la distanță și, prin urmare, modul de intrare
ar trebui să fie -i libvirt. Deoarece acesta este implicit, nu trebuie să îl specificați în comandă
linia.

XEN: SET UP SSH-AGENT ACCES LA XEN HOST
În prezent, trebuie să activați accesul SSH fără parolă la gazda Xen la distanță de pe virt-v2v
server de conversie.

De asemenea, trebuie să utilizați ssh-agent și să adăugați cheia publică ssh la /root/.ssh/authorized_keys (pe
gazda Xen).

După ce faceți acest lucru, ar trebui să verificați dacă accesul fără parolă funcționează de pe serverul virt-v2v
la gazda Xen. De exemplu:

$ ssh [e-mail protejat]
[ se conectează direct în shell, nu se solicită nicio parolă ]

Rețineți că accesul interactiv prin parolă și Kerberos sunt nu sprijinit. Tu avea a înscena
acces ssh folosind ssh-agent și authorized_keys.

XEN: TEST LIBVIRT CONEXIUNEA LA DISTANȚĂ XEN HOST
Folosește Virsh(1) comandă pentru a lista oaspeții pe gazda Xen la distanță:

$ virsh -c xen+ssh://[e-mail protejat] listă - toate
Id Nume Stat
-------------------------------------------------- -
0 Domeniul-0 rulează
- rhel49-x86_64-pv oprit

De asemenea, ar trebui să încercați să descărcați metadatele de la orice invitat de pe serverul dvs., astfel:

$ virsh -c xen+ssh://[e-mail protejat] dumpxml rhel49-x86_64-pv

rhel49-x86_64-pv
[...]


If il mai sus comenzi do nu muncă, apoi virt-v2v is nu merge la muncă oricare. Remediați-vă
configurația libvirt sau serverul de la distanță înainte de a continua.

If il oaspete discuri sunt situat on a gazdă bloca dispozitiv, atunci conversia va eșua. Vedea
„CONVERSII XEN SAU SSH DE LA DISPOZIVELE BLOCATE” de mai jos pentru o soluție.

XEN: IMPORTARE A PENSIUNEA
Pentru a importa un anumit oaspete de pe un server Xen, faceți:

$ virt-v2v -ic 'xen+ssh://[e-mail protejat]'\
rhel49-x86_64-pv \
-o local -os / var / tmp

unde „rhel49-x86_64-pv” este numele oaspetelui (care trebuie închis).

În acest caz, steagurile de ieșire sunt setate să scrie oaspetele convertit într-un temporar
director, deoarece acesta este doar un exemplu, dar puteți scrie și în libvirt sau în oricare altul
tinta sustinuta.

XEN OR SSH CONVERSII DIN BLOC DISPOZITIVE
În prezent, virt-v2v nu poate accesa direct un oaspete Xen (sau orice oaspete aflat la distanță peste
ssh) dacă discurile acelui oaspete sunt localizate pe dispozitive de bloc gazdă.

Pentru a afla dacă un oaspete Xen folosește dispozitive de bloc gazdă, priviți XML-ul invitatului. Vei vedea:


...


unde „type=’block’”, „source dev=" și „/dev/...” sunt toate indicii că discul este
situat pe un dispozitiv de bloc gazdă.

Acest lucru se întâmplă deoarece driverul qemu ssh block pe care îl folosim pentru a accesa discurile de la distanță utilizează
protocolul ssh sftp, iar acest protocol nu poate detecta corect dimensiunea blocului gazdă
dispozitive.

Soluția este să copiați oaspetele pe serverul de conversie, folosind separat
virt-v2v-copy-to-local(1) instrument, urmat de rularea virt-v2v. Veți avea nevoie de suficiente
spațiu pe serverul de conversie pentru a stoca o copie completă a invitatului.

virt-v2v-copy-to-local -ic xen+ssh://[e-mail protejat] oaspete
virt-v2v -i libvirtxml guest.xml -o local -os / var / tmp
rm guest.xml guest-disk*

REZULTATE LA LIBVIRT

-o libvirt opțiunea vă permite să încărcați oaspetele convertit pe o gazdă gestionată de libvirt.
Există mai multe limitări:

· Puteți utiliza doar o conexiune libvirt locală [vezi mai jos cum să o rezolvi].

· -tu piscină opțiunea trebuie să specifice un pool de directoare, nu ceva mai exotic, cum ar fi
iSCSI [dar vezi mai jos].

· Puteți încărca numai într-un hypervisor KVM.

La producție la a la distanta libvirt instanță şi / sau a non-director depozitare piscină trebuie sa folosesti
următoarea soluție:

1. Folosiți virt-v2v în -o local pentru a converti discurile și metadatele invitate într-un mod local
director temporar:

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

Acest lucru creează două (sau mai multe) fișiere în / var / tmp numit:

/var/tmp/NAME.xml # XML-ul libvirt (metadate)
/var/tmp/NAME-sda # primul disc al oaspetelui

(în locul „NUMELE” înlocuiți numele oaspetelui).

2. Încărcați discul(ele) convertit(e) în pool-ul de stocare numit „POOL”:

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

3. Editați /var/tmp/NAME.xml pentru a schimba /var/tmp/NAME-sda la numele piscinei. Cu alte cuvinte,
localizați următorul bit de XML:







și modificați două lucruri: Atributul „type=’file’” trebuie schimbat în „type=’volume’”,
si " „elementul trebuie modificat pentru a include atributele „pool” și „volum”:


...

...


4. Definiți invitatul final în libvirt:

virsh define /var/tmp/NAME.xml

REZULTATE LA rhev

Această secțiune se aplică numai pentru -o rhev modul de ieșire. Dacă utilizați virt-v2v de la RHEV-M
interfață de utilizator, apoi în culise, importul este gestionat de VDSM folosind -o vdsm
modul de ieșire (pe care utilizatorii finali nu ar trebui să încerce să îl folosească direct).

Trebuie să specificați -o rhev si un -tu opțiunea care indică RHEV-M Export Storage
Domeniu. Puteți specifica fie serverul NFS și punctul de montare, de ex.
„-os rhev-storage:/rhev/export”, sau îl puteți monta mai întâi și indicați directorul
unde este montat, de ex. „-os /tmp/mnt”. Aveți grijă să nu indicați spre stocarea datelor
Domeniu din întâmplare, deoarece nu va funcționa.

La finalizarea cu succes, virt-v2v va fi scris noul oaspete în Export Storage
Domeniu, dar nu va fi încă gata de rulare. Trebuie importat în RHEV utilizând interfața de utilizare
înainte de a putea fi folosit.

În RHEV ≥ 2.2, acest lucru se face din fila Stocare. Selectați domeniul de export pe care a fost invitatul
scris la. Un panou va apărea sub lista de domenii de stocare afișând mai multe
file, dintre care una este „VM Import”. Oaspetele convertit va fi listat aici. Selectează
invitatul corespunzător și faceți clic pe „Import”. Consultați documentația RHEV pentru detalii suplimentare.

Dacă exportați mai mulți oaspeți, atunci îi puteți importa pe toți în același timp prin intermediul
UI.

RESURSĂ CERINȚE

Reţea
Cea mai importantă resursă pentru virt-v2v pare să fie lățimea de bandă a rețelei. Virt-v2v ar trebui
să poată copia datele oaspeților la viteze gigabit Ethernet sau mai mari.

Asigurați-vă că conexiunile de rețea dintre servere (server de conversie, server NFS,
vCenter, Xen) sunt cât mai rapide și cu latență cât mai scăzută.

Disc spaţiu
Virt-v2v plasează fișiere temporare potențial mari în $TMPDIR (care este / var / tmp dacă
nu-l seta). Utilizarea tmpfs este o idee proastă.

Pentru fiecare disc invitat, o suprapunere este stocată temporar. Aceasta stochează modificările făcute
în timpul conversiei și este folosit ca cache. Suprapunerile nu sunt deosebit de mari - zeci
sau sute mici de megaocteți pe disc sunt tipice. În plus față de suprapunere(e), introduceți
și metodele de ieșire pot folosi spațiu pe disc, așa cum este prezentat în tabelul de mai jos.

-i icre
Aceasta plasează temporar o copie completă a discurilor sursă necomprimate în $TMPDIR.

-o privire
Aceasta plasează temporar o copie completă a discurilor de ieșire în $TMPDIR.

-o local
-o whoa
Trebuie să vă asigurați că există suficient spațiu în directorul de ieșire pentru cele convertite
oaspete.

-o zero
Aceasta plasează temporar o copie completă a discurilor de ieșire în $TMPDIR.

VMware vCenter resurse
Copierea de pe VMware vCenter este în prezent destul de lentă, dar credem că aceasta este o problemă
cu VMware. Asigurarea că hypervisorul VMware ESXi și vCenter rulează pe hardware rapid
cu multă memorie ar trebui să atenueze acest lucru.

Calcula putere si RAM
Virt-v2v nu este deosebit de intensiv în calcul sau RAM. Dacă rulați multe în paralel
conversii, atunci puteți lua în considerare alocarea unui nucleu CPU și între 512 MB și 1 GB de
RAM pentru fiecare instanță care rulează.

Virt-v2v poate fi rulat într-o mașină virtuală.

POST-CONVERSIE SARCINI

Oaspete reţea configuraţie
Virt-v2v nu poate reconfigura în prezent configurația de rețea a unui oaspete. Dacă cel convertit
invitatul nu este conectat la aceeași subrețea ca și sursa, configurația rețelei poate
trebuie actualizate. Vezi si virt-personaliza(1).

Conversia a ferestre din oaspete
Când convertiți oaspeți Windows, procesul de conversie este împărțit în două etape:

1. Conversie offline.

2. Prima pornire.

Invitatul va fi bootabil după etapa de conversie offline, dar nu va avea încă pe toate
driverele necesare instalate pentru a funcționa corect. Acestea vor fi instalate automat
prima dată oaspeţii cizme.

NB Aveți grijă să nu întrerupeți procesul de instalare automată a driverului atunci când vă conectați
invitatului pentru prima dată, deoarece acest lucru poate împiedica oaspete să pornească ulterior
corect.

GRATUITA SPACE PENTRU CONVERSIE

Virt-v2v verifică că există suficient spațiu liber în sistemul de fișiere invitat pentru a efectua
conversie. In prezent se verifica:

Sistemul de fișiere rădăcină Linux sau unitatea Windows „C:”.
Spațiu liber minim: 20 MB

Linux / boot
Spațiu liber minim: 50 MB

Acest lucru se datorează faptului că trebuie să construim un nou initramfs pentru unele Enterprise Linux
conversii.

Orice alt sistem de fișiere montabil
Spațiu liber minim: 10 MB

ALERGARE VIRT-V2V AS ROOT OR NON-ROOT

Nimic din virt-v2v nu are nevoie în mod inerent de acces la rădăcină și va funcționa bine ca non-root
utilizator. Cu toate acestea, anumite caracteristici externe pot necesita fie root, fie un utilizator special:

Montarea domeniului de stocare de export
Atunci când se utilizează -o rhev -tu server:/esd virt-v2v trebuie să aibă suficiente privilegii pentru NFS
montați domeniul de stocare de export de pe „server”.

Puteți evita să aveți nevoie de root aici, montându-l singur înainte de a rula virt-v2v și
care trece -tu /punctul de montare în schimb, dar în primul rând citiți următoarea secțiune...

Se scrie în domeniul de stocare de export ca 36:36
RHEV-M nu poate citi fișiere și directoare din domeniul de stocare de export decât dacă acestea
au UID:GID 36:36. Veți vedea probleme de import de VM dacă UID:GID nu este corect.

Când rulați virt-v2v -o rhev ca root, virt-v2v încearcă să creeze fișiere și
directoare cu proprietatea corectă. Dacă rulați virt-v2v ca non-root, va fi
probabil că încă funcționează, dar va trebui să schimbați manual proprietatea după ce virt-v2v are
terminat.

Scriind la libvirt
Atunci când se utilizează -o libvirt, poate fi necesar să rulați virt-v2v ca rădăcină pentru a putea scrie în
instanța sistemului libvirt (adică „qemu:///system”) și la locația implicită pentru
imagini de disc (de obicei / var / lib / libvirt / images).

Puteți evita acest lucru setând autentificarea conexiunii libvirt, vezi
http://libvirt.org/auth.html. Alternativ, utilizați -oc qemu:///session, care va
scrieți în instanța dumneavoastră libvirt pentru fiecare utilizator.

Scriind la Glance
Acest lucru nu nu nevoie de root (de fapt, probabil că nu va funcționa), dar poate necesita fie a
utilizator special și/sau pentru ca dvs. să obțineți un script care stabilește mediul de autentificare
variabile. Consultați documentația Glance.

DEBUGARE RHEV-M IMPORT Eșecuri

Când exportați în domeniul de stocare de export RHEV-M, apoi importați acel oaspete prin
RHEV-M UI, este posibil să întâmpinați o eroare de import. Diagnosticarea acestor defecțiuni este
enervant de dificil, deoarece interfața de utilizare ascunde în general adevăratul motiv al eșecului.

Există două fișiere jurnal de interes. Primul este stocat pe serverul RHEV-M însuși și
se numește /var/log/ovirt-engine/engine.log

Al doilea fișier, care este cel mai util, se găsește pe gazda SPM (SPM înseamnă
„Manager de stocare”). Acesta este un nod RHEV care este ales pentru a realiza toate metadatele
modificări în centrul de date, cum ar fi crearea de imagini sau instantanee. Puteți afla
care gazdă este SPM-ul curent din fila „Gazde” coloana „Stare SPM”. Odata ce ai
localizați SPM-ul, conectați-vă la el și luați fișierul /var/log/vdsm/vdsm.log care va contine
mesaje de eroare detaliate de la comenzi de nivel scăzut.

MINIM XML PENTRU -i libvirtxml OPȚIUNE

Când utilizați -i libvirtxml opțiunea, trebuie să furnizați niște XML libvirt. Scriind asta
de la zero este greu, așa că șablonul de mai jos este util.

notițe acest să be utilizat pentru de testare şi / sau Unde tu ști ceea ce ești face! daca tu
au metadate libvirt pentru invitat, folosește-le întotdeauna în schimb.


NUME
1048576
2

hvm














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

MAȘINĂRIE DE CITIT REZULTATE

--citit de mașină opțiunea poate fi utilizată pentru a face ieșirea mai prietenoasă cu mașina, ceea ce
este util atunci când apelați virt-v2v din alte programe, GUI-uri etc.

Există două moduri de a utiliza această opțiune.

În primul rând, utilizați opțiunea pe cont propriu pentru a interoga capabilitățile binarului virt-v2v.
Ieșirea tipică arată astfel:

$ virt-v2v --lizibil de mașină
virt-v2v
libguestfs-rewrite
intrare: disc
[...]
ieșire: locală
[...]
convert: enterprise-linux
convert:windows

Este tipărită o listă de caracteristici, una pe linie, iar programul se iese cu starea 0.

Caracteristicile „input:” și „output:” se referă la -i si -o opțiuni (modul de intrare și de ieșire).
susținut de acest binar. Caracteristicile „conversie:” se referă la tipurile de invitați pe care acest binar
știe să convertească.

În al doilea rând, utilizați opțiunea împreună cu alte opțiuni pentru a realiza programul obișnuit
ieșire mai prietenoasă cu mașina.

În acest moment, aceasta înseamnă:

1. Mesajele din bara de progres pot fi analizate din stdout căutând acest obișnuit
expresie:

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

2. Programul de apelare ar trebui să trateze mesajele trimise către stdout (cu excepția barei de progres
mesaje) ca mesaje de stare. Acestea pot fi înregistrate și/sau afișate utilizatorului.

3. Programul care apelează ar trebui să trateze mesajele trimise către stderr ca mesaje de eroare. În
În plus, virt-v2v iese cu un cod de stare diferit de zero dacă a existat o eroare fatală.

Virt-v2v ≤ 0.9.1 nu a acceptat --citit de mașină opțiune deloc. Opțiunea a fost
adăugat când virt-v2v a fost rescris în 2014.

Utilizați virt-v2v online folosind serviciile onworks.net