Il processo di migrazione delle VM da hypervisor XEN a oVirt (KVM) è possibile attraverso l'uso del tool fornito da RedHat/CentOS virt-v2v.

# yum install virt-v2v

Per non incorrere in un bug di RedHat nel "relabing" di SELINUX per alcuni guest con sistemi operativi obsoleti è stato necessario utilizzare un repository redhat in alfa della 7.4 per uitlizzare i nuovi tool di conversione v2v:

[base74]
name=CentOS-74 - Base
baseurl=https://people.redhat.com/~rjones/libguestfs-RHEL-7.4-preview/
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1

Questo repository mi ha permesso di installare gli ultimi pacchetti di virtualizzazione non affetti da bug come da nota redhat.

Di seguito i pacchetti che non presentano il bug inerente al porting di guest con SO precedente alla CentOS 6.2:

virt-v2v-1.36.2-1.el7.x86_64
libguestfs-1.36.2-1.el7.x86_64
libvirt-3.1.0-2.el7.x86_64
qemu-kvm-rhev-2.8.0-6.el7.x86_64

Di seguito l'errore in caso di porting con versione con il bug:

virt-v2v: error: libguestfs error: selinux_relabel: 
/sysroot/etc/selinux/targeted/contexts/files/file_contexts: Invalid argument

Nel caso della nostra infrastruttura, il porting da XEN ad oVirt è possibile attraverso due comandi:

  1. Copia delle volume del guest in forma d'immagine RAW
  2. Conversione immagine RAW e import in KVM
virt-v2v-copy-to-local -ic xen+ssh://<hostname DOM XEN> <hostname guest>

Il comando è necessario in caso di VM su logical volume o su dischi fisici in quanto il comando di import diretto (vedi dopo) è in grado di importare solo VM con disco di boot su file. E' fondamentale che il file di descrizione della VM sia nella directory /etc/xen/.

Il comando produce un file xml con le caratteristiche della VM e il disco del guest in formato file <hostname guest>-diskX.

E' necessario un piccolo workaround per fare riconoscere al tool di conversione v2v che il disco del guest è raw-data, quindi aprire il file xml e sostituire la stringa:

<driver name="phy"/>

con 

<driver name='tap' type='aio'/>

A questo punto si è pronti alla conversione del raw-disk e dell'import dell'immagine XEN in KVM. Ricordarsi di abiltare la direttiva:

export LIBGUESTFS_BACKEND=direct

A questo punto si lancia il seguente comando puntanto come output uno export-domain di oVirt

virt-v2v -x -v -i libvirtxml <hostname guest>.xml -o rhev -os <export-domain oVirt>

esempio:

virt-v2v -x -v -i libvirtxml vldantedev101.xml -o rhev -os /nfsmount/nasetto_ov01/divacc_export/

A termine del processo la macchina sarà presente nel export-domain di oVirt è sarà pronta per l'import nel datacenter prescelto.

La procedura non ha mostrato criticità per tutte le VM linux mentre sono stati necessari numerosi workaround per importare macchine windows con driver paravitualizzati GPL-PV.

Di seguito la ricetta come ritrovata fortunatamente su internet:

Based on customer feedback, we have come across an error that can occur when restoring your VM onto the new
platform. After completing steps 11-k in the ‘Migrate_Server2k8r2’ guide you are told to restore the server and you
should get to the login. Sometimes you will be presented with another BSOD instead stating ‘”xenpci.sys, the driver
unloaded without cancelling pending operations’. If you experience this, you will need to remove the xen drivers
manually.

1. Select ‘Launch Startup Repair (recommended)’.
   a. Select the radio button ‘use recovery tools….’, and install the Virtio Storage drivers and make a note
      of the drive letter assigned to the OS drive. In this case, I’ll refer to it as the ‘F:\’ drive but yours
      might be different.
   b. Wait for the ‘Startup Repair’ process to fail, or cancel it and click ‘Finish’.
   c. From the ‘Choose a recovery tool’ window select ‘Command Prompt’.
   d. Now type the following:
      i. ‘rmdir /q /s “f:\Program Files (x86)\Xen PV Drivers”’
      ii. ‘del /q “f:\Windows\System32\drivers\xen*”’
      iii. ‘del /q f:\Windows\inf\oem1.inf’
      iv. ‘del /q f:\Windows\inf\oem2.inf’
      v. ‘del /q f:\Windows\inf\oem3.inf’
      vi. ‘del /q f:\Windows\inf\oem4.inf’
      vii. ‘del /q f:\Windows\inf\oem5.inf’
      viii. ‘del /q f:\Windows\inf\oem*.pnf’
   e. Now type ‘regedit’, then hit enter.
   f. Select ‘HKLM’, go to ‘File\Load Hive’
   g. For this step, make sure you select the drive you are recovering and not the X: (boot) drive. Go to
      ‘C:\Windows\system32\config’ and open the ‘SYSTEM’ file.
   h. Type any ‘Key Name’ you want, example ‘temp’.
   i. Navigate to ‘HKLM\temp\ControlSet001\services’.
      i. Delete Key Names ‘xennet’, ‘xenpci’, ‘xenvdb’.
   j. Navigate to ‘HKLM\temp\ControlSet002\services’.
      i. Delete Key Names ‘xennet’, ‘xenpci’, ‘xenvdb’.
   k. Navigate back to ‘HKLM\temp’.
      i. Press ‘Ctrl + f’ to find.
      ii. Search for ‘upperfilters’ and keep pressing F3 to find any key with reference to ‘xenpci’ that
          have the same class value as below and delete them.
          1. ‘HKLM\***\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}’
          2. ‘HKLM\***\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}’
          3. ‘HKLM\***\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}’
   l. Check these values are still true:
      i. intelide ‘3’
      ii. msahci ‘0’
      iii. pciide ‘0’
      iv. LSI_SAS ‘3’
   m. Navigate back to the ‘temp’ registry key and select ‘File\Unload Hive’, then press ‘Yes’.
   n. Restart the server.
2. When your server has started, Login.
  • No labels