Клонирование виртуальных машин KVM

Перед клонированием убедитесь, что исходник содержит все необходимое для будущих клонов. Если вы только что установили операционную систему, подумайте, возможно имеет смысл доустановить mc, nano, traceroute, настроить сети, hostname, motd для ssh, iptables и др. Проверьте работу сети, установите последние обновления. А может быть, и httpd с почтовым сервером настройте. Убедитесь, что оригинал для клонирования не вызывает подозрений и работает стабильно. Готовы? Поехали!

Смотрим список виртуальных машин:

Создадим копию vm1 и назовем ее vm2.

Для начала остановим оригинал:

# virsh suspend vm1

или выключим его:

# virsh shutdown vm1

Дальше предлагаю рассмотреть два варианта:

1-й вариант: утилита virt-clone:

# virt-clone -o vm1 -n vm2 -f /data/vms/vm2.img —connect=qemu:///system
WARNING Setting the graphics device port to autoport, in order to avoid conflicting.
Allocating ‘vm2.img’ | 20 GB 00:00:06

Clone ‘vm2’ created successfully.

Т.к. команду мы выполняли от root, то virt-clone создала клон диска vm1.img с именем vm2.img с владельцем root:root, а не qemu:qemu. На скорость не влияет. Главное, убедиться, что диск создан:

# ls -al /data/vms/
total 3104656
drwxr-xr-x. 2 root root 4096 Apr 27 06:17 .
drwxr-xr-x. 5 root root 4096 Apr 19 17:45 ..
-rw-r—r—. 1 qemu qemu 21478375424 Apr 27 06:17 vm1.img
-rw-r—r—. 1 root root 1587609600 Apr 27 06:17 vm2.img

При запуске vm2 можете увидеть такое сообщение:

# virsh start vm2
error: Failed to start domain vm2
error: internal error: process exited while connecting to monitor: 2016-04-27T10:19:21.991952Z qemu-kvm: -chardev socket,id=charchannel0, path=/var/lib/libvirt/qemu/channel/target/domain-vm1/org.qemu.guest_agent.0,server,nowait: Failed to bind socket: Permission denied 2016-04-27T10:19:21.992122Z qemu-kvm: -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-vm1/org.qemu.guest_agent.0, server,nowait: chardev: opening backend «socket» failed

Обратите внимание на domain-vm1 в тексте ошибки. Исправляем это (ищем domain-vm1 и заменяем на domain-vm2):

# virsh edit vm2
Domain vm2 XML configuration edited.

# virsh start vm2
Domain vm2 started

2-й вариант (ручками)

Т.к. vm2 уже есть, создадим vm3 и сравним результаты.

# virsh shutdown vm1

Делаем дамп xml от vm1:

# virsh dumpxml vm1 > /tmp/vm3-template.xml

Удаляем UUID оригинала, libvirt добавит новые значения:

# sed -i /uuid/d /tmp/vm3-template.xml
# sed -i ‘/mac address/d’ /tmp/vm3-template.xml

Переименовываем имена со старого на новое:

# sed -i s/vm1/vm3/ /tmp/vm3-template.xml

Создаем новую vm3:

# virsh define /tmp/vm3-template.xml
# virsh start vm1
# virsh start vm3

Этот вариант я подсмотрел здесь: http://unix.stackexchange.com/questions/8351/

Разбор полетов

В чем я увидел отличия, так это в том, что в первом случае размер диска vm2 сильно отличался от размера vm3:

# ls -al —block-size=M /data/vms/
total 4550M
drwxr-xr-x. 2 root root 1M Apr 27 06:44 .
drwxr-xr-x. 5 root root 1M Apr 19 17:45 ..
-rw-r—r—. 1 qemu qemu 20484M Apr 27 07:00 vm1.img
-rw-r—r—. 1 qemu qemu 1515M Apr 27 07:00 vm2.img
-rw-r—r—. 1 qemu qemu 20484M Apr 27 06:59 vm3.img

