Цель: Вот я склонировал VM
базирующейся на связке QEMU + KVM применительно к Ubuntu 18.04 Server amd64
, а что дальше — ведь нужно же ее как-то подготовить перед использование, по аналогии как делается с Windows
системами через sysprep
. А у меня Ubuntu
система — значит и для нее данную процедуру по обезличиванию нужно проделать.
Как я делал клонирование VM
, через virt-manager
подключаюсь к своему хосту (Ubuntu 18.04 Server + QEMU/KVM
), открываю снапшоты у VM
, откатываюсь на необходимый и после в свойствах контейнера VM
запускаю процесс: «Виртуальная машина
» — «Клонировать
». VM
успешно склонировалась, но вот если запустить эталонную виртуальную машину и склонированную наблюдается что при различных MAC
-адресах они обе получают одинаковый IP
-адрес от роутера.
Сейчас я с нуля пройдусь по шагам клонирования VM
через консоль командной строки на хосте QEMU+KVM
хост на базе Ubuntu 18.04 Server amd64
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
ekzorchik@navy:~$ ssh -l ekzorchik 172.33.33.25 ekzorchik@srv-bionic:~$ sudo virsh list --all Id Name State ---------------------------------------------------- - FOX_PXE_1804_Server shut off - generic shut off - UServer1804 shut off → клонирую вот эту систему (снапшот откатил через virt-manager) - Userver1804_2 shut off - UServer1804_3 shut off - W7X64 shut off ekzorchik@srv-bionic:~$ |
Шаг №1: Проверяю что утилита virt-sysprep
доступна в консоли если это не так, то устанавливаю на хост необходимый пакет:
1 2 3 4 5 6 7 8 9 10 11 |
ekzorchik@srv-bionic:~$ virt-sysprep Command 'virt-sysprep' not found, but can be installed with: sudo apt install libguestfs-tools ekzorchik@srv-bionic:~$ sudo apt-get install -y libguestfs-tools ekzorchik@srv-bionic:~$ virt-sysprep -V virt-sysprep 1.36.13 |
Шаг №2: Клонирую необходимую виртуальную машину:
1 2 3 4 5 |
ekzorchik@srv-bionic:~$ sudo virt-clone --connect qemu:///system --original UServer1804 --name UServer1804_CLONE --file /var/lib/libvirt/images/UServer1804_CLONE.qcow2 Allocating 'UServer1804_CLONE.qcow2' | 40 GB 00:07 Clone 'UServer1804_CLONE' created successfully. |
Шаг №3: Делаем Sysprep
для склонированной VM (она у меня под именем UServer1804_CLONE
)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 |
ekzorchik@srv-bionic:~$ sudo virt-sysprep -d UServer1804_CLONE [ 0.0] Examining the guest ... [ 2.5] Performing "abrt-data" ... [ 2.5] Performing "backup-files" ... [ 2.9] Performing "bash-history" ... [ 2.9] Performing "blkid-tab" ... [ 2.9] Performing "crash-data" ... [ 2.9] Performing "cron-spool" ... [ 2.9] Performing "dhcp-client-state" ... [ 2.9] Performing "dhcp-server-state" ... [ 2.9] Performing "dovecot-data" ... [ 2.9] Performing "logfiles" ... [ 3.0] Performing "machine-id" ... [ 3.0] Performing "mail-spool" ... [ 3.0] Performing "net-hostname" ... [ 3.0] Performing "net-hwaddr" ... [ 3.0] Performing "pacct-log" ... [ 3.1] Performing "package-manager-cache" ... [ 3.1] Performing "pam-data" ... [ 3.1] Performing "passwd-backups" ... [ 3.1] Performing "puppet-data-log" ... [ 3.1] Performing "rh-subscription-manager" ... [ 3.1] Performing "rhn-systemid" ... [ 3.1] Performing "rpm-db" ... [ 3.1] Performing "samba-db-log" ... [ 3.2] Performing "script" ... [ 3.2] Performing "smolt-uuid" ... [ 3.2] Performing "ssh-hostkeys" ... [ 3.2] Performing "ssh-userdir" ... [ 3.2] Performing "sssd-db-log" ... [ 3.2] Performing "tmp-files" ... [ 3.2] Performing "udev-persistent-net" ... [ 3.2] Performing "utmp" ... [ 3.2] Performing "yum-uuid" ... [ 3.2] Performing "customize" ... [ 3.2] Setting a random seed [ 3.2] Setting the machine ID in /etc/machine-id [ 3.2] Performing "lvm-uuids" ... ekzorchik@srv-bionic:~$ |
О доступных операциях с помощью virt-sysprep
1 |
ekzorchik@srv-bionic:~$ sudo virt-sysprep --list-operations |
Шаг №4: Проверяю, а запуститься ли теперь виртуальная машина с системой внутри нее. Но вот все те так уже и хорошо, в консоли VM
(через virt-manager
) вижу:
1 |
ekzorchik@srv-bionic:~$ sudo virsh start UServer1804_CLONE |
Domain UServer1804_CLONE started
Booting from Hard Disk…
error: disk
lvmid/IDENTIFICATE
not found
Entering rescue mode…
grub rescue>
Вопрос почему?
Как я понял, загрузчик не смог найти /boot
раздел для обычной загрузки и вывалился в ошибку указал раздел с указанным lvmid
— мол хозяин поправь я тебя специально в режим восстановления GRUB RESCUE
отправил.
На заметку: В режиме grub rescue>
доступны только 4 команды, но это более чем достаточно, а команды: ls, set, unset, insmod
Шаг №5: Посредством команды ls
в режиме восстановления grub
отобразим все же какие разделы видит grub
1 2 3 4 5 |
grub rescue> ls (hd0) (hd0,msdos1) (lvm/srv--bionic--vg-swap_1) (lvm/srv--bionic--vg-root) grub rescue> |
Шаг №6: В моем случаем у меня система полностью установлена на LVM
, т. е. Раздел boot
расположен на lvm
разделе, а значит укажем загрузчику использовать раздел lvm
:
1 2 3 4 5 6 7 8 9 |
grub rescue> ls (lvm/srv--bionic--vg-root)/boot/ ./ ../ config-4.15.0-48-generic grub/ System.map-4.15.0-48-generic vmlinuz-4.15.0-48-generic initrd.img-4.15.0-48-generic grub rescue> set prefix=(lvm/srv--bionic--vg-root)/boot/grub grub rescue> set root=(lvm/srv--bionic--vg-root) grub rescue> |
Шаг №7: Загружаем необходимые модули дабы внесенные изменения запустили систему:
На заметку: Самым правильным способом считаю самим пройтись и определить какие модули нужны будут для загрузки и добавить, а не пользоваться найденными на просторах статей интернета. Так Вы запомните ошибки и сообщения которые возникают когда система не может загрузится и для Вас не будет в дальнейшем паники, что делать? У меня такого никогда не было.
1 2 3 4 5 6 7 8 9 10 11 |
grub rescue> insmod lvm grub rescue> insmod normal grub rescue> normal → пробуем загрузить систему, если все хорошо система загрузится как обычно: Ubuntu 18.04.2 LTS srv-bionic tty1 Hint: Num Lock on srv-bionic login: |
и IP
адрес уже получила не такой как у основной ВМ с которой выполнялось клонирование:
1 2 3 4 5 6 7 |
ekzorchik@srv-bionic:~$ ip r default via 172.33.33.1 dev ens0 proto dhcp src 172.33.33.17 metric 100 172.33.33.0/24 dev ens0 proto kernel scope link src 172.33.33.17 172.33.33.1 dev ens0 proto dhcp scope link src 172.33.33.17 metric 100 |
Если же система не загрузилась, то вот пример наиболее часто встречающихся модулей на загрузку:
1 2 3 4 5 |
grub rescue> insmod ext2 grub rescue> insmod lvm grub rescue> insmod part_msdos |
На заметку: На действующей системе можно посмотреть какие модули при загрузке используется посмотрев файл: cat /boot/grub/grub.cfg
Авторизуюсь в системе и отправляю ее в ребут дабы убедиться что она загрузится самостоятельно:
1 |
ekzorchik@srv-bionic:~$ sudo reboot |
Но вот не задача, снова такая же ошибка, что опять и так каждый раз вручную править — это бред, нужно разобрать реальное практическое решение. Повторяю шаги выше, но систему не перезагружаю.
1 2 3 4 5 |
ekzorchik@srv-bionic:~$ sudo grub-install /dev/vda ekzorchik@srv-bionic:~$ sudo update-grub ekzorchik@srv-bionic:~$ sudo reboot |
и вот после перезагрузки система запустилась без какой-либо ошибки. Теперь работает.
На этом у меня пока все, с уважением автор блога Олло Александр aka ekzorchik.