Linux KVM
KVM
KVM - система виртуализации котороая включена в состав ядра linux начиная с 2.6.20. Вероятно, наиболее прогрессивная система, т.к. RedHat переключилась на нее с XEN. Задача - запускать внутри виртуальных машин ОС отличную от хостовой (в моем случае - win32, FreeBSD, linux но другие версии ядра отличные от хостовых).
Сейчас использую VMWare, решил отказаться из-за следующих недостатков
- Неудобство управления (нужно держать под рукой vmware-console)
- Большие накладные расходы.
- VMWare не позволяет эмулировать более 2 процессоров (проверить!)
- Иногда - проблемы при обновлении ядра.
- Нет механизмов ограничения процессорного времени. (или я о них не знаю)
Hardware
KVM требует наличия x86-совместимого процессора с поддержкой одной из технологий аппаратной виртуализации — Intel VT либо AMD SVM. На данный момент KVM в состоянии запускать в качестве гостевых ОС GNU/Linux (32-битные и 64-битные), Windows (32-битные и 64-битные) и другие системы.
Для полноценной работы немодифицированных гостевых ОС потребуется процессор с поддержкой аппаратной виртуализации: Проверить наличие поддержки можно по наличию соответвующих флагов - комманда ниже должна дать непустой результат
В моем случае это
#cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 1 cpu MHz : 2310.439 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch bogomips : 4620.87 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 1 cpu MHz : 2310.439 cache size : 512 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch bogomips : 4621.05 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps
Конфигурация ядра
Что бы включить поддержку KVM, следует включить следующие опции ядра (я использовал модули):
| Linux Kernel Configuration: Поддержка KVM |
Device Drivers --->
[*] Virtualization --->
--- Virtualization
<M> Kernel-based Virtual Machine (KVM) support
<M> KVM for Intel processors support
<M> KVM for AMD processors support
|
Необходимое ПО
Для работы с kvm нужны следующие пакеты:
- app-emulation/kvm
- sys-apps/usbutils (только если нужна поддержка USB. Мне - не нужен)
- net-misc/bridge-utils (только если планируется bridged-net)
- sys-apps/usermode-utilities (нужен для управлениея tap-устройствами)
Еще я использовал:
- app-misc/screen
Запуск первой виртуальной машины
Добавляю в /etc/modules.autoload.d/kernel-2.6:
kvm-amd tun
и загружаю модули (tun нужен для работы сети, на этапе запуска виртуальной машины и установки гостевой WinXP - не нужен)
Далее, создаю диск с именем test1 размером 10G
Что бы посмотретьинформацию о диске можно воспользоваться следующей коммандой
image: ./test1.img file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 1.4G cluster_size: 4096
Далее пробую установить WinXP с образа установочного диска:
Т.к. все эксперементы я провожу на удаленном сервере, где нет ничего связанного с Х, то получаю следующее сообщение
Could not initialize SDL - exiting
Очевидно, что kvm попробовал вывести на экран какую-то графику и у него это не получилось. Отмечу, что я не сразу нашел решение, наиболее простое и правильное - перенаправить вывод графики на vnc. Соответвенно, комманда приобретает вид
Теперь можно подключиться к серверу на порт 5910 по vnc и пронаблюдать загрузку виртуальной машины.
Далее, наблюдаю за установкой и жму "далее" через vnc.
Если ОС не использует графику совсем - то запускать с параметром -curses вместо -vnc. В этом случае вывод будет праямо на текущюю консоль, что в большенстве случаев достаточно удобно.
Натройка сети на хост-системе и виртуальных машинах
Вцелом схема сети выглядит так: (вторая гостевая система пока только в процессе подготовки)
HOST KVM Гостевая система 1 (WinXP)
+-----------------------+ +-----------------+
| 95.69.хх.xx | | |
INET---+---- eth0 | | |
| | | | KVM Гостевая система 2 (FreeBSD 7.2)
| +------+ +--+---+---- nic0 | +--------------+
| |kvm_tap0---------+ | |172.16.254.6 | | |
| | 172.16.254.5 | | | | |
| |kvm_tap0---------+ | +-----------------+ | |
| | 172.16.254.9 | | | |
| +------+ | | | |
| +--+-------------------------+---- nic0 |
| | |172.16.254.10 |
+-----------------------+ +--------------+
Конфигурация ядра для поддержки сети
Понадобиться поддержка в ядре TUN/TAP устройств и возможно VLAN (не уверен что это необходимо). Я в своей конфигурации предпочел использовать routed а не bridged соеднение, и поддержка birdge обязательной не является. Поддержка VLAN мне необходима в любом случае, выключить ее я не могу.
| Linux Kernel Configuration: Поддержка bridging, TUN и VLAN |
Device Drivers --->
[*] Network device support --->
<M> Universal TUN/TAP device driver support
Networking support --->
Networking options --->
<M> 802.1d Ethernet Bridging
<*> 802.1Q VLAN Support
|
Настройка сети в хост-системе
- Загружаем соответвующий модуль)
[433164.306111] tun: Universal TUN/TAP device driver, 1.6 [433164.306114] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
- Добавляем соответвующие интерфейсы и именуем их как нравится.
[ Searching for packages matching sys-apps/usermode-utilities... ] [ Colour Code : set unset ] [ Legend : Left column (U) - USE flags from make.conf ] [ : Right column (I) - USE flags packages was installed with ] [ No USE flags found for sys-apps/usermode-utilities-20040406-r1]
В результате имеем 2 интерфейса в системе.
#ifconfig -a
kvm_tap0 Link encap:Ethernet HWaddr 1e:56:79:e2:41:eb
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
kvm_tap1 Link encap:Ethernet HWaddr 1e:56:79:e2:41:eb
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Настраиваем адреса на них:
Теперь нужно перезапустить виртуальную машину для того что бы включить в ней поддержку сети.
При запуске можно указать какая именно сетевая карта будет сэмулирована для гостевой ОС (по умолчанию - реалтек) и куда его подключить (в моем случае к kvm_tap0). Обязательно указать что никаких скриптов при старте выполнять не нужно (script=no,downscript=no)
Вторая виртуальная машина (FreeBSD 7.2)
Наcтроил dhcpd что бы не прописывать адрес руками
option domain-name "noname.com.ua";
option domain-name-servers 193.33.48.33, 193.33.49.160;
default-lease-time 36000;
max-lease-time 72000;
ddns-update-style none;
log-facility local7;
subnet 172.16.254.8 netmask 255.255.255.252 {
range 172.16.254.10 172.16.254.10;
option routers 172.16.254.9;
option domain-name "virtual.noname.com.ua";
option broadcast-address 172.16.254.9;
default-lease-time 60000;
max-lease-time 720000;
}
Запускаю на установку:
Windows 7 (тест)
Ну, есть и хорошая новость - она работает )
Видеокарты
я использую
т.к.эта видеокарта позволяет наиюолее гибко менять разрешение под WinXP (что мне, собственно, и нужно)
Управление виртуальными машинами
Предварительная настройка (-monitor)
Для управления виртуальными машинами используется консоль. По-умолчанию она доступна из графики (в примере выше - из сессии VNC) с помощью ctr-alt-2 (ctr-alt-1 - возврат в графику )
Но гораздо удобнее использовать сеть для подключении к консоли. Это позволит в будущем использовать скрипты и т.п. "вкусности".
Приведу цитату, думаю этого более чем достаточно для понимания для использования сети:
There are two basic options for redirecting your monitor to tcp sockets, namely raw socket and using the telnet protocol. I’ll go ahead and show the syntax for both options then discuss the options you have. For redirecting your monitor to raw tcp socket you use the following syntax:
-monitor tcp:192.168.1.1:4444,server,nowait
For redirecting to a socket supporting telnet protocol you use the following syntax
-monitor telnet:192.168.1.1:4444,server,nowait
The options are
- tcp – raw tcp sockets
*telnet – the telnet protocol is used instead of raw tcp sockets. This is the preferred option over tcp as you can break out of the monitor using Ctrl-] then typing quit. You can’t break out of the monitor like this after connecting with the raw socket option
- 192.168.1.1 – Listen on this port only. You can use 127.0.0.1 if you want to only allow connections locally. If you want to listen on any ip address on the server, just leave this blank so you end up with two consecutive colons ie “::” .
- 4444 – port number to listen on.
- server – listening in server mode
- nowait – qemu will wait for a client socket application to connect to the port before continuing unless this option is used. In most cases you’ll want to use the nowait option.
Второй вариант - использовать сокеты, как в примере ниже:
-monitor unix:/tmp/socket,server,nowait
Для работы использовать сто-то вроде:
echo 'info' | nc -v -U /tmp/socket
Сейчас я тестирую такую конфигурацию:
Добавление устройств на-лету
Нужно пробросить в ВМ флешку:
usb_add device -- add USB device (e.g. 'host:bus.addr' or 'host:vendor_id:product_id') usb_del device -- remove USB device 'bus.addr'
Например - добавление флешки:
(qemu) usb_add host:058f:6387 usb_add host:058f:6387 husb: using sys file-system with /dev/bus/usb
В консоли где запущена виртуальная машина вижу:
usb_create: no bus specified, using "usb.0" for "usb-host" husb: open device 2.8 husb: config #1 need -1 husb: 1 interfaces claimed for configuration 1 husb: grabbed usb device 2.8 husb: config #1 need 1 husb: 1 interfaces claimed for configuration 1 husb: config #1 need 1
Посмотреть устройства можно или
или из консоли виртуальной машины:
info usb info usb Device 0.1, Speed 12 Mb/s, Product QEMU USB Tablet Device 0.3, Speed 12 Mb/s, Product QEMU USB Hub Device 0.4, Speed 480 Mb/s, Product Mass Storage
(qemu)info usbhost
info usbhost
Device 1.1, speed 12 Mb/s
Hub: USB device 1d6b:0001, OHCI Host Controller
Device 2.1, speed 480 Mb/s
Hub: USB device 1d6b:0002, EHCI Host Controller
Device 2.2, speed 480 Mb/s
Hub: USB device 05e3:0605, USB2.0 Hub
Device 1.2, speed 12 Mb/s
Class e0: USB device 0a12:0001
Device 2.4, speed 12 Mb/s
Class 00: USB device 0403:6001, usb serial converter
Device 2.5, speed 480 Mb/s
Class 00: USB device 05e3:0710, USB2.0 card Reader
Device 2.8, speed 480 Mb/s
Class 00: USB device 058f:6387, Mass Storage
Auto filters:
Device *.* ID 058f:6387
(qemu)
При этом я получил доступ к флешке из виртуальной машины.
Аналогично, если я хочу отключить устройство:
(qemu) usb_del 0.4 usb_del 0.4 (qemu)
Идентификатор 0.4 - я взял из листинга выше
Device 0.4, Speed 480 Mb/s, Product Mass Storage
udev и автоматизация процесса
Естественно, все это можно обернуть в скрипт и, например, всегда автоматически пробрасывать устройство в ВМ.
. Обратить внимание на ключ -w1 - нужно что бы закрывать соединение после команды. У меня -w не работало в пакете nc6 , только в оригинальном nc.
echo "usb_add host:058f:6387" | nc -w1 192.168.15.198 4445 echo "info usb" | nc -w1 192.168.15.198 4445 echo "usb_del 0.3 " | nc -w1 192.168.15.198 4445
По большому счету работа с udev достаточно однообразна, подробности в отдельной статье: http://wiki.sirmax.noname.com.ua/index.php/Udev
Тут приведу только правило и скрипт:
BUS=="usb", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ACTION=="add", NAME="%k", GROUP="disk", ATTRS{serial}=="576B63C4", RUN+="/etc/udev/udev-VM.sh %k %s{idVendor} %s{idProduct}"
BUS=="usb", SUBSYSTEM=="block", KERNEL=="sd*", ACTION=="add", NAME="%k", GROUP="disk", RUN+="/etc/udev/udev-flash-mount.sh add %k"
BUS=="usb", SUBSYSTEM=="block", KERNEL=="sd*", ACTION=="remove", RUN+="/etc/udev/udev-flash-mount.sh remove %k"
Второе и третье правила - монтируют "известные" устройства в соответствующие точки монтирования. sd[a-z] - что бы избежать вызова скрипта для sdf1. Естественно, скрипт "для домашнего использования", но адаптировать его для массового использования нет никакой проблемы.
#!/bin/bash
LOGGER="/usr/bin/logger -t [udev-VM.sh]"
sleep 3
echo "Parameters are: "${1}" "${2} | $LOGGER
env | $LOGGER
echo "usb_add host:"${ID_VENDOR_ID}":"${ID_MODEL_ID} | $LOGGER
echo "usb_add host:${ID_VENDOR_ID}:${ID_MODEL_ID}" | /usr/bin/nc -w 1 192.168.15.198 445 | $LOGGER
echo $? | $LOGGER
exit
На отключение никакой скрипт не навешивал - нет необходимости.
Снапшоты
изучаю
Миграция
Пробую миграцию:
Запускаю еще одну копию ВМ с пустым диском и опцией
-incoming tcp:0:9999
/usr/bin/qemu-system-x86_64 \
-hda \
./test_centos.img \
-vga vmware \
-boot c -m 512M \
-net nic -net tap,ifname=$DEV0,script=no,downscript=no \
-vnc :3 \
-usbdevice tablet \
-usb \
-monitor tcp:192.168.15.198:4446,server,nowait \
-monitor unix:/tmp/winxp2.fifo,server,nowait \
-incoming tcp:0:9999
Запускаю миграцию, наблюдаю прогресс:
(qemu) migrate -d -b tcp:192.168.15.198:9999 migrate -d -b tcp:192.168.15.198:9999 (qemu) (qemu) info migrate info migrate Migration status: active transferred ram: 217 kbytes remaining ram: 536000 kbytes total ram: 541056 kbytes transferred disk: 249856 kbytes remaining disk: 20721664 kbytes total disk: 20971520 kbytes ... (qemu) info migrate info migrate Migration status: active transferred ram: 217 kbytes remaining ram: 536000 kbytes total ram: 541056 kbytes transferred disk: 5641216 kbytes remaining disk: 15330304 kbytes total disk: 20971520 kbytes (qemu) (qemu) info migrate info migrate Migration status: completed
На стороне получателя:
Receiving block device images Completed 100 %
Оригинальная ВМ после миграции остановлена (stop в консоли), снова запустить ее можно используя команду c
Миграция с рабочей станции на другую рабочуюю станциию (рабочий пример)
Продолжая тему живой миграции, пробую реализовать все на практике.
Отмечу что все попытки смигрировать на ВМ на другую архитектуру окончились неудачей.
По этой причиине при подготовки оборудования я просто склонировал ОС, и в ходе эксперемента все программы имеют одну и ту же версию. Ядро, естественнно, то же с теми же опциями.
Hardware details
И процессором (ядер три, но они все одинаковые):
Создаю диск и запускаю ВМ.
qemu-img create -f qcow2 win_xp.img.incoming 20G
Запускаю ВМ и ожидаю входных данных:
DEV0=kvm_tap6
/usr/bin/qemu-system-x86_64 \
-boot c \
-hda \
./win_xp.img.incoming \
-m 512M \
-net nic -net tap,ifname=$DEV0,script=no,downscript=no \
-vnc :11 \
-vga vmware \
-usbdevice tablet \
-usb \
-monitor tcp:127.0.0.1:4411,server,nowait \
-monitor unix:/tmp/winxp.fifo,server,nowait \
-incoming tcp:192.168.15.34:9911
настройка сети
На второй машине 2 интерфейса - нативный влан на eth5 и влан 197 который и будет сбриджован для ВМ
Аналогично на первой рабочей станции. в результате имеем
- на ноде 1 запущена ВМ в рабочем режиме, сеть работает. Поднят ВПН (CiscoVPN) как тестовое приложение. IP 192.168.77.42
- на ноде 2 запущена ВМ в режиме ожидания.
- обе ноды подключены к VLAN197 (eth0.197 и eth5.197 соответвенно)
- на обоих нодах интерфейсы br0 соединяют виртуальные kvm_tap6 и vlan197
- в VLAN197 присутвует шлюз, выпускающий ВМ в инет.
Процесс миграции
Замечу что в процессе миграции я нормаьно продолжал работать на ВМ.
Запускаем процесс миграции:
(qemu) migrate -d -b tcp:192.168.15.34:9911 migrate -d -b tcp:192.168.15.34:9911 (qemu) (qemu) info migrate info migrate Migration status: active transferred ram: 32 kbytes remaining ram: 540900 kbytes total ram: 541056 kbytes transferred disk: 59392 kbytes remaining disk: 20912128 kbytes total disk: 20971520 kbytes (qemu) <SKIPPED> (qemu) info migrate info migrate Migration status: active transferred ram: 32 kbytes remaining ram: 540900 kbytes total ram: 541056 kbytes transferred disk: 178176 kbytes remaining disk: 20793344 kbytes total disk: 20971520 kbytes
Со стороны второй ноды:
Receiving block device images Completed 74 %
Разделение и ограничение ресурсов
VirtIO
Для диска:
${DISK} - имя файла
qemu-img create -o preallocation=metadata -f qcow2 ${DISK} 20G
screen -dmS $VM_NAME /usr/bin/qemu-system-x86_64 \
-drive file=${DISK},if=virtio \
-vga cirrus \
-boot c \
-option-rom /usr/share/kvm/pxe-rtl8139.bin \
-m 512 \
-net nic,model=rtl8139,vlan=0,macaddr=00:16:5e:25:05:${VM_NUMBER} \
-net tap,ifname=$DEV0,script=no,downscript=no \
-vnc :$VM_NUMBER \
-usbdevice tablet \
-usb \
-monitor tcp:127.0.0.1:44${VM_NUMBER},server,nowait \
-monitor unix:/tmp/${VM_NAME}.fifo,server,nowait
Nested virtualization
options kvm-intel nested=y
modprobe kvm-intel nested=y
ToDo
- Ограничение процессорного времени
- Приоритезация (возможно ли?)
- Разделение памяти
Ссылки
Есть некоторая доля вероятности, что какую-то из ссылок которой я воспользовался я забыл указать. Потому, если такое вдруг случиться - укажите мне на ошибку. Я исправлю.
- http://www.ibm.com/developerworks/ru/library/l-linux-kvm/
- http://tyom.blogspot.com/
- http://jack.kiev.ua/docs/qemu-doc-ru.html
- http://www.pivpav.ru/2011/05/406.html
- http://www.ossportal.ru/technologies/kvm?page=1
- http://www.opennet.ru/openforum/vsluhforumID3/63200.html
- http://mydebianblog.blogspot.com/2008/09/qemu-usb.html
- http://xgu.ru/wiki/man:qemu
http://jack.kiev.ua/docs/qemu-doc-ru.html http://www.opennet.ru/opennews/art.shtml?num=25119