Судя по всему, virt-clone при создании клона копирует только реально занятое виртуальной машиной место. Размер vm2.img лишь чуть-чуть больше, чем показания «df -h», выполненной в vm1, vm2 или vm3 (т.к. между клонированиями я ничего с гостями не делал, то и размер их не менялся относительно «предка» vm1).

Вообще, когда вы с чем-то сталкиваетесь впервые, старайтесь анализировать изменения после каждого шага. Сделали «sed -i /uuid/d /tmp/vm3-template.xml» — посмотрели. Сравнили с оригиналом. Потом склонировали vm2, на всякий случай просмотрите директорию, где у вас хранятся диски гостей. Создали новую сеть — поинтересуйтесь, был ли создан файл настроек сети в /etc/libvirt/qemu/networks. Ну и в таком роде.

Где бы вы что-то ни увидели, старайтесь все, что вам незнакомо, проверять до выполнения в консоли. Увидели в этой статье пример команды virt-clone, не поленитесь, сходите в интернет и поищите, кто еще так предлагает, что пишет man.

Старайтесь все ваши действия документировать, записывать, комментировать и тогда вы получите свой собственный how-to и будете его использовать, когда надо будет через год создать еще парочку гостей. Если вы не создаете виртуальные машины регулярно, то будет нормально, если вы забудете синтаксис, а history может быть очищена или заполнена таким количеством всяких команд, да еще и с очепятками, что вам опять придется разбираться по-новой.

Источник

Как клонировать существующие образы виртуальной машины KVM в Linux

Я хотел клонировать мою виртуальную машину Debian или Ubuntu Linux KVM для тестирования. Как клонировать существующие образы виртуальной машины в KVM?

Вы можете использовать простую команду с именем virt-clone . Это утилита командной строки для клонирования существующих образов виртуальной машины с использованием библиотеки управления гипервизором «libvirt». Он скопирует образы дисков любой существующей виртуальной машины и определит нового гостя с идентичной конфигурацией виртуального оборудования. Элементы, которые требуют уникальности, будут обновлены, чтобы избежать столкновения между старыми и новыми гостями.

Как клонировать вашу виртуальную машину и создавать новые экземпляры в KVM

Синтаксис будет выглядеть следующим образом

Примеры

Сначала, виртуальная машина/домен с устройствами для клонирования должна быть приостановлена или отключена. Чтобы изящно завершить работу домена с именем ubuntu-box1 , запустите:

ИЛИ вы можете приостановить её следующим образом:

Примеры возможных выводов данных:

Давайте сгенерируем новое имя гостя и пути для нового автоматического сохранения для виртуальной машины, под названием ubuntu-box1

Примеры возможных выводов данных:

Вышеупомянутая команда клонировала гостя под названием «demo» по умолчанию, автоматически создает новое имя, которое выглядит как ubuntu-box1-clone , а также клон пути диска. Вы можете начать или возобновить исходный домен:

Далее, запустите ubuntu-box1-clone , для этого введите:

Мой сервер dhcpd дал 192.168.2.147 IP-адрес ubuntu-box1-clone виртуальной машине, выполните:

И наконец, ssh там, где нам надо:

Рисунок 01 Команда virt-clone клонирует существующие образы виртуальной машины

Обратите внимание, что virt-clone ничего не меняет в гостевой операционной системе, он только дублирует диски и изменяет хост-сервер. Таким образом, такие вещи, как смена паролей, изменение статического IP-адреса, ssh-ключей, имен хостов и т. д., выходят за рамки этого инструмента. После входа в систему с помощью клонирования виртуальной машины, используя ssh, вы можете изменить следующее:

Вы можете использовать virt-sysprep вместо virt-clone , если вам нужно клонировать виртуальную машину и делать / перезагружать что-либо внутри гостевой операционной системы.

Источник

Клонирование виртуальных машин KVM

Для клонирования ВМ можно использовать простую команду virt-clone. Это утилита командной строки для клонирования существующих образов виртуальных машин с использованием библиотеки «libvirt». Она скопирует образы дисков любой существующей ВМ и определит нового гостя с идентичной конфигурацией виртуального оборудования. Элементы, которые требуют уникальности, будут обновлены, чтобы избежать столкновения между старыми и новыми ВМ.

