OmniCube: Migration à partir de VMware

EFit-partners

Mars 2026

Chapter 1
Conversion de VMs VMware vers des zones OmniOS

1.1 Introduction

La migration prend place sur le node hébergeant le zpool migration, soit dia-hc-01 pour le moment. Elle est gérée en grande partie par le script /migration/vmware2omnicube.sh qui doit être exécuté avec les permissions root.

~# /migration/vmware2omnicube.sh -h

Tranfer VMs from VMWARE to /migration/vm_share and/or convert them for OmniCube.

The VM information is retrieved from /migration/vm_info.txt which contains the absolute path of each VM folder
Example
/vmfs/volumes/60784f15-386a5f9e-8fc3-f0921c0c9578/w10jadoma

    /migration/vmware2omnicube.sh -p [NUM_OF_PARALLEL_PROC] -t  # Copy VM VMDKs from vmware
    /migration/vmware2omnicube.sh -p [NUM_OF_PARALLEL_PROC] -c  # Convert VM VMDKs to Omnicube

Comme mentionné dans l'aide du script, l'information de conversion provient du fichier /migration/vm_info.txt dont la structure est la suivante:

| Path de la VM sur le serveur ESX                             | OS   | Port VNC | STATUT |
| ------------------------------------------------------------ | ---- | -------- | ------ |
| /vmfs/volumes/66274c7a-e15629b5-2cc1-5c6f69f89c80/chhpfp     | 2k19 | 6107     | WAIT   |
| /vmfs/volumes/60866e8b-72926fdd-61bb-f0921c0c89a0/chhpftpext | 2k12 | 6119     | -      |
| /vmfs/volumes/6078500b-f17379c4-44dc-f0921c0c9578/chhpflowr  | lnx  | 6108     | DONE   |
| /vmfs/volumes/6079579f-51bd66bb-764e-f0921c0c9578/chhproche  | 2k22 | 6133     | DONE   |
| /vmfs/volumes/67ee48ec-c4e84d09-a408-5c6f69f856f0/chhpxeleris | 2k22 | 6134     | DONE   |

OS:: Le type et la version d'OS provient des informations fournies par les VMware tools.
En cours de conversion, il s'est avéré que cette information ne s'est pas révélée très pertinente, raison pour laquelle, cette information est maintenant retirée pendant le processus de conversion. L'OS ne sert donc plus dans les faits que pour savoir si on migre un Unix (lnx) ou une version quelconque de Windows.
Port VNC:: Le port VNC est défini de manière séquentielle basée sur les ports libres. Un moyen facile, quoique pas entièrement rigoureux, permet de détecter sur chaque node le port libre. Il suffira de prendre le plus élevé.

~$ echo $(($(ps -eaf | perl -nle 'print $1 if /socat\s+TCP-LISTEN:(\d+)/' | sort -r | head -1)+1))
6135

WAIT:: Permet de préparer le fichier sans que l'entrée ne soit traitée par vmware2omnicube.sh
DONE:: La conversion des disques de la VM VMware vers Omnicube est complète
-:: Doit être traitée par le script vmware2omnicube.sh

1.2 Copie des VMDK

VMware limite la bande passante des connexions SSH rendant le passage par ce protocole plutôt inefficace. Il est donc préférable de passer par un partage NFS défini côté Omnicube et monté sur les nodes ESXi. C'est ce qui a été défini sur /migration/vm_share (zpool migration/vm_share).

~$ zfs get mountpoint,primarycache,sharenfs migration/vm_share
NAME                PROPERTY      VALUE                SOURCE
migration/vm_share  mountpoint    /migration/vm_share  default
migration/vm_share  primarycache  none                 local
migration/vm_share  sharenfs      sec=sys,rw           local

vm_share étant utilisé comme un transit, il est important de mettre la propriété primarycache à none pour éviter de polluer l'arc size zfs.

En tête du script vmware2omnicube.sh se trouvent les paramètres qu'il faudra peut-être changer en fonction des besoins

