Po podłączeniu dysku HDD z systemem Centos (/dev/sdc) do nadzorowanego przez PROXMOX-a (/dev/sda) sprzętu wykonuje obraz na partycję trzeciego tysku (/dev/sdb). Brak możliwości wykonania obrazu źródła (/dev/hdc - 1TB) na systemowy (/dev/hda - 2TB) wynika z ograniczonej pojemności głównej pamięci masowej. Stąd montuje dodatkową partycję 8TB dysku /dev/sdb następującą komendą:

 mount /dev/sdb1 /mnt/sdb1

Mając gdzie możemy wykonać obraz dysku /dev/hdc w formacie qcow2 (patrz. http://bit.sos.pl/blog/historia-sukcesu-2/proxmox-disk-copy-to-qcow2-34 ) na partycję drugiego dysku /dev/hdb1:

qemu-img convert -p -f raw -O qcow2 /dev/sdc /mnt/sdb1/bit_2023_10_08.qcow2

Ponieważ oba dyski /dev/hdc oraz w tym przypadku szczególnie duże znaczenie służący do zapisu dysk /dev/hdb są talerzowe (HDD) trzeba się liczyć trzema godzinami pracy aplikacji qemu-img. Przy zastosowaniu dysku SSD na backup operacja ulegnie przyśpieszeniu przynajmniej trzy krotnie. W trzecim etapie wykonujemy dołączenie stworzonego obrazu do istniejącej VM w środowisku PROXMOX o numerze 301 umieszczonej na logicznej partycji local-lvm komendą:

qm importdisk 301 /mnt/sdb1/bit_2023_10_08.qcow2 local-lvm

Poprawne wykonanie powyższej operacji pozwala na aktywację dysku w opcji HARDWARE GUI PROXMOX dostępnej z poziomu przeglądarki oraz w opcji OPTIONS -> BOOT ORDER zaznaczenie go jako urządzenie aktywne przy starcie VM. Niestety próba uruchomienia tak stworzonej kopii CENTOS-a kończy się komunikatem:

Zanim zaradzimy temu problemowi wyłączamy maszynę wirtualną 301 komendą wydaną dla PROXMOX-a:

qm stop 301

Teraz przy ponownym starcie maszyny 301 wciskamy klawisz F3 i wybieramy tryb awaryjny Linuxa (rescue). System poprosi o podanie hasła root-a. Po pozytywnym zalogowaniu możemy teraz zaradzić powyższemu błędowi wykonując w trybie awaryjnym następujący rozkaz (oczywiście należy go dostosować do własnego środowiska Centos-a zerkając do katalogu ls /boot):  

dracut -f /boot/initramfs-3.10.0-514.26.2.el7.x86_64,img 3.10.0-514.26.2.el7.x86_64