Как клонировать существующие образы виртуальных машин KVM в Linux

Пример клонирования ВМ с помощью virt-clone

ВМ для клонирования должна быть приостановлена или отключена. Чтобы корректно завершить работу ВМ с именем vm1, выполните:
ИЛИ поставьте ВМ на паузу:

Давайте сгенерируем новую ВМ на основе vm1
Приведенная выше команда клонировала ВМ vm1, автоматически сгенерировав новое имя vm1-clone и путь к образу. Теперь можно запустить или снять с паузы оригинальную ВМ:
Или
Теперь можно запустить склонированную vm1-clone:
И убедиться, что она запущена:
И наконец, подключаемся к ВМ:

Примечание

virt-clone ничего не меняет в гостевой ОС, он только дублирует диски и вносит изменения на стороне хоста. Таким образом, такие вещи, как изменение паролей, изменение статического IP-адреса, ssh-ключей, имен хостов и т. д. не входят в сферу применения этого инструмента.

После входа в клонированную ВМ с помощью ssh вы можете изменить их:

Но что делать, если у вам надо сделать 10 клонов? Для этого можно воспользоваться утилитой virt-sysprep, чтобы изменить hostname ВМ и сбросить все настройки внутри ОС.

Сначала установите пакет libguestfs-tools:

Теперь можно запустить virt-sysprep:

Вот такой у меня вывод после запуска virt-sysprep -d pgsql-1 —hostname pgsql-1:

Источник

Virtualbox: клонирование виртуальных машин

Клонирование созданных виртуальных машин — задача, частая при создании и тестировании собственных индивидуализированных сборок. Благо, в Virtualbox’е она выполняется не просто, а очень просто. Соответствующая функция вызывается либо из главного меню: Машина –> Клонировать, либо из контекстного меню по ПКМ:

Очевидно, что в любом случае клонируемая машина должна быть выключена — в работающей машине указанный пункт активизирован не будет.

В появившемся окне будет предложено задать имя новой машины — по умолчанию это будет Клон [orig-name], однако ясно, что оно может быть любым, кроме совпадающего с исходным:

Нужно ли генерировать новые MAC-адреса для сетевых устройств — зависит от задачи. Для тех целей, в которых я использую Virtualbox (тестирование и модификация собственных образов) — не нужно.

Далее предлагается определить с типом клонирования — полным или связным. Чем они разлимчаются — очевидно из поясняющего текста. Для моих целей подходит только полное клонирование:

Далее начинается процесс клонирования:

Длительность его зависит от величины VDI-образа и быстродействия. По завершении клонирования никакого сообщения не выводится — просто в списке виртуальных машин появляется ещё одно имя:

В примере можно видеть cintu-ts — собранную «вручную» систему-матку из mini.iso Ubuntu 16.04.1 и Cinnamon из репозитория Tsvetko, без всяких дополнительных компонентов, и два её (пока) точных клона, которым со временем предстоит стать mini- и midi-редакциями Cintu 16.04.2, соответственно.

Оставьте комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник

Работа с виртуальными машинами KVM. Клонирование виртуальных машин

Продолжаем серию статей о виртуализации на базе KVM. В предыдущих статьях было рассказано об инструментарии, о настройке хост-машины и создании виртуальной машины. Сегодня мы поговорим о создании образа виртуальной машины и его клонировании.

Исследования вопроса дали удручающие результаты: информацию по созданию образов виртуальных машин в сети очень сложно найти, а та, что есть, качеством и полнотой не отличается.

Для получения образа виртуальной машины в минимальной системе в ней достаточно поменять всего пару файлов чтобы получить нормально работающую систему, но в случае Debian появляются небольшие сложности.

Для создания новой виртуальной машины на основе имеющейся системы нужно внести следующие изменения:

• изменить hostname
• поправить файл hosts
• изменить настройки DNS
• заменить хост-ключи SSH
• изменить пароль для root