ROOT_DIR:: Répertoire contenant les VMs VMware à migrer (Valeur par défaut: /migration/vm_share)
ROOT_NFS_DIR:: NFS mountpoint du répertoire précédent sur les serveurs ESXi (Valeur par défaut: /vmfs/volumes/NFSDIAHC01)
LOG_FILE:: Log file des copies et conversions (Valeur par défaut: /var/log/migration.log)
TRANSFER_SUFFIX_START:: Nom du répertoire de lock dans le répertoire de la VM VMware quand une copie est lancée (Valeur par défaut: TRANSFER_START)
TRANSFER_SUFFIX_END:: Nom du répertoire de lock dans le répertoire de la VM VMware quand une copie est terminée (Valeur par défaut: TRANSFER_END)
CONVERT_SUFFIX_START:: Nom du répertoire de lock dans le répertoire de la VM VMware quand une conversion est lancée. Il est important de noter que le répertore de la VM VMware dans /migration/vm_share est effacé après la conversion des VMDKs. (Valeur par défaut: CONVERT_START)
VM_INFO_FILE:: Information des VMs à migrer (Cf. Ci-dessus) (Valeur par défaut: /migration/vm_info.txt)
VM_INITIAL_SNAPSHOT:: Nom du snapshot initial créé juste après la conversion des VMDKs (Valeur par défaut: INIT)
ESX_SERVER:: Serveur ESXi sur lequel une connexion SSH sera initialisée pour lancer le processus de copie. Le user utilisé est efit. (Valeur par défaut: mt-esxi-07.chrh.local)

Pour définir préalablement sur ESXi le path absolu de la VM à migrer, le plus facile est de suivre la procédure suivante avec le user root:

~# export SSHPASS=$(cat /root/.sshpass)
~# /opt/omnicube/bin/sshpass -e ssh efitadm@mt-esxi-07.chrh.local
esxi:~#: for vm in [VMWARE_VM_NAME]
do
  VM=${vm}
  for dir in $(ls -lrth /vmfs/volumes/ | awk '/^d/ {print $9}')
  do
    ls -l /vmfs/volumes/${dir} | grep -i ${VM}'$' > /dev/null
    [ $? -eq 0 ] && vm_dir=$(find /vmfs/volumes/${dir} -type d -a -name "*${VM}*") && du -sh ${vm_dir} && break
  done
done

Pour lancer la copie, ouvrez un screen sous root et éxécutez la commande de copie:

~# screen -d -R
~# /migration/vmware2omnicube.sh -t -p 4

En dehors du screen, le statut de la copie peut être monitoré dans /var/log/migration.log

Si la connexion SSH devait être non fonctionnelle, il faut alors cloner la VM à partir de ESX sur le share NFS ROOT_NFS_DIR défini ci-dessus. Il est important de noter que la phase de conversion des VMDKs s'attend à un nom de VM identique à celui défini sur Omnicube. Si le nom diffère, comme contenant "_clone", ou autre, il faudra alors faire la conversion manuellement.

Déroulé logique de la copie:

Connexion SSH au serveur ESXi
Création du répertoire de la VM VMware sur /migration/vm_share et création dans ce répertoire du lock TRANSFER_SUFFIX_START
Utilisation de l'outil vmkfstools pour cloner la VM VMware sur le share NFS ROOT_NFS_DIR
Création dans ce répertoire du lock TRANSFER_SUFFIX_END

1.3 Conversion

1.3.1 Windows

Le zpool de la zone Omnicube doit être monté sur le serveur qui héberge la migration et la zone doit avoir le statut installed. Le répertoire root/raw doit aussi exister dans la path de la zone. Au besoin, il faudra fixer le recordsize avant la conversion.

~$ pfexec zfs set recordsize=4k zonevm01/zones/zonevm01

Si le processus de copie de l'étape deux s'est terminé correctement, il suffit de d'ouvrir un screen et de lancer la conversion.

~# screen -d -R
~# /migration/vmware2omnicube.sh -t -p 4

Pour rappel, le répertoire de la VM est effacé de /migration/vm_share après la conversion.

S'il faut passer en mode manuel, le processus est le suivant:

Éviter l'utilisation de l'arc size:

~# zfs set primarycache=none zonevm01/zones/zonevm01
~# cd /migration/vm_share/zonevm01_clone/

