virt-v2v - En ligne dans le Cloud

PROGRAMME:

Nom

virt-v2v - Convertir un invité pour utiliser KVM

SYNOPSIS

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 domaine-invité.xml -o local -os / Var / tmp

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

virt-v2v -i disk disk.img -o coup d'oeil

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

DESCRIPTION

Virt-v2v convertit les invités d'un hyperviseur étranger pour s'exécuter sur KVM. Il peut lire Linux et
Invités Windows s'exécutant sur VMware, Xen, Hyper-V et certains autres hyperviseurs, et convertissez
les vers KVM gérés par libvirt, OpenStack, oVirt, Red Hat Enterprise Virtualization (RHEV)
ou plusieurs autres cibles.

Il existe également un frontal compagnon appelé virt-p2v(1) qui se présente sous forme d'ISO, de CD ou de PXE
image qui peut être démarrée sur des machines physiques pour virtualiser ces machines (physique à
virtuel, ou p2v).

Cette page de manuel documente le virt-v2v réécrit inclus dans libguestfs ≥ 1.28.

CONTRIBUTION ET SORTIE MODES

┌────────────┐ ┌─────────▶ -o nul
-i disque ────────────┐ │ │ ─┘┌───────▶ -o local
-i ova ──────────┐ └──▶ │ virt-v2v │ ──┘┌───────▶ -o qemu
│ conversion │ ───┘┌────────────┐
VMware─▶┌────────────┐ │ serveur │ ────▶ -o libvirt │─▶ KVM
Xen -i libvirt │ │ │ (par défaut) │
... ───▶│ (par défaut) │ │ │ ──┐ └────────────┘
└────────────┘ │ │ ─┐└──────▶ -o coup d'œil
-i libvirtxml ─────────▶ │ │ ┐└─────────▶ -o rhev
└──────────▶ -o vdsm

Virt-v2v a un certain nombre de modes d'entrée et de sortie possibles, sélectionnés à l'aide du -i et -o
option. Un seul mode d'entrée et de sortie peut être sélectionné pour chaque exécution de virt-v2v.

-i disque est utilisé pour la lecture à partir d'images de disque local (principalement pour les tests).

-i libvirt est utilisé pour la lecture à partir de n'importe quelle source libvirt. Étant donné que libvirt peut se connecter à de nombreux
différents hyperviseurs, il est utilisé pour lire les invités de VMware, RHEL 5 Xen et plus encore.
VOTRE -ic L'option sélectionne la source précise de libvirt.

-i libvirtxml est utilisé pour lire les fichiers XML de libvirt. C'est la méthode utilisée par
virt-p2v(1) dans les coulisses.

-i ovules est utilisé pour la lecture à partir d'un fichier source VMware ova.

-o coup d'oeil est utilisé pour écrire sur OpenStack Glance.

-o libvirt est utilisé pour écrire sur n'importe quelle cible libvirt. Libvirt peut se connecter à un réseau local ou
hyperviseurs KVM distants. Les -oc L'option sélectionne la cible libvirt précise.

-o locales est utilisé pour écrire sur une image disque locale avec un fichier de configuration libvirt local
(principalement pour tester).

-o qemu écrit sur une image disque locale avec un script shell pour démarrer l'invité directement dans
qemu (principalement pour les tests).

-o rhév est utilisé pour écrire sur une cible RHEV-M / oVirt. -o vdsm n'est utilisé que lorsque virt-v2v
fonctionne sous contrôle VDSM.

--en place demande à virt-v2v de personnaliser le système d'exploitation invité dans la machine virtuelle d'entrée,
au lieu de créer une nouvelle VM dans l'hyperviseur cible.

EXEMPLES

Convertir VMware vCenter serveur à locales libvirt
Vous avez un serveur VMware vCenter appelé "vcenter.example.com", un centre de données appelé
"Datacenter", et un hyperviseur ESXi appelé "esxi". Vous souhaitez convertir un invité appelé
"vmware_guest" à exécuter localement sous libvirt.

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

Dans ce cas, vous devrez probablement exécuter virt-v2v en tant que "root", car il doit parler
sur le démon libvirt du système et copiez les disques invités sur / var / lib / libvirt / images.

Pour plus d'informations, voir "ENTRÉE DU SERVEUR VMWARE VCENTER" ci-dessous.

Convertir VMware à RHEV-M/oVirt
C'est le même que l'exemple précédent, sauf que vous voulez envoyer l'invité à un RHEV-M
Exporter le domaine de stockage qui est situé à distance (sur NFS) dans "rhev.nfs:/export_domain".
Si vous n'êtes pas sûr de l'emplacement du domaine de stockage d'exportation, vous devez vérifier la
paramètres sur votre console de gestion RHEV-M. Les interfaces réseau invitées sont connectées à
le réseau cible appelé "rhevm".

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

Dans ce cas, l'hôte exécutant virt-v2v agit comme un Conversion serveur.