Большой находкой для меня оказалась библиотека libguestfs — она позволяет управлять дисками и оперировать файлами виртуальных машин как в интерактивном режиме, так и по заранее составленному сценарию.

Эту библиотеку написал Richard Jones из небезызвестной компании Red Hat. Она позволяет работать с файловыми системами (начиная от ext2 и заканчивая NTFS в Windows, UFS в FreeBSD — в общем, со всеми файловыми системами, с которыми умеет работать ядро), образами систем, LVM-разделами, в случае установки гостевых ОС из семейства MS Windows — править системный реестр (через библиотеку hivex). В общем, утилита очень богатая возможностями и очень гибкая. И что самое главное — не требует административных (root) прав для ее использования.

Исследуем образ

Итак, приступим к работе.

Основным инструментом, с помощью которого мы будем работать с образом гостевой системы, является guestfish.

Попробуем произвести некоторые операции в интерактивном режиме:

$ guestfish
> add-drive debian_5_i386.img
> run
> list-filesystems
/dev/vda1: ext3
> mount-vfs rw ext3 /dev/vda1 /
> cat /etc/fstab
# /etc/fstab: static file system information.
#
#

proc /proc proc defaults 0 0
/dev/vda1 / ext3 errors=remount-ro 0 1
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0

Что очень здорово — все необходимые операции можно производить и в неинтерактивном режиме (по заранее составленному сценарию). Приведу пример скрипта, который редактирует файлы hosts, hostname и interfaces в системе:

Использование heredoc оказалось очень удобным в данном контексте.

(К слову: если возникают какие-либо вопросы по библиотеке, на них сам автор очень быстро отвечает на IRC канале #libguestfs на irc.freenode.net. Да и вообще парень очень интересный.)

Secure Hell

Как видно из названия, я с этим вопросом достаточно долго промучился: в Debian/Ubuntu автоматической регенерации ключей при их удалении попросту нет. В других системах, которые я пробовал использовать, с этим всё в порядке, а для deb-based операционных систем с этим проблемы.

Я сделал вот так:

$ guestfish
> add-drive debian_guest.img
> run
> mount-vfs rw ext3 /dev/vda1 /
> download /etc/init.d/ssh /home/username/debian_5_etc_init_ssh

Далее были сделаны следующие изменения:

— /home/username/debian_5_etc_init_ssh 2012-12-21 00:00:00.000000000 +0000
+++ /home/username/debian_5_etc_init_ssh_fixed 2012-12-21 00:00:00.000000000 +0000
@@ -32,6 +32,10 @@
([ «$previous» ] && [ «$runlevel» ]) || [ «$runlevel» = S ]
>

+check_ssh_host_key() <
+ if [ ! -e /etc/ssh/ssh_host_key ] ; then
+ echo «Generating Hostkey. »
+ /usr/bin/ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N » || return 1
+ fi
+ if [ ! -e /etc/ssh/ssh_host_dsa_key ] ; then
+ echo «Generating DSA-Hostkey. »
+ /usr/bin/ssh-keygen -d -f /etc/ssh/ssh_host_dsa_key -N » || return 1
+ fi
+ if [ ! -e /etc/ssh/ssh_host_rsa_key ] ; then
+ echo «Generating RSA-Hostkey. »
+ /usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N » || return 1
+ fi
+>
+
check_for_no_start() <
# forget it if we’re trying to start, and /etc/ssh/sshd_not_to_be_run exists
if [ -e /etc/ssh/sshd_not_to_be_run ]; then
@@ -75,6 +79,7 @@

case «$1» in
start)
+ check_ssh_host_key
check_privsep_dir
check_for_no_start
check_dev_null
@@ -106,6 +111,7 @@
;;

restart)
+ check_ssh_host_key
check_privsep_dir
check_config
log_daemon_msg «Restarting OpenBSD Secure Shell server» «sshd»

Внимание, патч нерабочий, он приведён как пример необходимых изменений.

И для двух версий Debian/Ubuntu я сделал аналогичный файл с уже изменённым файлом ssh. Далее его можно просто загрузить в виртуальную машину.