En fonction du nombre de disques à migrer (exemple de quatre disques)

~# count=0
~# for id in "" _1 _2 _3
do
  echo ${count}
  time /opt/ooce/bin/qemu-img convert -f vmdk -O raw zonevm01_clone${id}.vmdk /zones/zonevm01/root/root/raw/disk${count}.raw
  count=$((count+1))
done
~# rsync --progress /migration/WinPE_efit.iso /zones/zonevm01/root/root/raw/disk.iso

Dans le cas d'un Windows 2012

~# rsync --progress --sparse /iso/virtio/virtio-win-0.1.215.iso /zones/zonevm01/root/root/raw/virtio-win-0.1.215.iso

Restaurer la propriété primarycache

~# zfs set primarycache=metadata zonevm01/zones/zonevm01
~# zfs snasphot -r zonevm01/zones/zonevm01@INIT
~# zoneadm -z zonevm01 boot

Une fois la zone démarrée, il faut s'y connecter pour convertir le bootdisk en UEFI et y ajouter des drivers virtio. Par convention le premier disque (disk0.raw) est le disque de boot. Si sur VMware, un autre disque constitue le disque de boot, il faudra mettre à jour la configuration de la zone sur Omnicube.

~# zlogin -e '#' -C zonevm01

Dans la console SAC, ouvrir un prompt qui donne accès à la console WinPE dans laquelle il faut lancer un powershell:

SAC> cmd
SAC> ch -sn Cmd0001
PS> powershell

Lancer diskpart pour confirmer que le disque doit bien être converti en UEFI. Si une partition FAT32 est visible et qu'il y a une partition nommée System, le disque est déjà converti en UEFI

PS> diskpart
 list disk
 select disk 0
 list part
 exit

Lancer la conversion. En cas d'échec, reportez-vous à la section Issues

PS> mbr2gpt /validate /disk:0
PS> mbr2gpt /convert /disk:0 /allowFullOS

Vérifier que la conversion s'est bien déroulée et lister les volumes accessibles.

PS> diskpart
 list disk
 select disk 0
 list part
 list vol
 exit

Si la partition contenant Windows n'a pas de lettre, il faut l'assigner avec diskpart

PS> diskpart
 list disk
 select disk 0
 list part
 select part 2
 assign letter=D
 exit

Si Windows se trouve sur le volume D, c'est ici qu'on trouve quelle version de Windows est installée

PS> $sys_letter = 'D'
PS> reg load HKLM\OFFLINE_SOFT "${sys_letter}:\Windows\System32\config\SOFTWARE"
PS> reg query "HKLM\OFFLINE_SOFT\Microsoft\Windows NT\CurrentVersion" /v ProductName
PS> reg unload HKLM\OFFLINE_SOFT

Une fois la version identifiée, il faut spécifier win_vers à partir des codes suivants:

2k12:: Windows Server 2012
2k12R2:: Windows Server 2012 Release 2
2k16:: Windows Server 2016
2k19:: Windows Server 2019
2k22:: Windows Server 2022
2k25:: Windows Server 2025
2k3:: Windows Server 2003
2k8:: Windows Server 2008
2k8R2:: Windows Server 2008 Release 2
w10:: Windows 10
w11:: Windows 11
w7:: Windows 7
w8:: Windows 8
w8.1:: Windows 8.1
xp:: Windows XP

PS> $win_vers = 'XXX'

Pour toute version de Windows Server supérieure à 2012r2, utilisez la procédure suivante pour l'injection des drivers virtio:

PS> $drv_letter = 'X'
PS> dism /image:${sys_letter}:\ /add-driver:${drv_letter}:\Drivers\viostor\${win_vers}\amd64\viostor.inf
PS> dism /image:${sys_letter}:\ /add-driver:${drv_letter}:\Drivers\vioscsi\${win_vers}\amd64\vioscsi.inf
PS> dism /image:${sys_letter}:\ /add-driver:${drv_letter}:\Drivers\NetKVM\${win_vers}\amd64\netkvm.inf

Pour Windows 2012 ou 2012R2, utilisez la procédure suivante pour l'injection des drivers virtio:

PS> $drv_letter = 'G' # Lettre du volume contenant les virtio-win-0.1.215
PS> dism /image:${sys_letter}:\ /add-driver:${drv_letter}:\viostor\${win_vers}\amd64\viostor.inf
PS> dism /image:${sys_letter}:\ /add-driver:${drv_letter}:\vioscsi\${win_vers}\amd64\vioscsi.inf
PS> dism /image:${sys_letter}:\ /add-driver:${drv_letter}:\NetKVM\${win_vers}\amd64\netkvm.inf

Activation de la Special Administration Console (SAC) de Windows:

PS> bcdedit /enum OSLOADER

Configuration du SAC

PS> bcdedit /ems '{default}' on
PS> bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200

Shutdown de la VM sous WinPE

PS> wpeutil shutdown

Quitter la console de la zone OmniOS et retirer le CDROM de la configuration de la zone:

~# zonecfg -z zonevm01 remove attr name=cdrom1 # Uniquement pout Windows 2012(R2)
~# zonecfg -z zonevm01 remove attr name=cdrom0
~# zonecfg -z zonevm01 remove attr name=bootorder

Redémarrer la zone ou la migrer vers une autre node (Cf migration de zone dans manuel d'opérations)

En cas d'échec de la conversion UEFI

PS X:\Windows\System32> mbr2gpt /validate /disk:0
MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
Cannot find OS partition(s) for disk 0

La solution consiste à appliquer la procédure suivante:

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     E   DVD_ROM      UDF    CD-ROM       616 MB  Healthy
  Volume 1     C   System Rese  NTFS   Partition    100 MB  Healthy
  Volume 2     D                NTFS   Partition    149 GB  Healthy

DISKPART> exit

Leaving DiskPart...
PS X:\Windows\System32> .\chkdsk.exe D: /f /x
PS D:\Windows\System32> .\Defrag.exe D: /u /v
PS X:\Windows\System32> diskpart
DISKPART> select disk 0
DISKPART> list part

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary            100 MB  1024 KB
  Partition 2    Primary            149 GB   101 MB
DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     E   DVD_ROM      UDF    CD-ROM       616 MB  Healthy
  Volume 1     C   System Rese  NTFS   Partition    100 MB  Healthy
  Volume 2     D                NTFS   Partition    149 GB  Healthy

DISKPART> select vol 2

Volume 2 is the selected volume.

DISKPART> list part

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary            100 MB  1024 KB
* Partition 2    Primary            149 GB   101 MB
DISKPART> shrink desired=1024

DiskPart successfully shrunk the volume by: 1024 MB

DISKPART> list part

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary            100 MB  1024 KB
* Partition 2    Primary            148 GB   101 MB

DISKPART> create partition primary

DiskPart succeeded in creating the specified partition.

DISKPART> sel par 3

Partition 3 is now the selected partition.

DISKPART> active

DiskPart marked the current partition as active.

DISKPART> format fs=ntfs quick

DISKPART> assign letter=F

DISKPART> exit

PS X:\Windows\System32> .\bcdboot.exe D:\Windows /f all /s F:\
Boot files successfully created.

PS X:\Windows\System32> mbr2gpt /validate /disk:0
MBR2GPT: Attempting to validate disk 0
MBR2GPT: Retrieving layout of disk
MBR2GPT: Validating layout, disk sector size is: 512 bytes
MBR2GPT: Validation completed successfully

1.3.2 Linux

Si le processus de copie de l'étape 2 s'est terminé correctement, il suffit de d'ouvrir un screen et de lancer la conversion.

~# screen -d -R
~# /migration/vmware2omnicube.sh -t -p 4

Pour rappel, le répertoire de la VM est effacé de /migration/vm_share après la conversion

S'il faut passer en mode manuel, voilà le processus à suivre:

Éviter l'utilisation de l'arc size:

~# zfs set primarycache=none zonevm01/zones/zonevm01
~# cd /migration/vm_share/zonevm01_clone/

En fonction du nombre de disques à migrer, quatre dans l'exemple ci-dessous:

~# count=0
~# for id in "" _1 _2 _3
do
  echo ${count}
  time /opt/ooce/bin/qemu-img convert -f vmdk -O raw zonevm01_clone${id}.vmdk /zones/linux-mig/root/raw/zonevm01-disk${count}.raw
  count=$((count+1))
done

La migration des zones Linux se déroule grâce à la VM helper linux-mig dont le bootdisk contient tous les outils nécessaires à la migration. Elle utilise une carte réseau physique lui permettant d'avoir accès à Internet, car pour chaque VM convertie, il faudra la plupart du temps télécharger les versions de grub supportant l'UEFI.

Voici un descriptif du helper en question

~$ zoneadm -z linux-mig list -v
ID NAME             STATUS     PATH                           BRAND    IP
 - linux-mig        installed  /zones/linux-mig               bhyve    excl
~$ zonecfg -z linux-mig export 
create -b
set zonepath=/zones/linux-mig
set brand=bhyve
set autoboot=false
set ip-type=exclusive
add net
set physical="efitmig0"
set mac-addr="2:8:20:21:8c:ce"
set global-nic="bge0"
end
add device
set match="/raw/disk0.raw"
end
add attr
set name="bootrom"
set type="string"
set value="BHYVE_RELEASE"
end
add attr
set name="priority"
set type="string"
set value="4"
end
add attr
set name="vnc"
set type="string"
set value="on"
end
add attr
set name="bootdisk"
set type="string"
set value="/raw/disk0.raw"
end
add attr
set name="vcpus"
set type="string"
set value="4"
end
add attr
set name="diskif"
set type="string"
set value="virtio-blk"
end
add attr
set name="ram"
set type="string"
set value="4G"
end
add attr
set name="disk0"
set type="string"
set value="/raw/disk4.raw"
end
add attr
set name="disk1"
set type="string"
set value="/raw/disk5.raw"
end
add attr
set name="disk2"
set type="string"
set value="/raw/disk6.raw"
end

1.3.3 Dérivés de Debian Linux

En grande majorité, les VM Debian Linux ne sont constituées que d'un seul disque et utilisent LVM. La procédure de conversion suit le process suivant:

$# cd /zones/linux-mig/root/raw 
## Déplacer le disque de démarrage de la VM Debian Linux comme disk4.raw
$# mv -i zonevm01-disk0.raw disk4.raw
## Identifier la taille du disque et créer 1 disk5.raw légèrement plus grand
$# ls -lrth disk4.raw
-rw-r--r--   1 root     root        100G Feb 24 19:21 disk4.raw
$# truncate -s 105G disk5.raw
$# ls -lrth disk5.raw
-rw-r--r--   1 root     root        105G Feb 24 19:53 disk5.raw

Le disque disk6.raw est gardé comme disque de réserve pouvant notamment servir comme deuxième disque utilisé par le Volume Group de la VM Debian.

Une fois les disques préparés, on démarre la VM linux-mig et on s'y connecte en console ou en SSH. En console, il n'est pas besoin de spécifier de mot de passePour la connexion SSH, le plus facile est de mettre sa clé SSH publique dans .ssh/authorized_keys du user root.

~# zoneadm -z linux-mig boot && zlogin -e '#' -C linux-mig
...
Debian GNU/Linux 12 rescue ttyS0

rescue login: root
Linux rescue 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Mar  3 00:06:14 CET 2026 from 10.95.11.179 on pts/0
root@rescue:~#

Dans la VM linux-mig (rescue):

disk4.raw est vu comme /dev/vdb
disk5.raw est vu comme /dev/vdc
disk6.raw est vu comme /dev/vdd

Le principe de conversion vise à créer une partition UEFI sur /dev/vdc et de faire des clones de toutes les partitions utiles de /dev/vdb sur /dev/vdc. En cas d'utilisation de LVM, un cycle de reboot sera nécessaire mais pour éviter ce cycle on peut tout aussi bien étendre le VG grâce à une partition sur /dev/vdc et utiliser pvmove pour migrer toutes les données des anciens volumes physiques vers le nouveau. Il suffira alors de faire un vgreduce pour supprimer l'utilisation des anciens. C'est même obligatoire si le VG original est constitué de deux disques. Cloner les partitions et faire un cycle de reboot reste la plupart du temps plus rapide, c'est ce processus qui est décrit ci-dessous:

root@rescue:~# pvdisplay
  --- Physical volume ---
  PV Name               /dev/vdb3
  VG Name               ubuntu-vg
  PV Size               <99.00 GiB / not usable 0
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              25343
  Free PE               0
  Allocated PE          25343
  PV UUID               YHNE8L-k0AR-wspB-zoaL-Bq64-McFp-UEffR

root@rescue:~# fdisk -l /dev/vdb
Disk /dev/vdb: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 131072 bytes
I/O size (minimum/optimal): 131072 bytes / 131072 bytes
Disklabel type: gpt
Disk identifier: 078D4EF0-67D9-429E-BFAC-A28C9C53E2D1

Device       Start       End   Sectors Size Type
/dev/vdb1     2048      4095      2048   1M BIOS boot
/dev/vdb2     4096   2101247   2097152   1G Linux filesystem
/dev/vdb3  2101248 209713151 207611904  99G Linux filesystem

root@rescue:~# gdisk /dev/vdc
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.

Command (? for help): n
Partition number (1-128, default 1):
First sector (34-220200926, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-220200926, default = 220198911) or {+-}size{KMGTP}: +512M
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): L
Type search string, or <Enter> to show all codes: efi
ef00 EFI system partition
Hex code or GUID (L to show codes, Enter = 8300): ef00
Changed type of partition to 'EFI system partition'

