Qemu-KVM: работа в Debian: различия между версиями
imported>Vix (Новая страница: «Данная статья — это обобщение информации, накопленной за время использования гипервизо…») |
imported>Vix Нет описания правки |
||
Строка 215: | Строка 215: | ||
* [http://habrahabr.ru/post/170259/ взято тут...] | * [http://habrahabr.ru/post/170259/ взято тут...] | ||
* [http://rus-linux.net/MyLDP/vm/kvm-v-debian.html еще полезное .. ] |
Текущая версия от 18:54, 16 января 2016
Данная статья — это обобщение информации, накопленной за время использования гипервизора Qemu-KVM. Я хочу поделиться теми знаниями опытом, которыми обладаю на данный момент. Надеюсь, что моя статья пойдет на пользу тем, кто только собирается использовать гипервизор Qemu-KVM или уже использует. И еще: статья не для новичков linux (элементарные вещи здесь рассматриваться не будут).
Про данную систему виртуализации в сети написано много. Но когда действительно начинаешь с ней работать — сталкиваешься с нехваткой информации и практических примеров применения. Итак приступим.
Входящая задача. Был выделен компьютер как тестовая станция – для проверки работоспособности резервных копий баз данных, устанавливаемого программного обеспечения, сборки msi пакетов и прочих весьма разнообразных задач. Конфигурация компьютера:
процессор Atlon X2 245 оперативная память 4 гигабайта жесткий диск 500 гигабайт материнская плата ASUS M4N68T-M LE.
После непродолжительного раздумья было принято решение использовать компьютер как платформу для работы с виртуальными машинами. Процессор аппаратную виртуализацию поддерживал. В связи с этим было принято решение установить еще 1 жесткий диск. Порывшись в «закромах родины» был найден диск на 80 гигабайт. Его добавили к конфигурации.
С компьютером разобрались. Теперь на очереди гипервизор. Хотелось работать с такой платформой, которую потом можно использовать в корпоративной среде. Поэтому virtualbox, microsoft virtual pc, vmware workstations не подходили. Встал следующий вопрос — какую систему выбрать:
Microsoft hyper-v не подходит — платная. Компания, в которой я работаю использует только лицензионное программное обеспечение. Следовательно никто не выделит для моих целей лицензию на сервер. VMWARE ESXi не знает контролера SATA, расположенного на материнской плате (поскольку разрабатывалась для серверных систем). Qemu-kvm — свободно разрабатываемый гипервизор, поддерживает аппаратную виртуализацию. Его можно установить в любой современный дистрибутив Linux. Это по мне, его и берем.
Выбор дистрибутива Linux. Стандартно я использую Debian. Вы можете выбрать любой понравившийся вам дистрибутив (ubuntu, Fedora, Opensuse, Archlinux). Гипервизор qemu-kvm есть в любом из выше перечисленных дистрибутивов, а гугл пестрит статьями о том, как его поставить.
Переходим к делу. Установку операционной среды описывать я не буду. Оговорюсь лишь, что во время установки операционной среды жесткий диск большего размера не трогал. Его время еще придет. Как установить гипервизор на Debian очень хорошо описано здесь. Лично я ставлю qemu-kvm libvirt-bin.
Гипервизор поставили, теперь немного о внутренней структуре. Есть два каталога, в которые стоит заглянуть:
/etc/libvirt/ — здесь в основном хранятся конфигурационные файлы /var/lib/libvirt/ — здесь будут хранится образы жестких дисков, мгновенные снимки системы и многое другое.
Наш гипервизор установлен.
Теперь немного о настройках. Qemu-kvm не работает напрямую с сетевой картой на физическом компьютере. Следовательно нужно настроить мост. Что делаем:
открываем файл /etc/network/interfaces и приводим его к следующему виду:
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo br0 iface lo inet loopback # Set up interfaces manually, avoiding conflicts with, e.g., network manager iface eth0 inet manual # Bridge setup iface br0 inet static bridge_ports eth0 address ххх.ххх.ххх.ххх broadcast ххх.ххх.ххх.ххх netmask ххх.ххх.ххх.ххх gateway ххх.ххх.ххх.ххх bridge_stp off bridge_fd 0 bridge_maxwait 0
Больше информации здесь.
Далее сохраняем файл и перезагружаем компьютер. О, чудо! Гипервизор установлен! Дальше возникает вопрос: как управлять сервером? Управлять Qemu-kvm можно двумя программами: virt-manager и virtinst.
Virt-manager. Эта программа рассчитана на графический интерфейс. Она поддерживает как удаленное управление виртуальными машинами, так и локальное. Но у нее есть огромный минус — аналогов для windows попросту нет. Как лично я вышел из положения. Установил графическую оболочку LXDE и сервер xrdp, благодаря такому нехитрому набору программ мне не пришлось физически ходить к компьютеру (больно много ему чести). Я просто подключался через стандартный RDP клиент который, есть в windows. Но это дополнительная трата ресурсов компьютера. Если вы установили virt-manager, он автоматически создает: хранилище для образов виртуальных машин по пути /var/lib/libvirt/images виртуальный сетевой интерфейс default. Следовательно подмонтировать жесткий диск с большим объемом нужно в директорию /var/lib/libvirt/images. Virtinst. Это консольная утилита. Никакой графики, сплошная командная строка и экономия системных ресурсов. Если вы решили воспользоваться консольным управлением, то вам придется в вручную создать хранилище образов виртуальных машин. Делается это следующим образом. По ssh подключаемся к серверу. Заходим под пользователем root. Место для хранилища можно выбрать любое:
можно подмонтировать жесткий диск в директорию и указать его в качестве хранилища можно просто устройство выбрать хранилищем.
Меня больше привлек вариант с директорией (проще копировать диски виртуальных машин). Следовательно что я сделал: отформатировал диск 500 гигабайт в формат ext4 (когда доделают btrfs, то лучше пользоваться ней). Создал директорию /etc/libvirt/images и смонтировал его туда. Не забудьте дописать в fstab строчку для автоматического монтирования. После чего в консоли набираем vitsh и жмем Enter. Выглядит это так:
root@kvm:/home/firsachi# virsh Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit
virsh #
Теперь если дать команду help — видим список команд оболочки. Нас интересует, есть ли готовые хранилища. Для этого вводим команду pool-list --all
virsh # pool-list --all — Name State Autostart
Если ввести просто pool-list, то вам будут показаны только активные хранилища, а нужно видеть их все. Создаем пул
virsh # pool-define-as storage dir --target /etc/libvirt/images/
Говорим, что пул запускается автоматически
virsh # pool-autostart storage
Стартуем пул
virsh # pool-start storage
Теперь проверяем
virsh # pool-list –all
Вывод должен быть такой
virsh # pool-list --all Name State Autostart — storage active yes
Немного о командах рекомендую прочитать тут.
Если не создавать хранилище для образов дисков виртуальных машин, то для того, чтобы диски лежали в одном месте, нужно будет указывать полный путь к образу при его создании(много писать), а так образ создастся в указанном пуле или если он у вас единственный, то его имя указывать не обязательно. Конфигурационный файл пула будет лежать в директории /etc/libvirt/storage/ это .xml файлик. Выходим из virsh введя команду exit.
В принципе наш гипервизор установился и его можно использовать. Но есть еще маленькая мелочь, о которой хотелось бы упомянуть. А именно о том, как работает Qemu-kvm.
Запущенная на нем виртуальная машина шлет команды физическому процессору напрямую через загружаемый модуль (kvm-amd или kvm-intel). Это должен быть один из модулей, который соответствует производителю процессора (Intel или AMD).
Этот модуль подгружается во время старта системы. Однако это не мой метод. Я пересобираю ядро системы для того, чтобы встроить нужный модуль (в виде опции при пересборке) непосредственно в ядро. Но это не единственная модернизация, которую я провожу. Кроме этого я делаю следующее:
отключаю поддержку звука (это сервер, а не рабочая станция); не использую протокол IPv6 (в моей сети он не используется); отключаю поддержку сетевых карт wifi, wmax и все что сними связанно.
Не люблю когда лишние функции обременяют ядро лишней нагрузкой.
В сборке собственного ядра мне помогли вот эти статьи первая и вторая.
Забегу немного вперед. Многие люди в интернете жаловались на то, что модель сетевой карты virtio некорректно работает. Этому есть объяснение, и достаточно простое. Драйвера для этого устройства находятся в стадии экспериментальных. Зато virtio storage работают отлично.
Теперь начинаем работать с виртуальными машинами. Создаем нашу первую виртуальную машину:
virt-install --connect qemu:///system \ --name comp1 \ --ram 512 \ --vcpus=1 \ --disk pool=storage,cache=none,size=20, format= qcow2\ --disk /home/firsachi/Winxp.iso,device=cdrom \ --bridge=br0,model=e1000 \ --os-type=windows --os-variant=winxp \ --graphics vnc,port=5901,listen=0.0.0.0
Некоторые детали хочу пояснить:
pool=storage указываем пул, в котором нужно создать диск; cache=none это означает, что отключено кэширование записи на диск. В моем случае это образ img. При включенном кэшировании записи вдвое увеличивается время обращения к диску виртуальной машины; size=20 размер диска в гигабайтах; format= qcow2 это формат образа диска. Как я понял, только он поддерживает снимки системы; model=e1000 модель сетевой гигабитной карты Intel (по умолчанию идет стомегабитный rtl8139); port=5901 порт, на который можно обратиться с помощью Ultra VNC Viewer; listen=0.0.0.0 разрешение подключиться со всех IP (по умолчанию слушает только localhost). Установку можно произвести непосредственно и на устройство. Выглядеть будет так: virt-install --connect qemu:///system \ --name comp1 \ --ram 512 \ --vcpus=1 \ --disk /dev/sdb, format= qcow2\ --disk /home/firsachi/Winxp.iso,device=cdrom \ --bridge=br0,model=e1000 \ --os-type=windows --os-variant=winxp \ --graphics vnc,port=5901,listen=0.0.0.0 Где sdb должен быть заменен на ваше устройство.
Если все прошло успешно, то для подключения к консоли нашей виртуальной машины нужно установить Ultra VNC Viewer к себе на компьютер. В подключении нужно указать IP адрес сервера и порт, или доменное имя сервера и порт. Как происходит установка Windows, надеюсь, знают все.
Теперь о драйверах виртуальных машин. Для установки драйверов нужны следующие образы дисков: virtio-win-0.1-30.iso и viostor-0.1-30-floppy.img Последний диск не обязателен, он нужен только в том случае, если вы собираетесь установить windows xp или windows 2003 server на virtio storage (кстати, если так сделать, то операционная система работает быстрее).
Здесь написано как подключить и отключить cdrom. Есть еще один бонус: к виртуальной машине можно подключить внешние устройства (например физический жесткий диск или usb накопитель). Заходим в virsh. Команда будет выглядеть так: virsh # attach-disk comp1 /dev/sdc vdv --type disk Где:
comp1 – имя виртуального компьютера, к которому подключаем диск. /dev/sdc – путь к устройству на физическом компьютере. Vdv — куда подключаем на виртуальной машине. --type – тип диска.
Отключить диск:
virsh # deatach-disk comp1 vdv
Во многом поможет и вот эта статья. Рекомендую также заглядывать вот сюда.
Где я применяю этот гипервизор? У меня на нем постоянно работает контролер домена. Причем работает стабильно, без сбоев. Авторизация в домене происходит без проблем. Параллельно могу запустить максимум 2 виртуальные машины. Восстановление виртуальной машины на другом сервере. Одним солнечным и безоблачным днем я подумал: а что будет, если придется переносить его на другой сервер. Режим миграции виртуальной машины в гипервизоре есть, но его негде проверить — нет такого второго компьютера. Поэтому пришлось исходить из самого худшего варианта. Предположим:
компьютер, на котором работала виртуальная машина, сгорел (процессор Atlon X2 245). раз в неделю виртуальная машина выключается и делается резервная копия файла конфигурации и образа диска.
Следовательно мои действия на этот случай. Для эксперимента я принес из дому свой ноутбук. На нем стоит процессор i5-3210M, linux дистрибутив OpenSuse (для моего ноутбука больше совместим с «железом»).
Установил на нем Qemu-KVM, переместил на него файл конфигурации виртуальной машины и образ диска. В файле конфигурации отредактировал путь к диску виртуальной машины, перезагрузил ноутбук. И, о чудо! Гипервизор не только увидел мою виртуальную машину, но и запустил ее.
Создание снимков виртуальных машин. Qemu-KVM поддерживает создание снимков виртуальных машин. Приведу самый простой пример. От суперпользователя заходим в virsh и выполняем следующую команду:
virsh # snapshot-create-as name name — это имя виртуальной машины.
После того, как снимок виртуальной машины будет сделан, резервные копии файлов конфигураций будут лежать в директории /var/lib/libvirt/qemu/snapshot/. Но вот где лежат данные диска виртуальной машины — мне пока не известно.
Просмотреть снимки можно следующей командой:
virsh # snapshot-list name Name Creation Time State — 1360593244 2013-02-11 16:34:04 +0200 running 1360594479 2013-02-11 16:54:39 +0200 running
Восстановить из фотографии можно так:
virsh # snapshot-revert name 1360593244
Удалить не нужный снимок можно так:
virsh # snapshot-delete name 1360593244
Вот так теперь и живем: гипервизор Qemu-KVM, виртуальный контролер домена, и довольный проделанной работой я. Спасибо всем, кто дочитал до конца. Надеюсь, мои мысли оказались полезными.