> upload /home/username/debian_5_etc_init_ssh_fixed /etc/init.d/ssh

А теперь удалим ключи, чтобы они сгенерировались автоматически:

> glob rm /etc/ssh_host_*_key*

Удаление по маске не работает. Поскольку в API данный метод не реализован, префикс glob позволяет развернуть маску в список файлов.

Для FreeBSD и CentOS достаточно просто удалить ключи, при старте они сами сгенерируются.

Идентификация пользователей

Для начала стоит рассказать о том, как представлено хранение информации о пользователях в Linux/FreeBSD. Это будет немного занудно, но необходимо для понимания того, что мы всё-таки делаем. Хотя по минимуму достаточно информации только о shadow-файле.

Вся необходимая для аутентификации пользователей хранится в файлах /etc/passwd и /etc/shadow(/etc/master.passwd в FreeBSD).

Рассмотрим структуру файла /etc/passwd

Процитирую из вики порядок использования полей:

• регистрационное имя или логин
• хеш пароля (сейчас не используется, используется скрытый в shadow пароль)
• идентификатор пользователя
• идентификатор группы по умолчанию
• информационное поле GECOS
• начальный (он же домашний) каталог
• регистрационная оболочка, или shell

Рассмотрим структуру /etc/shadow

• имя пользователя
• хэш пароля
• дата последнего изменения пароля
• через сколько дней можно будет поменять пароль
• через сколько дней пароль устареет
• за сколько дней до того, как пароль устареет, начать напоминать о необходимости смены пароля
• через сколько дней после того, как пароль устареет, заблокировать учётную запись пользователя
• дата, при достижении которой учётная запись блокируется
• зарезервированное поле

Нам нужно изменить конкретно второе поле (хэш пароля). Его можно разбить на три части:

• 1 — тип шифрования md5, 2 — SHA512 (поправьте меня если я не прав)
• APv1HQOB — соль, через которую шифруется пароль
• HJQhYFq9JSnhusQ.1Ql10. — непосредственно хэш пароля с солью.

Хэш генерируется командой:

$ mkpasswd —method=md5 —salt=»APv1HQOB» «$password»
$1$APv1HQOB$HJQhYFq9JSnhusQ.1Ql10.

Его нам и нужно подставить в файл /etc/shadow.

Я написал небольшой скрипт, который будет генерировать случайный пароль и соль длиной 8 символов, выводить его, генерировать хэш и подставлять его в нужный файл:

#!/bin/bash
tempfile=`mktemp`
shadow=»/etc/shadow»
salt=`pwdgen`
passwd=`pwdgen`
hash=`pwhash $salt $password`
hash_esc=`escape_hash $hash `
pwdgen() <
charspool=(‘a’ ‘b’ ‘c’ ‘d’ ‘e’ ‘f’ ‘g’ ‘h’ ‘i’ ‘j’ ‘k’ ‘l’ ‘m’ ‘n’ ‘o’ ‘p’ ‘q’ ‘r’ ‘s’ ‘t’ ‘u’ ‘v’ ‘w’ ‘x’ ‘y’ ‘z’ ‘0’ ‘1’ ‘2’ ‘3’ ‘4’ ‘5’ ‘6’ ‘7’ ‘8’ ‘9’ ‘0’ ‘A’ ‘B’ ‘C’ ‘D’ ‘E’ ‘F’ ‘G’ ‘H’ ‘I’ ‘J’ ‘K’ ‘L’ ‘M’ ‘N’ ‘O’ ‘P’ ‘Q’ ‘R’ ‘S’ ‘T’ ‘U’ ‘V’ ‘W’ ‘X’ ‘Y’ ‘Z’);
len=$<#charspool[*]>
for c in $(seq 8); do
echo -n $
done
>

pwhash() <
salt=$1
password=$2
hash=`mkpasswd —method=md5 —salt=$salt $password`
echo $hash
>

# Функция нужна, чтобы sed корректно отработал закрывающие слэши и знаки $
escape_hash() <
echo $1 | sed -e ‘s/\//\\\//g’ -e ‘s/\$/\\\$/g’
>