Command (? for help): n
Partition number (2-128, default 2):
First sector (34-220200926, default = 1050624) or {+-}size{KMGTP}:
Last sector (1050624-220200926, default = 220198911) or {+-}size{KMGTP}: +1G
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): n
Partition number (3-128, default 3):
First sector (34-220200926, default = 3147776) or {+-}size{KMGTP}:
Last sector (3147776-220200926, default = 220198911) or {+-}size{KMGTP}:
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): L
Type search string, or <Enter> to show all codes: lvm
8e00 Linux LVM
Hex code or GUID (L to show codes, Enter = 8300): 8e00
Changed type of partition to 'Linux LVM'

Command (? for help): p
Disk /dev/vdc: 220200960 sectors, 105.0 GiB
Sector size (logical/physical): 512/131072 bytes
Disk identifier (GUID): BA2BA3FE-0ACF-44F0-B15F-C69D3ABD0A41
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 220200926
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI system partition
   2         1050624         3147775   1024.0 MiB  8300  Linux filesystem
   3         3147776       220198911   103.5 GiB   8E00  Linux LVM

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/vdc.
The operation has completed successfully.

Clonage des partitions

root@rescue:~# time dd if=/dev/vdb2 of=/dev/vdc2 bs=1M conv=sparse status=progress
1070596096 bytes (1.1 GB, 1021 MiB) copied, 5 s, 214 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.76544 s, 186 MB/s