Notez qu'après la conversion, l'invité apparaîtra dans le domaine de stockage d'exportation RHEV-M,
d'où vous devrez l'importer à l'aide de l'interface utilisateur RHEV-M. (Voir "SORTIE VERS
RHEV").

Convertir disque image à Pile ouverte coup d'oeil
Étant donné une image disque d'un autre hyperviseur que vous souhaitez convertir pour l'exécuter sur OpenStack
(seul OpenStack basé sur KVM est pris en charge), vous pouvez faire :

virt-v2v -i disk disk.img -o coup d'oeil

Pour contrôler le nom de l'image dans Glance, utilisez le -On option.

Convertir disque image à disque image
Étant donné une image disque d'un autre hyperviseur que vous souhaitez convertir pour l'exécuter sur KVM, vous
avoir deux options. Le plus simple est d'essayer :

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

où virt-v2v devine tout sur l'entrée disque.img et (dans ce cas) écrit le
résultat converti en / Var / tmp.

Une méthode plus complexe consiste à écrire du XML libvirt décrivant l'invité d'entrée (si vous pouvez
obtenir l'hyperviseur source pour vous fournir libvirt XML, alors tant mieux). Tu
peut alors faire :

virt-v2v -i libvirtxml domaine-invité.xml -o local -os / Var / tmp

Depuis que domaine-invité.xml contient le(s) chemin(s) d'accès aux images disque invité(s) dont vous n'avez pas besoin
spécifiez le nom de l'image disque sur la ligne de commande.

Pour convertir une image disque locale et la démarrer immédiatement dans qemu local, procédez comme suit :

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

SUPPORT MATRIX

Hyperviseurs (Saisir)
VMware ESXi
Doit être géré par VMware vCenter ≥ 5.0. L'entrée directe non gérée d'ESXi n'est pas
prise en charge.

OVA exporté depuis VMware
Les OVA d'autres hyperviseurs ne fonctionneront pas.

RHEL 5Xen
Citrix Xen
Citrix Xen n'a pas été testé récemment.

Hyper-V
Pas testé récemment. Nécessite que vous exportiez le disque ou que vous utilisiez virt-p2v(1) sur Hyper-V.

Directement à partir d'images disque
Uniquement les images disque exportées à partir d'hyperviseurs pris en charge et à l'aide de formats de conteneur
soutenu par qemu.

Machines physiques
Le virt-p2v(1) outil.

Hyperviseurs (Production)
QEMU et KVM uniquement.

Virtualisation gestion les systèmes (Production)
Aperçu d'OpenStack
Red Hat Enterprise Virtualization (RHEV) 2.2 et versions ultérieures
libvirt local
Et donc Virsh(1), virt-manager(1), et des outils similaires.

Disque local

Invites
Red Hat Entreprise Linux 3, 4, 5, 6, 7
CentOS3, 4, 5, 6, 7
Linux scientifique 3, 4, 5, 6, 7
Oracle Linux
Fedora
SLES 10 et plus
OpenSUSE 10 et versions ultérieures
Windows XP à Windows 8.1 / Windows Server 2012 R2
Nous utilisons les numéros de version internes de Windows, voir
https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions

Actuellement, NT 5.2 à NT 6.3 sont pris en charge.

Voir « WINDOWS » ci-dessous pour des notes supplémentaires sur la conversion des invités Windows.

INVITÉ firmware
BIOS ou UEFI pour tous les types d'invités (mais voir "UEFI" ci-dessous).

OPTIONS

--Aidez-moi
Afficher l'aide.

-b
--pont
See --réseau ci-dessous.

--comprimé
Écrivez un fichier de sortie compressé. Ceci n'est autorisé que si le format de sortie est qcow2
(voir -de ci-dessous) et équivaut à la -c option de qemu-img (1).

--dcpath Dossier/Centre de données
NB: Vous n'avez pas besoin d'utiliser ce paramètre si vous avez libvirt ≥ 1.2.20.

Pour VMware vCenter, remplacez le paramètre « dcPath=... » utilisé pour sélectionner le centre de données.
Virt-v2v peut généralement le calculer à partir de l'URI "vpx://", mais s'il se trompe,
alors vous pouvez le remplacer en utilisant ce paramètre. Accédez à votre interface de dossier Web vCenter,
par exemple. "https://vcenter.example.com/dossier" (sans une barre oblique finale) et examinez le
paramètre "dcPath=" dans les URL qui apparaissent sur cette page.

--debug-gc
Déboguer le ramasse-miettes et l'allocation de mémoire. Ceci n'est utile que lors du débogage
problèmes de mémoire dans virt-v2v ou les liaisons OCaml libguestfs.

--debug-overlays
Enregistrez le ou les fichiers de superposition créés lors de la conversion. Cette option n'est utilisée que pour
débogage virt-v2v et peut être supprimé dans une future version.

-i disque
Réglez la méthode de saisie sur disque.

Dans ce mode, vous pouvez lire une image disque de machine virtuelle sans métadonnées. virt-v2v
essaie de deviner les meilleures métadonnées par défaut. C'est généralement suffisant, mais vous pouvez obtenir
un contrôle plus fin (par exemple de la mémoire et des vCPU) en utilisant -i libvirtxml au lieu. Invités uniquement
qui utilisent un seul disque peuvent être importés de cette façon.

-i libvirt
Réglez la méthode de saisie sur libvirt. C'est la valeur par défaut.

Dans ce mode, vous devez spécifier un nom d'invité libvirt ou un UUID sur la ligne de commande.
Vous pouvez également spécifier un URI de connexion libvirt (voir -ic).

-i libvirtxml
Réglez la méthode de saisie sur libvirtxml.

Dans ce mode, vous devez passer un fichier XML libvirt sur la ligne de commande. Ce fichier est
lire afin d'obtenir des métadonnées sur l'invité source (telles que son nom, la quantité de
mémoire), et aussi pour localiser les disques d'entrée. Voir « XML MINIMAL POUR -i libvirtxml
OPTION" ci-dessous.

-i locales
C'est la même chose que -i disque.

-i ovules
Réglez la méthode de saisie sur ovules.

Dans ce mode, vous pouvez lire un fichier VMware ova. Virt-v2v lira le fichier manifeste ova
et vérifiez la validité des volumes vmdk (sommes de contrôle) ainsi que l'analyse du fichier ovf,
puis convertissez l'invité. Voir "ENTRÉE DE VMWARE OVA" ci-dessous

-ic libvirtURI
Spécifiez un URI de connexion libvirt à utiliser lors de la lecture de l'invité. Ceci n'est utilisé que
quand -je libvirt.

Uniquement les connexions libvirt locales, les connexions VMware vCenter ou la télécommande RHEL 5 Xen
les connexions peuvent être utilisées. Les autres connexions libvirt distantes ne fonctionneront pas en général.

Voir également "ENTRÉE DE VMWARE VCENTER SERVER", "ENTRÉE DE RHEL 5 XEN" ci-dessous.

-si le format
Pour -i disque uniquement, cela spécifie le format de l'image disque d'entrée. Pour d'autres entrées
méthodes, vous devez spécifier le format d'entrée dans les métadonnées.

--en place
Ne créez pas de machine virtuelle de sortie dans l'hyperviseur cible. A la place, ajustez le
OS invité dans la machine virtuelle source à exécuter dans l'hyperviseur d'entrée.

Ce mode est destiné à l'intégration avec d'autres ensembles d'outils, qui prennent la responsabilité
de convertir la configuration de la VM, en prévoyant un rollback en cas d'erreur,
transformer le stockage, etc.

Conflits avec tous -o * options.

--lisible par machine
Cette option est utilisée pour rendre la sortie plus conviviale pour la machine lorsqu'elle est analysée par
d'autres programmes. Voir "SORTIE LISIBLE PAR LA MACHINE" ci-dessous.

-n entrée:sortie
-n ande
--réseau entrée:sortie
--réseau ande
-b entrée:sortie
-b ande
--pont entrée:sortie
--pont ande
Mapper le réseau (ou pont) appelé "in" vers le réseau (ou pont) appelé "out". Si non "dans :"
préfixe est donné, tous les autres réseaux (ou ponts) sont mappés sur "out".

Voir "RÉSEAUX ET PONTS" ci-dessous.

--pas de copie
Ne copiez pas les disques. Au lieu de cela, la conversion est effectuée (et jetée), et
les métadonnées sont écrites, mais aucun disque n'est créé. Voir aussi la discussion sur -o nul ci-dessous.

Ceci est utile dans deux cas : Soit vous voulez tester si la conversion est susceptible de
réussir, sans le long processus de copie. Ou vous êtes seulement intéressé à regarder
les métadonnées.

Cette option n'est pas compatible avec -o libvirt car cela créerait un invité défectueux
(un sans disques).

Cette option n'est pas compatible avec -o coup d'oeil pour des raisons techniques.

--pas de coupe tous
--pas de coupe mp[, mp...]
Par défaut, virt-v2v s'exécute fstream(8) pour réduire la quantité de données à
copié. Ceci est connu pour casser certains chargeurs de démarrage bogués provoquant des échecs de démarrage après
conversion (voir par exemple https://bugzilla.redhat.com/show_bug.cgi?id=1141145#c27).

Vous pouvez utiliser --pas de coupe tous pour désactiver tous les rognages. Notez que cela augmentera considérablement
la quantité de données qui doit être copiée et peut ralentir virt-v2v.

Vous pouvez également désactiver le rognage sur les systèmes de fichiers sélectionnés uniquement (spécifié par une virgule).
liste séparée de leur(s) point(s) de montage dans l'invité). Typiquement, vous utiliseriez
--pas de coupe / boot pour contourner le bug de grub mentionné ci-dessus.

Vous pouvez également désactiver le rognage sur les partitions en utilisant le schéma de nommage libguestfs pour
appareils, par exemple : --pas de coupe / dev / sdb2 signifie ne pas couper la deuxième partition sur la deuxième
dispositif de bloc. Utilisation systèmes de fichiers virt(1) pour lister les noms de système de fichiers dans un invité.

-o disque
C'est la même chose que -o locales.

-o coup d'oeil
Définissez la méthode de sortie sur OpenStack Glance. Dans ce mode, l'invité converti est
téléchargé sur Glance. Vous pouvez contrôler le nom de l'image en définissant le -On option.

-o libvirt
Définissez la méthode de sortie sur libvirt. C'est la valeur par défaut.

Dans ce mode, l'invité converti est créé en tant qu'invité libvirt. Vous pouvez également préciser
un URI de connexion libvirt (voir -oc).

Voir "SORTIE VERS LIBVIRT" ci-dessous.

-o locales
Définissez la méthode de sortie sur locales.

Dans ce mode, l'invité converti est écrit dans un répertoire local spécifié par -OS
/rép (le répertoire doit exister). Les disques de l'invité converti sont écrits sous la forme :

/dir/nom-sda
/dir/nom-sdb
[etc]

et un fichier XML libvirt est créé contenant les métadonnées d'invité :

/dir/nom.xml

où "nom" est le nom de l'invité.

-o nul
Définissez la méthode de sortie sur nul.

L'invité est converti et copié (sauf si vous spécifiez également --pas de copie), mais les résultats
sont jetés et aucune métadonnée n'est écrite.

-o éviter
C'est la même chose que -o rhév.

-o qemu
Définissez la méthode de sortie sur qemu.

Ceci est similaire à -o locales, sauf qu'un script shell est écrit que vous pouvez utiliser
pour démarrer l'invité dans qemu. Les disques convertis et le script shell sont écrits dans le
répertoire spécifié par -OS.

Lorsque vous utilisez ce mode de sortie, vous pouvez également spécifier le --qemu-boot option qui bottes
l'invité sous qemu immédiatement.

-o rhév
Définissez la méthode de sortie sur rhév.

L'invité converti est écrit dans un domaine de stockage d'exportation RHEV. Les -OS paramètre
doit également être utilisé pour spécifier l'emplacement du domaine de stockage d'exportation. Notez ceci
n'importe pas réellement l'invité dans RHEV. Vous devez le faire manuellement plus tard
à l'aide de l'interface utilisateur.

Voir "SORTIE VERS RHEV" ci-dessous.

-o vdsm
Définissez la méthode de sortie sur vdsm.

Ce mode est similaire à -o rhév, mais le chemin complet vers le domaine de données doit être indiqué :
/rhev/data-center/ /. Ce mode n'est utilisé que lorsque
virt-v2v fonctionne sous le contrôle de VDSM.

-oa clairsemé
-oa préalloué
Définissez le mode d'allocation du fichier de sortie. La valeur par défaut est "sparse".

-oc libvirtURI
Spécifiez une connexion libvirt à utiliser lors de l'écriture de l'invité converti. C'est seulement
utilisé quand -o libvirt. Voir "SORTIE VERS LIBVIRT" ci-dessous.

Seules les connexions libvirt locales peuvent être utilisées. Les connexions libvirt à distance ne fonctionneront pas.

-de le format
Lors de la conversion de l'invité, convertissez les disques au format donné.

S'il n'est pas spécifié, le format d'entrée est utilisé.

-On prénom
Renommez l'invité lors de sa conversion. Si cette option n'est pas utilisée, le nom de sortie
est le même que le nom d'entrée.

-OS storage
L'emplacement du stockage pour l'invité converti.

Pour -o libvirt, il s'agit d'un pool de répertoires libvirt (voir "virsh pool-list") ou d'un UUID de pool.

Pour -o locales et -o qemu, il s'agit d'un nom de répertoire. Le répertoire doit exister.

Pour -o rhév, il peut s'agir d'un chemin NFS du domaine de stockage d'exportation de la forme
" : ", par exemple:

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

L'export NFS doit être montable et accessible en écriture par l'utilisateur et l'hôte exécutant virt-v2v,
puisque le programme virt-v2v doit réellement le monter lorsqu'il s'exécute. Donc tu as probablement
devez exécuter virt-v2v en tant que "root".

Ou: Vous pouvez monter vous-même le domaine de stockage d'exportation et pointer -OS au point de montage.
Notez que virt-v2v devra toujours écrire dans ce répertoire distant, donc virt-v2v
encore besoin de s'exécuter en tant que "root".

Vous obtiendrez une erreur si virt-v2v est incapable de monter/écrire sur le stockage d'exportation
Domaine.

--password-fichier filet
Au lieu de demander le(s) mot(s) de passe de manière interactive, transmettez le mot de passe dans un fichier.
Notez que le fichier doit contenir le mot de passe complet, sans tout traînant nouvelle ligne, Et pour
sécurité, le fichier doit avoir le mode 0600 afin que les autres ne puissent pas le lire.

--print-source
Imprimez les informations sur l'invité source et arrêtez. Cette option est utile lorsque vous êtes
mise en place de cartes de réseau et de pont. Voir "RÉSEAUX ET PONTS".

--qemu-boot
Lors de l'utilisation -o qemu seulement, cela démarre l'invité immédiatement après la fin de virt-v2v.

-q
--silencieux
Cela désactive les barres de progression et autres sorties inutiles.

--racine demander
--racine unique
--racine premier
--racine / dev / sdX
--racine /dev/VG/LV
Choisissez le système de fichiers racine à convertir.

Dans le cas où la machine virtuelle est à double amorçage ou multi-boot, ou où la VM a
d'autres systèmes de fichiers qui ressemblent à des systèmes d'exploitation, cette option peut être utilisée pour sélectionner
le système de fichiers racine (alias lecteur "C:" ou /) du système d'exploitation qui doit être
converti. La console de récupération Windows, certains lecteurs de DVD connectés et les bogues dans
l'heuristique d'inspection de libguestfs, peut faire ressembler un invité à un multi-boot fonctionnant
système.

La valeur par défaut dans virt-v2v ≤ 0.7.1 était --root unique, ce qui provoque la mort de virt-v2v si un
système d'exploitation multi-démarrage est trouvé.

Depuis virt-v2v 0.7.2, la valeur par défaut est maintenant --root demander: Si la VM s'avère être multi-
boot, alors virt-v2v s'arrêtera et répertoriera les systèmes de fichiers racine possibles et demandera à l'utilisateur
lequel utiliser. Cela nécessite que virt-v2v soit exécuté de manière interactive.

--root d'abord signifie choisir le premier périphérique racine dans le cas d'un multi-boot
système opérateur. Comme il s'agit d'une heuristique, il peut parfois choisir la mauvaise.

Vous pouvez également nommer un périphérique racine spécifique, par exemple. --root /dev/sda2 signifierait utiliser le
deuxième partition sur le premier disque dur. Si le périphérique racine nommé n'existe pas ou
n'a pas été détecté en tant que périphérique racine, virt-v2v échouera.

Notez qu'il y a un bogue dans grub qui l'empêche de démarrer avec succès un
système multiboot si VirtIO est activé. Grub ne peut démarrer qu'un système d'exploitation
du premier disque VirtIO. Spécifiquement, / boot doit être sur le premier disque VirtIO, et
il ne peut pas charger en chaîne un système d'exploitation qui n'est pas dans le premier disque VirtIO.

--vdsm-image-uuid UUID
--vdsm-vol-uuid UUID
--vdsm-vm-uuid UUID
--vdsm-ovf-sortie
Normalement, le mode de sortie RHEV choisit des UUID aléatoires pour l'invité cible. Cependant VDSM
doit contrôler les UUID et transmettre ces paramètres lorsque virt-v2v s'exécute sous VDSM
contrôler. Les paramètres contrôlent :

· le répertoire image de chaque disque invité (--vdsm-image-uuid) (cette option est passée
une fois pour chaque disque invité)

· UUID pour chaque disque invité (--vdsm-vol-uuid) (cette option est passée une fois pour chaque
disque invité)

· le nom du fichier OVF (--vdsm-vm-uuid).

· le répertoire de sortie OVF (répertoire courant par défaut) (--vdsm-ovf-sortie).

Le format des UUID est : "12345678-1234-1234-1234-123456789abc" (chaque chiffre hexadécimal peut être
"0-9" ou "af"), conforme à OSF DCE 1.1.

Ces options ne peuvent être utilisées qu'avec -o vdsm.

-v
--verbeux
Activez les messages détaillés pour le débogage.

-V
--version
Afficher le numéro de version et quitter.

--typevm à poser
--typevm serveur
Pour le -o rhév or -o vdsm cibles uniquement, spécifiez le type d'invité. Vous pouvez définir ceci
vers « bureau » ou « serveur ». Si l'option n'est pas donnée, une valeur par défaut appropriée est
choisi en fonction du système d'exploitation invité détecté.

-x Activez le traçage des appels d'API libguestfs.

XEN PARAVIRTUALISÉ INVITES

Les anciennes versions de virt-v2v pouvaient transformer un invité paravirtualisé (PV) Xen en un invité KVM en
installer un nouveau noyau. Cette version de virt-v2v ne ne sauraient essayez d'installer un nouveau
graines. Au lieu de cela, il vous donnera une erreur s'il y a uniquement Noyaux Xen PV disponibles.

Par conséquent, avant la conversion, vous devez vérifier qu'un noyau standard est installé. Pour certains
anciennes distributions Linux, cela signifie installer un noyau à partir du tableau ci-dessous :

RHEL 3 (ne s'applique pas, car il n'y avait pas de noyau PV Xen)

RHEL 4 i686 avec > 10 Go de RAM : installez 'kernel-hugemem'
i686 SMP : installer 'kernel-smp'
autre i686 : installez le « noyau »
x86-64 SMP avec > 8 processeurs : installez « kernel-largesmp »
x86-64 SMP : installez 'kernel-smp'
autre x86-64 : installez le « noyau »

RHEL 5 i686 : installer 'kernel-PAE'
x86-64 : installez le « noyau »

SLES 10 i586 avec > 10 Go de RAM : installez « kernel-bigsmp »
i586 SMP : installer 'kernel-smp'
autre i586 : installez 'kernel-default'
x86-64 SMP : installez 'kernel-smp'
autre x86-64 : installez 'kernel-default'

SLES 11+ i586 : installez « kernel-pae »
x86-64 : installez 'kernel-default'

Windows (ne s'applique pas, car il n'y a pas de noyau Windows Xen PV)

ACTIVATION VIRTIO

" Virtio " est le nom d'un ensemble de pilotes qui font le disque (bloc périphérique), le réseau et
d'autres opérations d'invité fonctionnent beaucoup plus rapidement sur KVM.

Les anciennes versions de virt-v2v pouvaient installer ces pilotes pour certains invités Linux. Cette
la version de virt-v2v fait ne sauraient tenter d'installer de nouveaux noyaux ou pilotes Linux, mais
vous avertir s'ils ne sont pas déjà installés.

Afin d'activer virtio, et donc d'améliorer les performances de l'invité après la conversion,
vous devez vous assurer que le minimum les versions des packages sont installées avant conversion,
en consultant le tableau ci-dessous.

RHEL 3 Aucun pilote virtio n'est disponible

Noyau RHEL 4 >= 2.5.9-89.EL
lvm2 >= 2.02.42-5.el4
mappeur de périphérique >= 1.02.28-2.el4
selinux-policy-targeted >= 1.17.30-2.152.el4
policycoreutils >= 1.18.1-4.13

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

RHEL 6+ Toutes les versions prennent en charge virtio

Fedora Toutes les versions prennent en charge virtio

SLES 11+ Toutes les versions prennent en charge virtio

Noyau SLES 10 >= 2.6.16.60-0.85.1

OpenSUSE 11+ Toutes les versions prennent en charge virtio

Noyau OpenSUSE 10 >= 2.6.25.5-1.1

Les pilotes Windows sont installés à partir du répertoire pointé par
Variable d'environnement "VIRTIO_WIN"
(/usr/share/virtio-win par défaut) si présent

RHEL 4

SELinux renommer apparaît à accrocher toujours
Dans RHEL ≤ 4.7, il y avait un bogue qui faisait que le réétiquetage SELinux semblait se bloquer pour toujours
à l'adresse suivante :

*** Avertissement -- Un nouveau libellé SELinux est requis. ***
*** Désactivation de l'application de la sécurité. ***
*** Le réétiquetage peut prendre beaucoup de temps, ***
*** selon la taille du système de fichiers. ***

En réalité, il attend que vous appuyiez sur une touche (mais il n'y a aucune indication visuelle de
cette). Vous pouvez soit appuyer sur la touche "[Retour]", à quel point l'invité terminera
réétiqueter et redémarrer, ou vous pouvez installer policycoreutils ≥ 1.18.1-4.13 avant de commencer
la conversion v2v. Voir aussi https://bugzilla.redhat.com/show_bug.cgi?id=244636

FENÊTRES

botte échec: 0x0000007B
Cet échec de démarrage est dû au fait que Windows est incapable de trouver ou de charger le bon pilote de disque
(par exemple. vistor.sys). Si vous rencontrez cette erreur, voici quelques points à vérifier :

· Assurez-vous d'abord que l'invité démarre sur l'hyperviseur source avant la conversion.

· Vérifiez que les pilotes Windows virtio sont disponibles dans /usr/share/virtio-win, Et Ce
virt-v2v n'a imprimé aucun avertissement indiquant l'impossibilité d'installer les pilotes virtio.

Sur Red Hat Enterprise Linux 7, vous devrez installer les pilotes signés disponibles
dans le package "virtio-win". Si vous n'avez pas accès aux pilotes signés, alors
vous devrez probablement désactiver la signature du pilote dans les menus de démarrage.

· Vérifiez que vous présentez une interface virtio-blk (ne sauraient virtio-scsi et ne sauraient ide) à
l'invité. Sur la ligne de commande qemu/KVM, vous devriez voir quelque chose de similaire à ceci :

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

Dans libvirt XML, vous devriez voir :



· Vérifiez que la stratégie de groupe Windows n'empêche pas l'installation du pilote ou
utilisé. Essayez de supprimer la stratégie de groupe Windows avant la conversion.

· Vérifiez qu'il n'y a aucun antivirus ou autre logiciel qui implémente une stratégie de groupe
interdictions d'installer ou d'utiliser de nouveaux pilotes.

· Activez le débogage de démarrage et vérifiez le vistor.sys le pilote est en cours de chargement.

Pile ouverte et Windows réactivation
OpenStack n'offre pas d'adresses de périphérique/PCI stables aux invités. Chaque fois qu'il crée
ou démarre un invité, il régénère le XML libvirt pour cet invité à partir de zéro. Les
libvirt XML n'aura pas des champs. Libvirt attribuera ensuite des adresses aux appareils,
de manière prévisible. Les adresses peuvent changer si l'une des conditions suivantes est vraie :

· Un nouveau disque ou périphérique réseau a été ajouté ou supprimé de l'invité.

· La version d'OpenStack ou (éventuellement) de libvirt a changé.

Parce que Windows n'aime pas les modifications "matérielles" de ce type, cela peut déclencher Windows
réactivation.

Cela peut également empêcher le démarrage avec une erreur 7B [voir la section précédente] si l'invité a
stratégie de groupe contenant « Restrictions d'installation de périphérique ».

UEFI

VMware vous permet de présenter le micrologiciel UEFI aux invités (au lieu du BIOS PC ordinaire).
Virt-v2v peut convertir ces invités, mais nécessite que l'UEFI soit pris en charge par la cible
hyperviseur.

Actuellement, KVM prend en charge OVMF, un micrologiciel UEFI partiellement open source, et peut les exécuter
clients.

Étant donné que la prise en charge d'OVMF n'a été ajoutée à KVM que récemment (en 2014/2015), tous ne ciblent pas
les environnements prennent encore en charge les invités UEFI :

UEFI sur libvirt, qemu
Prise en charge. Virt-v2v générera automatiquement le bon XML libvirt (métadonnées),
mais notez que la même version d'OVMF doit être installée sur l'hôte de conversion tel quel
installé sur l'hyperviseur cible, sinon vous devrez ajuster les chemins dans le
métadonnées.

UEFI sur OpenStack
Non supporté.

UEFI sur RHEV
Non supporté.

NETWORKS ET DES PONTS

Les invités sont généralement connectés à un ou plusieurs réseaux, et lorsqu'ils sont convertis en cible
hyperviseur, vous souhaitez généralement reconnecter ces réseaux à la destination. Les options
--réseau et --pont vous permet de le faire.

Si vous n'êtes pas sûr des réseaux et ponts utilisés sur l'hyperviseur source, alors
vous pouvez examiner les métadonnées source (libvirt XML, informations vCenter, etc.). Ou tu peux
exécutez virt-v2v avec le --print-source option qui oblige virt-v2v à imprimer le
informations dont il dispose sur l'invité sur la source, puis quittez.

Dans le --print-source sortie, vous verrez une section montrant l'interface réseau de l'invité
Cartes (NIC) :

$ virt-v2v [-i ...] --nom de la source d'impression
[...]
Cartes réseau :
Réseau mac "par défaut": 52:54:00:d0:cf:0e

C'est typique d'un invité libvirt : il a une seule interface réseau connectée à un
réseau appelé "par défaut".

Pour mapper un réseau spécifique à un réseau cible, par exemple "par défaut" sur la source à
"rhevm" sur la cible, utilisez :

virt-v2v [...] --network par défaut : rhevm

Pour mapper chaque réseau à un réseau cible, utilisez :

virt-v2v [...] --réseau rhevm

Les ponts sont gérés de la même manière, mais vous devez utiliser le --pont option à la place. Pour
Exemple:

$ virt-v2v [-i ...] --nom de la source d'impression
[...]
Cartes réseau :
Pont "br0"

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

CONTRIBUTION De VMWARE VCENTRE SERVEUR

Virt-v2v est capable d'importer des invités depuis VMware vCenter Server.

vCenter ≥ 5.0 est requis. Si vous n'avez pas vCenter, il est recommandé d'utiliser OVA à la place
(voir "ENTRÉE DE VMWARE OVA" ci-dessous), ou si cela n'est pas possible, voir "ENTRÉE DE
HYPERVISEUR VMWARE ESXi".

Virt-v2v utilise libvirt pour accéder à vCenter, et donc le mode d'entrée doit être -i
libvirt. Comme il s'agit de la valeur par défaut, vous n'avez pas besoin de le spécifier sur la ligne de commande.

VCENTER : ENLEVER VMWARE OUTILS De FENÊTRES INVITES
Pour les invités Windows, vous devez supprimer les outils VMware avant la conversion. Bien que ce soit
pas strictement nécessaire, et l'invité pourra toujours courir, si vous ne le faites pas, alors
l'invité converti se plaindra à chaque démarrage. Les outils ne peuvent pas être retirés après
conversion car le programme de désinstallation vérifie s'il s'exécute sur VMware et refuse de démarrer
(ce qui est aussi la raison pour laquelle virt-v2v ne peut pas les supprimer).

Cela n'est pas nécessaire pour les invités Linux, car virt-v2v est capable de supprimer les outils VMware.

VCENTER : URI
L'URI libvirt d'un serveur vCenter ressemble à ceci :

vpx://user@server/Datacenter/esxi

où:

"utilisateur@"
est l'utilisateur (facultatif, mais recommandé) sous lequel se connecter.

Si le nom d'utilisateur contient une barre oblique inverse (par exemple, "DOMAIN\USER"), vous devrez alors URI-
échapper à ce caractère en utilisant %5c : "DOMAIN%5cUSER" (5c est le code ASCII hexadécimal pour
barre oblique inverse.) D'autres signes de ponctuation peuvent également devoir être échappés.

"serveur"
est le serveur vCenter (ne sauraient hyperviseur).

"Centre de données"
est le nom du centre de données.

Si le nom contient un espace, remplacez-le par le code d'échappement URI %20.

"esxi"
est le nom de l'hyperviseur ESXi exécutant l'invité.

Si le déploiement VMware utilise des dossiers, ceux-ci devront peut-être être ajoutés à l'URI, par exemple :

vpx://utilisateur@serveur/Dossier/Datacenter/esxi

Pour plus de détails sur les URI libvirt, voir : http://libvirt.org/drvesx.html

Les erreurs typiques de libvirt / virsh lorsque l'URI est incorrect incluent :

· Impossible de trouver le centre de données spécifié dans [...]

· Impossible de trouver la ressource de calcul spécifiée dans [...]

· Le chemin [...] ne spécifie pas de ressource de calcul

· Le chemin [...] ne spécifie pas de système hôte

· Impossible de trouver le système hôte spécifié dans [...]

VCENTER : TEST LIBVIRT CONNEXION À VCENTRE
Utilisez l'option Virsh(1) commande pour répertorier les invités sur le serveur vCenter comme ceci :

$ virsh -c 'vpx://[email protected]/Datacenter/esxi' list --all
Saisissez le mot de passe root pour vcenter.example.com : ***

Identifiant Nom État
-------------------------------------------------- -
- Fedora 20 éteint
- Windows 2003 éteint

Si vous obtenez une erreur "Le certificat homologue ne peut pas être authentifié avec les certificats CA donnés"
ou similaire, vous pouvez soit importer le certificat de l'hôte vCenter, soit contourner la signature
vérification en ajoutant le drapeau "?no_verify=1":

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

Vous devriez également essayer de vider les métadonnées de n'importe quel invité sur votre serveur, comme ceci :

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

Windows 2003
[...]


If le au dessus de commandes do ne sauraient travailler, puis virt-v2v is ne sauraient aller à travail non plus. Réparez votre
configuration de libvirt et/ou votre serveur VMware vCenter avant de continuer.

VCENTER : IMPORTATION A CLIENT
Pour importer un invité particulier depuis vCenter Server, procédez comme suit :

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

où "Windows 2003" est le nom de l'invité (qui doit être arrêté).

Notez qu'il peut vous être demandé le mot de passe vCenter deux fois. Cela se produit une fois parce que
libvirt en a besoin, et une deuxième fois parce que virt-v2v lui-même se connecte directement au
serveur. Utilisation --password-fichier de fournir un mot de passe via un fichier.

Dans ce cas, les indicateurs de sortie sont définis pour écrire l'invité converti dans un fichier temporaire
répertoire car ce n'est qu'un exemple, mais vous pouvez également écrire dans libvirt ou tout autre
cible prise en charge.

VCENTER : NON-ADMINISTRATEUR RÔLE
Au lieu d'utiliser le rôle d'administrateur vCenter, vous pouvez créer un non-administrateur personnalisé
rôle pour effectuer la conversion. Vous devrez cependant lui donner un minimum de
autorisations comme suit :

1. Créez un rôle personnalisé dans vCenter.

2. Activez (vérifiez) les objets suivants :

Magasin de données:
- Parcourir la banque de données
- Opérations sur les fichiers de bas niveau

Session:
- Valider la séance

Machine virtuelle:
Approvisionnement:
- Autoriser l'accès au disque
- Autoriser l'accès au disque en lecture seule
- Gestion du système d'exploitation invité par l'API VIX

CONTRIBUTION De VMWARE OVA

Virt-v2v est capable d'importer des invités à partir des fichiers OVA (Open Virtualization Appliance) de VMware.
Seuls les OVA exportés depuis VMware vSphere fonctionneront.

OAV : ENLEVER VMWARE OUTILS De FENÊTRES INVITES
Pour les invités Windows, vous devez supprimer les outils VMware avant la conversion. Bien que ce soit
pas strictement nécessaire, et l'invité pourra toujours courir, si vous ne le faites pas, alors
l'invité converti se plaindra à chaque démarrage. Les outils ne peuvent pas être retirés après
conversion car le programme de désinstallation vérifie s'il s'exécute sur VMware et refuse de démarrer
(ce qui est aussi la raison pour laquelle virt-v2v ne peut pas les supprimer).

Cela n'est pas nécessaire pour les invités Linux, car virt-v2v est capable de supprimer les outils VMware.

OAV : CREATE OVA
Pour créer un OVA dans vSphere, utilisez l'option "Exporter le modèle OVF" (à partir du contexte VM
ou à partir du menu Fichier). Soit "Dossier de fichiers" (OVF) soit "Fichier unique" (OVA)
travail, mais OVA est probablement plus facile à gérer. Les fichiers OVA ne sont en réalité que du goudron non compressé
fichiers, vous pouvez donc utiliser des commandes telles que "tar tf VM.ova" pour afficher leur contenu.

Créez OVA au outil multifonction

Vous pouvez également utiliser « ovftool » propriétaire de VMware :

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

Pour vous connecter à vCenter :

ovftool --noSSLVerify \
vi://UTILISATEUR :[email protected]/DONNÉES-NOM DU CENTRE DE DONNÉES/vm/VM \
VM.ova

Pour l'authentification prenant en charge Active Directory, vous devez exprimer le caractère "@" dans le
forme de son code hexadécimal ascii (%5c) :

vi://DOMAIN%5cUSER:MOT DE PASSE@...

OAV : IMPORTATION A CLIENT
Pour importer un fichier OVA appelé VM.ova, faire;

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

Si vous avez exporté l'invité en tant que "Dossier de fichiers", or si vous avez déballé l'archive OVA
vous-même, vous pouvez alors pointer virt-v2v vers le répertoire contenant les fichiers :

$ virt-v2v -i ova /chemin/vers/fichiers -o local -os / Var / tmp

CONTRIBUTION De VMWARE ESXi HYPERVISEUR

Virt-v2v ne peut pas accéder directement à un hyperviseur ESXi. Vous devez utiliser la méthode OVA ci-dessus
(voir "INPUT FROM VMWARE OVA") si possible, car il est beaucoup plus rapide et nécessite beaucoup moins
d'espace disque que la méthode décrite dans cette section.

Vous pouvez utiliser le virt-v2v-copie-vers-local(1) outil pour copier l'invité de l'hyperviseur dans un
fichier local, puis convertissez-le.

ESXi : ENLEVER VMWARE OUTILS De FENÊTRES INVITES
Pour les invités Windows, vous devez supprimer les outils VMware avant la conversion. Bien que ce soit
pas strictement nécessaire, et l'invité pourra toujours courir, si vous ne le faites pas, alors
l'invité converti se plaindra à chaque démarrage. Les outils ne peuvent pas être retirés après
conversion car le programme de désinstallation vérifie s'il s'exécute sur VMware et refuse de démarrer
(ce qui est aussi la raison pour laquelle virt-v2v ne peut pas les supprimer).

Cela n'est pas nécessaire pour les invités Linux, car virt-v2v est capable de supprimer les outils VMware.

ESXi : URI
L'URI libvirt pour les hyperviseurs VMware ESXi ressemblera à ceci :

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

Le paramètre "?no_verify=1" désactive la vérification du certificat TLS.

ESXi : TEST LIBVIRT CONNEXION À ESXi HYPERVISEUR
Utilisez l'option Virsh(1) commande pour tester l'URI et lister les invités distants disponibles :

$ virsh -c esx://[email protected]?no_verify=1 liste --all
Saisissez le mot de passe root pour esxi.example.com : ***
Identifiant Nom État
-------------------------------------------------- -
- invité éteint

ESXi : COPY L' CLIENT À L' L'APPROVISIONNEMENT APPRENTISSAGE
Utilisation de l'URI libvirt comme -ic option, copiez l'un des invités sur la machine locale :

$ virt-v2v-copie-vers-local -ic esx://[email protected]?no_verify=1 invité

Cela crée invité.xml, disque-invité1...

ESXi : DO L' VIRT-V2V CONVERSION
Effectuez la conversion de l'invité à l'aide de virt-v2v :

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

ESXi : NETTOYER UP
Retirer le invité.xml et disque-invité* fichiers.

CONTRIBUTION De RHEL 5 XEN

Virt-v2v est capable d'importer des invités Xen à partir d'hôtes RHEL 5 Xen.

Virt-v2v utilise libvirt pour accéder à l'hôte Xen distant, et donc le mode d'entrée
devrait être -i libvirt. Comme c'est la valeur par défaut, vous n'avez pas besoin de le spécifier sur la commande
ligne.

XEN : SET UP AGENT SSH ACCÈS À XEN HÔTE
Actuellement, vous devez activer l'accès SSH sans mot de passe à l'hôte Xen distant à partir de virt-v2v
serveur de conversion.

Vous devez également utiliser ssh-agent et ajouter votre clé publique ssh à /root/.ssh/authorized_keys (sur
l'hôte Xen).

Après cela, vous devez vérifier que l'accès sans mot de passe fonctionne à partir du serveur virt-v2v
à l'hôte Xen. Par exemple:

$ ssh [email protected]
[ se connecte directement au shell, aucun mot de passe n'est demandé ]

Notez que l'accès interactif par mot de passe et Kerberos sont ne sauraient prise en charge. Tu avons installer
accès ssh à l'aide de ssh-agent et de allowed_keys.

XEN : TEST LIBVIRT CONNEXION À REMOTE XEN HÔTE
Utilisez l'option Virsh(1) commande pour lister les invités sur l'hôte Xen distant :

$ virsh -c xen+ssh://[email protected] tout lister
Identifiant Nom État
-------------------------------------------------- -
0 Domaine-0 en cours d'exécution
- rhel49-x86_64-pv éteint

Vous devriez également essayer de vider les métadonnées de n'importe quel invité sur votre serveur, comme ceci :

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

rhel49-x86_64-pv
[...]


If le au dessus de commandes do ne sauraient travailler, puis virt-v2v is ne sauraient aller à travail non plus. Réparez votre
configuration de libvirt ou le serveur distant avant de continuer.

If le invité disques situé on a hôte bloc dispositif, la conversion échouera. Voir
« CONVERSIONS XEN OU SSH À PARTIR DE PÉRIPHÉRIQUES BLOCS » ci-dessous pour une solution de contournement.

XEN : IMPORTATION A CLIENT
Pour importer un invité particulier depuis un serveur Xen, procédez comme suit :

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

où "rhel49-x86_64-pv" est le nom de l'invité (qui doit être arrêté).

Dans ce cas, les indicateurs de sortie sont définis pour écrire l'invité converti dans un fichier temporaire
répertoire car ce n'est qu'un exemple, mais vous pouvez également écrire dans libvirt ou tout autre
cible prise en charge.

XEN OR SSH TRANSFORMATION De BLOC DISPOSITIFS
Actuellement, virt-v2v ne peut pas accéder directement à un invité Xen (ou à tout invité situé à distance sur
ssh) si les disques de cet invité sont situés sur des périphériques de bloc hôte.

Pour savoir si un invité Xen utilise des périphériques de bloc hôte, examinez le XML de l'invité. Tu verras:





où "type='block'", "source dev=" et "/dev/..." sont toutes des indications que le disque est
situé sur un périphérique de bloc hôte.

Cela se produit parce que le pilote de bloc qemu ssh que nous utilisons pour accéder aux disques distants utilise le
protocole ssh sftp, et ce protocole ne peut pas détecter correctement la taille du bloc hôte
dispositifs.

La solution de contournement consiste à copier l'invité sur le serveur de conversion, en utilisant le
virt-v2v-copie-vers-local(1) outil, suivi de l'exécution de virt-v2v. Vous aurez besoin de suffisamment
sur le serveur de conversion pour stocker une copie complète de l'invité.

virt-v2v-copy-to-local -ic xen+ssh://[email protected] invité
virt-v2v -i libvirtxml invité.xml -o local -os / Var / tmp
rm guest.xml disque-invité*

SORTIE À LIBVIRT

VOTRE -o libvirt L'option vous permet de télécharger l'invité converti vers un hôte géré par libvirt.
Il y a plusieurs limites :

· Vous ne pouvez utiliser qu'une connexion libvirt locale [voir ci-dessous pour savoir comment contourner ce problème].

· Le -OS pool L'option doit spécifier un pool de répertoires, rien de plus exotique comme
iSCSI [mais voir ci-dessous].

· Vous ne pouvez télécharger que vers un hyperviseur KVM.

À sortie à a éloigné libvirt instance et/ou a non-répertoire storage pool tu dois utiliser
la solution de contournement suivante :

1. Utilisez virt-v2v dans -o locales mode pour convertir les disques invités et les métadonnées en un
répertoire temporaire :

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

Cela crée deux (ou plus) fichiers dans / Var / tmp appelé:

/var/tmp/NAME.xml # le XML libvirt (métadonnées)
/var/tmp/NAME-sda # le premier disque de l'invité

(pour "NOM", remplacez le nom de l'invité).

2. Téléchargez le(s) disque(s) converti(s) dans le pool de stockage appelé « POOL » :

taille=$(stat -c%s /var/tmp/NOM-sda)
virsh vol-create-as POOL NAME-sda $size --format brut
virsh vol-upload --pool NOM DU POOL-sda /var/tmp/NOM-sda

3. modifier /var/tmp/NOM.xml pour changer /var/tmp/NOM-sda au nom de la piscine. En d'autres termes,
localisez le bit suivant de XML :







et changer deux choses : L'attribut "type='file'" doit être changé en "type='volume'",
et le " " doit être modifié pour inclure les attributs " pool " et " volume " :







4. Définissez l'invité final dans libvirt :

virsh définir /var/tmp/NOM.xml

SORTIE À rhév

Cette section s'applique uniquement aux -o rhév mode de sortie. Si vous utilisez virt-v2v du RHEV-M
interface utilisateur, puis en coulisses, l'import est géré par VDSM à l'aide du -o vdsm
mode de sortie (que les utilisateurs finaux ne devraient pas essayer d'utiliser directement).

Vous devez préciser -o rhév et le -OS option qui pointe vers le stockage d'exportation RHEV-M
Domaine. Vous pouvez soit spécifier le serveur NFS et le point de montage, par ex.
"-os rhev-storage:/rhev/export", ou vous pouvez le monter en premier et pointer vers le répertoire
où il est monté, par ex. "-os /tmp/mnt". Attention à ne pas pointer vers le stockage de données
Domaine par accident car cela ne fonctionnera pas.

En cas de réussite, virt-v2v aura écrit le nouvel invité sur le stockage d'exportation
Domain, mais il ne sera pas encore prêt à fonctionner. Il doit être importé dans RHEV à l'aide de l'interface utilisateur
avant de pouvoir être utilisé.

Dans RHEV ≥ 2.2, cela se fait à partir de l'onglet Stockage. Sélectionnez le domaine d'exportation de l'invité
écrit à. Un volet apparaîtra sous la liste des domaines de stockage affichant plusieurs
onglets, dont l'un est "VM Import". L'invité converti sera répertorié ici. Sélectionnez le
invité approprié et cliquez sur "Importer". Voir la documentation RHEV pour plus de détails.

Si vous exportez plusieurs invités, vous pouvez les importer tous en même temps via le
UI.

RESSOURCE EXIGENCES

Réseau
La ressource la plus importante pour virt-v2v semble être la bande passante du réseau. Virt-v2v devrait
être en mesure de copier les données des invités à des vitesses Ethernet gigabit ou supérieures.

Assurez-vous que les connexions réseau entre les serveurs (serveur de conversion, serveur NFS,
vCenter, Xen) sont aussi rapides et avec une latence aussi faible que possible.

Disque espace
Virt-v2v place des fichiers temporaires potentiellement volumineux dans $TMPDIR (qui est / Var / tmp si tu
ne le réglez pas). Utiliser tmpfs est une mauvaise idée.

Pour chaque disque invité, une superposition est stockée temporairement. Cela stocke les modifications apportées
lors de la conversion, et est utilisé comme cache. Les superpositions ne sont pas particulièrement grandes - des dizaines
ou des centaines de mégaoctets par disque sont typiques. En plus de la ou des superpositions, saisissez
et les méthodes de sortie peuvent utiliser de l'espace disque, comme indiqué dans le tableau ci-dessous.

-i ovules
Cela place temporairement une copie complète des disques sources non compressés dans $TMPDIR.

-o coup d'oeil
Cela place temporairement une copie complète des disques de sortie dans $TMPDIR.

-o locales
-o qemu
Vous devez vous assurer qu'il y a suffisamment d'espace dans le répertoire de sortie pour le converti
client.

-o nul
Cela place temporairement une copie complète des disques de sortie dans $TMPDIR.

VMware vCenter numériques
La copie à partir de VMware vCenter est actuellement assez lente, mais nous pensons qu'il s'agit d'un problème
avec VMware. S'assurer que l'hyperviseur VMware ESXi et vCenter s'exécutent sur du matériel rapide
avec beaucoup de mémoire devrait atténuer cela.

calcul power et RAM
Virt-v2v n'est pas particulièrement gourmand en calcul ou en RAM. Si vous utilisez plusieurs parallèles
conversions, vous pouvez envisager d'allouer un cœur de processeur et entre 512 Mo et 1 Go de
RAM par instance en cours d'exécution.

Virt-v2v peut être exécuté dans une machine virtuelle.

POST-CONVERSION TÂCHES

INVITÉ réseau paramétrage
Virt-v2v ne peut actuellement pas reconfigurer la configuration réseau d'un invité. Si le converti
l'invité n'est pas connecté au même sous-réseau que la source, sa configuration réseau peut
doivent être mis à jour. Voir également virt-personnaliser (1).

Façonnage a Windows invité
Lors de la conversion d'invités Windows, le processus de conversion est divisé en deux étapes :

1. Conversion hors ligne.

2. Premier démarrage.

L'invité sera amorçable après l'étape de conversion hors ligne, mais n'aura pas encore tout
pilotes nécessaires installés pour fonctionner correctement. Ceux-ci seront installés automatiquement le
première fois que l'invité démarre.

NB Veillez à ne pas interrompre le processus d'installation automatique du pilote lors de la connexion
à l'invité pour la première fois, car cela peut empêcher l'invité de démarrer par la suite
correctement.

un devis GRATUIT SPACE POUR CONVERSION

Virt-v2v vérifie qu'il y a suffisamment d'espace libre dans le système de fichiers invité pour effectuer le
conversion. Actuellement, il vérifie :

Système de fichiers racine Linux ou lecteur Windows "C:"
Espace libre minimum : 20 Mo

Linux/Unix / boot
Espace libre minimum : 50 Mo

C'est parce que nous devons créer un nouvel initramfs pour certains Linux d'entreprise
conversions.

Tout autre système de fichiers montable
Espace libre minimum : 10 Mo

RUNNING VIRT-V2V AS TRAITEMENT OR NON RACINE

Rien dans virt-v2v n'a intrinsèquement besoin d'un accès root, et il fonctionnera très bien en tant que non-root
utilisateur. Cependant, certaines fonctionnalités externes peuvent nécessiter soit un utilisateur root, soit un utilisateur spécial :

Montage du domaine de stockage d'exportation
Lors de l'utilisation -o rhév -OS serveur :/esd virt-v2v doit avoir des privilèges suffisants pour NFS
montez le domaine de stockage d'exportation à partir du "serveur".

Vous pouvez éviter d'avoir besoin de root ici en le montant vous-même avant d'exécuter virt-v2v, et
en passant -OS /point de montage à la place, mais lisez d'abord la section suivante ...

Écriture dans le domaine de stockage d'exportation en tant que 36:36
RHEV-M ne peut pas lire les fichiers et les répertoires du domaine de stockage d'exportation à moins qu'ils
avoir UID:GID 36:36. Vous verrez des problèmes d'importation de VM si l'UID:GID n'est pas correct.

Lorsque vous exécutez virt-v2v -o rhév en tant que root, virt-v2v tente de créer des fichiers et
répertoires avec la propriété correcte. Si vous exécutez virt-v2v en tant que non-root, il
fonctionnera probablement toujours, mais vous devrez changer manuellement de propriétaire une fois que virt-v2v aura
fini.

Écrire sur libvirt
Lors de l'utilisation -o libvirt, vous devrez peut-être exécuter virt-v2v en tant que root pour qu'il puisse écrire sur
l'instance du système libvirt (c'est-à-dire "qemu:///system") et à l'emplacement par défaut pour
images disque (généralement / var / lib / libvirt / images).

Vous pouvez éviter cela en configurant l'authentification de connexion libvirt, voir
http://libvirt.org/auth.html. Sinon, utilisez -oc qemu:///session, Qui va
écrivez dans votre instance libvirt par utilisateur.

Écrire pour jeter un coup d'œil
Cela ne ne sauraient besoin de root (en fait, cela ne fonctionnera probablement pas), mais peut nécessiter soit un
utilisateur spécial et/ou pour que vous trouviez un script qui définit l'environnement d'authentification
variables. Consultez la documentation Glance.

DÉBOGAGE RHEV-M IMPORTER LES ÉCHECS

Lorsque vous exportez vers le domaine de stockage d'exportation RHEV-M, puis importez cet invité via
l'interface utilisateur RHEV-M, vous pouvez rencontrer un échec d'importation. Diagnostiquer ces défaillances est
extrêmement difficile car l'interface utilisateur cache généralement la véritable raison de l'échec.

Il existe deux fichiers journaux intéressants. Le premier est stocké sur le serveur RHEV-M lui-même, et
est appelé /var/log/ovirt-engine/engine.log

Le deuxième fichier, le plus utile, se trouve sur l'hôte SPM (SPM signifie
"Gestionnaire de pool de stockage"). Il s'agit d'un nœud RHEV qui est choisi pour effectuer toutes les métadonnées
modifications dans le centre de données, telles que la création d'images ou d'instantanés. Vous pouvez découvrir
quel hôte est le SPM actuel dans la colonne « État du SPM » de l'onglet « Hôtes ». Une fois que tu as
localisé le SPM, connectez-vous et récupérez le fichier /var/log/vdsm/vdsm.log qui contiendra
messages d'erreur détaillés des commandes de bas niveau.

MINIMAL XML POUR -i libvirtxml OPTION

Lorsque vous utilisez le -i libvirtxml option, vous devez fournir du XML libvirt. Écrire ceci
partir de zéro est difficile, le modèle ci-dessous est donc utile.

Notes cet devrait uniquement be d'utiliser pour vers les tests et/ou où you savoir est ce que nous faisons Vous êtes Faire! Si vous
avoir des métadonnées libvirt pour l'invité, utilisez-les toujours à la place.


NOM
1048576
2

hvm














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

APPRENTISSAGE LISIBLE SORTIE

VOTRE --lisible par machine L'option peut être utilisée pour rendre la sortie plus conviviale pour la machine, ce qui
est utile lors de l'appel de virt-v2v à partir d'autres programmes, interfaces graphiques, etc.

Il y a deux façons d'utiliser cette option.

Utilisez d'abord l'option seule pour interroger les capacités du binaire virt-v2v.
La sortie typique ressemble à ceci :

$ virt-v2v --lisible par machine
virt-v2v
libguestfs-réécrire
entrée:disque
[...]
sortie:locale
[...]
convertir:entreprise-linux
convertir:fenêtres

Une liste de fonctionnalités est imprimée, une par ligne, et le programme se termine avec l'état 0.

Les fonctionnalités « input : » et « output : » se réfèrent à -i et -o (mode d'entrée et de sortie) options
pris en charge par ce binaire. Les fonctionnalités « convertir : » font référence aux types d'invités que ce binaire
sait se convertir.

Deuxièmement, utilisez l'option en conjonction avec d'autres options pour rendre le programme régulier
sortie plus conviviale pour la machine.

Pour le moment cela signifie :

1. Les messages de la barre de progression peuvent être analysés à partir de stdout en recherchant ce
expression:

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

2. Le programme appelant doit traiter les messages envoyés à stdout (sauf pour la barre de progression
messages) en tant que messages d'état. Ils peuvent être enregistrés et/ou affichés pour l'utilisateur.

3. Le programme appelant doit traiter les messages envoyés à stderr comme des messages d'erreur. Dans
De plus, virt-v2v se termine avec un code d'état différent de zéro s'il y a eu une erreur fatale.

Virt-v2v ≤ 0.9.1 ne prenait pas en charge le --lisible par machine option du tout. L'option était
ajouté lorsque virt-v2v a été réécrit en 2014.

Utilisez virt-v2v en ligne en utilisant les services onworks.net