guestfish $tempfile.new
upload $tempfile.new $shadow
EOF

Как вы наверняка заметили, мы использовали внешнюю команду внутри скрипта, в которой мы заменили содержимое первой секции на полученный в скрипте хэш. Для этого используется внешний оператор «! «: он очень удобен, когда нам нужно сделать какие-то небольшие операции, не прерывая процесс работы с guestfish (поскольку на запуск guestfish всё таки требуется некоторое время).

Подготовка мастер-образа

Поскольку образы требуется периодически обновлять (в случае выхода важных обновлений или исправления ошибки в образе), нам следует подготовить мастер-образы, в которых мы будет производить необходимые манипуляции. Для разворачивания мы будем готовить эти образы при помощи отдельного скрипта.

Что нам нужно убрать в нашем образе:

1. Очистить логи
2. Удалить следы пребывания в системе
3. Удалить скачанные пакеты (актуально для Debian и Ubuntu, только они мусорят)
4. Удалить файл с настройками сетевой карты
5. Удалить ключи.

После этого нам нужно будет уменьшить размер файловой системы, уменьшить раздел и отрезать от образа лишнее.

Приложу небольшой участок кода, который выполняет первую часть необходимого действия:

Флаг «-» перед командой означает, что мы не должны выходить, если какая-то из команд вернёт -1. Это сделано специально, чтобы отсутствие каких-либо файлов не прерывало выполнение остальных команд; таким образом, кастомизация данного скрипта для различных дистрибутивов становится не нужной, хотя она и возможна.

А теперь приступим к уменьшению образа:

$ guestfish /tmp/block_count
EOF
$ foo=`cat /tmp/block_count`
$ guestfish

Цифра 2144 — это размер загрузчика и таблицы разделов.

Вкратце суть проделанного в следующем: мы ужимаем файловую систему до минимального размера, вычисляем, сколько она стала занимать (минимальное количество блоков), и умножаем их на 4, поскольку размер блока 4 кбайта, после чего создаём образ полученной величины.

После этого нам необходимо будет воспользоваться утилитой virt-resize из комплекта утилит libguestfs, чтобы перенести получившуюся файловую систему в новый, меньший образ.

$ virt-resize —shrink /dev/vda1 debian_guestl.img debian_guest_minimal.img

Следует сразу обговорить ограничения данного метода: это применимо только для файловых систем ext2-4, поскольку resize2fs работает только с ними. Для чего-то нестандартного можно легко допилить нужный функционал (правда, как я уже упоминал ранее, libguestfs очень сложно собрать). Для образца можно посмотреть мой патч для реализации resize2fs-M.

К сожалению с FreeBSD всё сильно сложнее, и пока нет никаких вариантов решения проблемы с ней кроме добавления в конфиг виртуальной машины ещё одного диска и его монтирования.

Теперь же мы должны, по желанию, конечно, упаковать получившийся образ при помощи xz (это долго, но результат стоит того):

$ xz -9 debian_guest.img
$ ls -lsha debian_guest.img.xz
107M -rw-r—r— 1 username username 107M Dec 21 00:00 debian_guest.img.xz

Разворачивание образа

Итак, образ виртуальной машины мы получили, но образы — это не готовые рабочие системы. Чтобы получить рабочую систему, нам нужно произвести несколько операций:

1. Аллоцировать образ на диск
2. Скопировать загрузчик и таблицу разделов
3. Перенести информацию из шаблона в образ виртуальной машины
4. Расширить файловую систему
5. Сменить пароль root
6. прописать сетевые настройки

Для Linux всё элементарно: в составе libguestfs есть замечательная утилита, написанная на OCaml — virt-resize, пункты с 2 по 4 выполняются ею без проблем.

По ряду причин на »’guestfish»’ реализовать изменение размера диска невозможно (копирование mbr в guestfish невозможно), посему нужно использовать более функциональные средства.

Собственно, это все, что минимально требуется знать для осуществления клонирования образов виртуальных машин.

Следующая статья расскажет про лимитирование ресурсов виртуальных машин.

Источник