real	0m5.773s
user	0m0.032s
sys	0m5.245s
root@rescue:~# time dd if=/dev/vdb3 of=/dev/vdc3 bs=1M conv=sparse status=progress
106079191040 bytes (106 GB, 99 GiB) copied, 320 s, 331 MB/s
101373+0 records in
101373+0 records out
106297294848 bytes (106 GB, 99 GiB) copied, 321.819 s, 330 MB/s

real	5m21.836s
user	0m1.682s
sys	3m26.323s

Shutdown, évacuation du disque disk4.raw puis reboot. Cette étape peut être omise en cas d'utilisation de pvmove ou en absence d'utilisation de LVM.

root@rescue:~# shutdown -h now
~# mv -i disk4.raw zonevm01-disk0.raw
~# truncate -s 5G disk4.raw
~# zoneadm -z linux-mig boot && (zlogin -e '#' -C linux-mig ou ssh)

Phase de conversion

root@rescue:~# lvdisplay
  --- Logical volume ---
  LV Path                /dev/ubuntu-vg/ubuntu-lv
  LV Name                ubuntu-lv
  VG Name                ubuntu-vg
  LV UUID                lcZugF-CvU8-2dr6-mXQq-GNCh-Bcae-2bqX3P
  LV Write Access        read/write
  LV Creation host, time ubuntu-server, 2023-08-08 10:48:59 +0200
  LV Status              available
  # open                 0
  LV Size                <99.00 GiB
  Current LE             25343
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

root@rescue:~# mkfs.vfat  /dev/vdc1
mkfs.fat 4.2 (2021-01-31)
root@rescue:~# mount /dev/ubuntu-vg/ubuntu-lv /mnt
root@rescue:~# mount /dev/vdc2 /mnt/boot/
root@rescue:~# mkdir  /mnt/boot/efi
root@rescue:~# mount /dev/vdc1 /mnt/boot/efi/
root@rescue:~# for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run
do
  mount -B $i /mnt/$i
done
root@rescue:~# blkid /dev/vdc1
/dev/vdc1: UUID="34D3-FFFD" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="fccf44f5-a235-4c64-ac53-3ac4e1b66a83"
root@rescue:~# chroot /mnt

Vérifier le hostname

root@rescue:/# cat /etc/hostname
zonevm01

Ajouter ou modifier dans configuration grub /etc/default/grub les paramètres suivants:

GRUB_CMDLINE_LINUX="console=tty1 console=ttyS0,115200"
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

Ajouter à /etc/fstab une entrée pour /boot/efi avec les informations extraites ci-dessus:

UUID=34D3-FFFD  /boot/efi       vfat    umask=0077      0       1

Fixer /etc/resolv.conf qui peut s'avérer être un lien symbolique:

root@rescue:~# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 29 Aug  8  2023 /etc/resolv.conf -> ../run/resolvconf/resolv.conf

Terminer le processus par l'installation du package grub-efi-amd64 et de grub:

root@rescue:~# apt update
root@rescue:~# apt install grub-efi-amd64
root@rescue:~# grub-install /dev/vdc
Installing for x86_64-efi platform.
Installation finished. No error reported.

Si une erreur se présente, la commande suivante peut résoudre le problème:

root@rescue:~# grub-install --target=x86_64-efi --bootloader-id=GRUB --efi-directory=/boot/efi --no-nvram --removable

root@rescue:~# update-grub
root@rescue:~# exit
root@rescue:~# shutdown -h now

Astuce

À titre d'exemple, voici ce qu' on pourrait faire pour migrer les datas au sein d'un Volume Group LVM nommé PROD

root@rescue:/# pvmove /dev/vdb1 /dev/vdc2
root@rescue:/# vgreduce PROD /dev/vdb1
root@rescue:/# pvmove /dev/vdb2 /dev/vdc2
root@rescue:/# vgreduce PROD /dev/vdb2

Pour les distributions qui ne sont plus supportées, il faut fixer les sources.list et les faire pointer vers archives.

~# echo "deb [trusted=yes] http://archive.debian.org/debian stretch main non-free contrib" > /etc/apt/sources.list
~# echo "deb-src [trusted=yes] http://archive.debian.org/debian stretch main non-free contrib" >> /etc/apt/sources.list
~# echo "deb [trusted=yes] http://archive.debian.org/debian-security stretch/updates main non-free contrib" >> /etc/apt/sources.list

Maintenant que le disque est converti, il suffit de le copier vers son ZFS final.

~# time /usr/gnu/bin/dd if=/zones/linux-mig/root/raw/disk5.raw of=/zones/zonevm01/root/root/raw/disk0.raw bs=1M conv=sparse status=progress
~# zfs set primarycache=metadata zonevm01/zones/zonevm01

Redémarrer la zone ou la migrer vers un autre node (Cf migration de zone dans manuel d'opérations)

1.3.4 Dérivés de RedHAT Linux, autres Linux ou Unix

La plupart de ce qui a été décrit pour Debain reste vrai pour RedHat et les autres, et ce jusqu'à au chroot dans le système proprement dit. Ensuite, il appartient de mimiquer les actions exécutées pour Debinandans le contexte de l'OS concerné.

L'homogénéité des distributions RedHat est bien moindre que pour les Debian. CentOS, Rocky Linux, Redhat, Oracle Linux, ... ont chacune des spécificités en fonction de leur version qui rendraient fastidieux l'exposition des processus pour chacune d'entre elles, et ce y compris pour les BSD.