Системе виртуализации «Proxmox» на Хабре посвещено несколько постов, и, конечно, прежде, чем писать этот пост мне довелось их изучить для собственного эксперимента. Мое исследование сводилось к установке Proxmox 3.1 на «голое железо», его настройке и переносе существующих виртуальных машин с VMWare на новую систему. Установка ОС производилась, как следует из названия поста, с дистрибутива Proxmox 3.1, «как есть». В процессе инсталляции, настройки и импорта виртуальных машин возникли интересные моменты, с которыми я и хотел бы поделиться с сообществом.
Момент первый: Установка системы и сообщение «GRUB LOADING...»
После инсталляции ОС с диска происходит перезагрузка и первый пуск Proxmox, в этот момент выводится сообщение «GRUB LOADING..» и запуск замирает.
Проблема «GRUB LOADING..» связана с 2-мя факторами, которые следует учесть при инсталляции proxmox:
- жесткий диск, на который производится установка ос, при запуске должен быть всегда первым (к сожалению, соответствующая установка опции порядка загрузки в BIOS не дает должного результата, парадокс, но необходимо найти искомый sata0 порт и загружать систему в правильной конфигурации)
- привод всегда должен быть подключен (без привода будем наблюдать «GRUB LOADING..», очевидно, устройство привода фигурирует в скриптах запуска)
Момент второй: Настройка сети в контейнере openvz (proxmox) или активация интерфейса типа bridge
После создания в веб интерфейсе контейнера возникает проблема с настройкой сети. При настройке возможно указать ip адрес, однако это будет виртуальный NAT, т.е. доступ в контейнер возможен с vhost, но не из всей сети. Для того чтобы контейнер был доступен из всей сети, необходимо настроить ethernet (eth0). На этапе установки eth0 также можно сконфигурировать, но ip адрес назначен не будет. Причем в самом контейнере eth0 отсутствует (команда ifconfig его не показывает). Вот здесь и возникает проблема: как настроить интерфейс «мост».
Согласно материалам по настройке сетей OpenVZ, необходимо сделать следующее: войти в контейнер («100» — id контейнера)
vzctr enter 100
в системе контейнера определить интерфейс eth0 (без этого шага следующий шаг будет действителен до перезагрузки контейнера)
ifconfig eth0 0
затем сконфигурировать интерфейс eth0
ifconfig eth0 192.168.XXX.XXX netmask 255.255.255.0 ip route add 192.168.XXX.YYY dev eth0 ip route add default via 192.168.XXX.YYY
или на постоянно внести в /etc/network/interfaces
auto eth0 iface eth0 inet static address 192.168.XXX.XXX netmask 255.255.255.0 gateway 192.168.XXX.YYY
Момент третий: Импорт виртуальных машин VMWare в KVM Proxmox
- Импорт freebsd.vmdk
Перед импортом существующей виртуальной машины VMWare с FreeBSD необходимо создать ее прототип на Proxmox KVM с теми же самыми параметрами, выбрав формат диска «vmdk», тип IDE. После создания прототипа копируем диск «freebsd.vmdk» в /var/lib/vz/images/id/, переименовываем его (присваивая имя созданного диска) и запускаем виртуальную машину. Если загрузка заканчивается поиском корневого раздела, то в привод машины загружаем диск frenzy и повторяем запуск с live-cd в режиме hdrw (запись на диск). Смотрим смонтированные слайсы df -h, находим маркировку диска (ad или da), редактируем файл /etc/fstab, меняя маркировку диска на полученную в предыдущей команде. После удачной загрузки ОС нужно будет отредактировать и сетевой интерфейс. - Импорт windows.vmdk
Необходимо предварительно загрузить импортируемую виртуальную машину VMWare на родном ПО, затем в загруженной машине добавить в реестр информацию о драйверах IDE ссылка, скопировать pciide.sys в %SystemRoot%System32/Drivers. Деинсталлировать из виртуальной системы VMWare Tools, отключить виртуальную машину и скопировать файл виртуального диска vmdk в Proxmox (KVM). Загрузить виртуальную систему с импортированным диском (тип IDE).
Момент четвертый: Сжатие виртуальных дисков формата VMDK в Proxmox
Процедура сжатия для дисков vmdk, на мой взгляд, очень важна, т.к. объем физического диска всегда ограничен.
- Сжатие WINDOWS.vmdk
Сжатие виртуальных дисков связано с эффектом «раздувания» файла vmdk (увеличение размера файла) при работе гостевой виртуальной системы. Для сжатия виртуального диска формата VMDK с ОС MS Windows можно воспользоваться парой утилит от VMWare: vmware-mount и vmware-vmdiskmanager — в составе пакета VDDK, можно скачать с оф. сайта. Т.к. Proxmox работает на Debian, то скачиваем linux64 архив и устанавливаем:
tar -xzf VMware-vix-disklib-5.1.0-774844.x86_64.tar.gz
cd ./vmware-vix-disklib-distrib
./vmware-install.pl
После установки необходимо добавить строку в /etc/ld.so.conf:
/usr/lib/vmware-vix-disklib/lib64
Далее утилиты готовы к работе с дисками. Выключаем гостевую виртуальную систему, диск которой будет подвержен сжатию. Процедура сжатия vmdk-диска состоит из трех фаз:- дефрагментация диска vmdk
vmware-vdiskmanager -d /path/to/name.vmdk - подготовка к сжатию диска
vmware-mount /path/to/name.vmdk /mnt/vmdk/
если на этапе монтирования возникает ошибка о неизвестной файловой системе NTFS, необходимо загрузить поддержку данной системы в Debian:
apt-get install ntfs-3g
vmware-vdiskmanager -p /mnt/vmdk/ - сжатие диска
vmware-mount -x # отмонтирование vmdk носителя
losetup -d /dev/loop0 # в случае ошибки при выполнении первой команды: "device is busy"
vmware-mount -x # и повтор команды
vmware-vdiskmanager -k /path/to/name.vmdk # команда сжатия диска
Эффект сжатия диска vmdk — до истинного размера диска в гостевой виртуальной системе.
- дефрагментация диска vmdk
- Сжатие FREEBSD.vmdk
Для сжатия виртуального диска с ОС FREEBSD указанные выше утилиты не подойдут, т.к. возникает проблема монтирования vmdk-диска в хостовую систему: Debian не знает файловой системы UFS. Однако, выход существует, можно воспользоваться встроенными возможностями FreeBSD: создать дампы файловой системы исходной гостевой ОС и восстановить их на вновь созданный виртуальный диск, а затем поменять диски — процедура переноса freeBSD на новый hdd.
Момент пятый: Восстановление виртуальной гостевой системы в Proxmox через консоль
Процедура восстановления виртуальной гостевой системы в Proxmox посредством веб-интерфейса хорошо знакома, однако, как это происходит в консоли не понятно. Гостевые системы (речь о KVM) бэкапятся в файл vzdump-qemu-id-date-time.vma.gz. Это архив предварительно упакованного виртуального диска и файла конфигурации гостевой ОС.
Логично сначала достать файл .vma:
gzip -d vzdump-qemu-103-date-time.vma.gz
где 103 — номер гостевой системы в Proxmox
Далее необходимо распокавать файл vzdump-qemu-103-date-time.vma. Для этого в Proxmox 3.1 существует специальная утилита vma
vma extract vzdump-qemu-103-date-time.vma /var/103
Примечание: команда сработает без ошибок, если в каталоге /var не создавать предварительно каталог «103». В итоге в /var/103/ будет пара файлов:
vm-103-disk-1.raw
qemu-server.conf
Примечание: если мы восстанавливали гостевую систему с диском vmdk, то восстановленный диск будет в формате «raw». Исправить это можно, осуществив конвертирование в нужный формат:
qemu-img -f raw -O vmdk vm-103-disk-1.raw vm-103-disk-1.vmdk
Момент шестой: Правильное выключение гостевой Windows на Proxmox (KVM)
«Правильное выключение ОС» для гостевых систем Proxmox (KVM) означает имитация события «нажатия кнопки выключения системы на физической машине». Такое отключение срабатывает корректно в unix-системах. Это достигается командой в QEMU:
qm shutdown 103
Однако, в гостевых Windows системах в фоне команда возвращает ошибку и система не выключается. Отключение происходит «правильно» только в случае успешного входа в систему, либо «принудительно» (событие «отключение кабеля питания») — другой командой (qm stop 103). Исправить данную ситуацию возможно, скорректировав локальную политику гостевой Windows ОС:
Пуск — Панель управления — Администрирование — Локальная политика безопасности — Параметры безопасности — Локальные политики — Параметры безопасности — Завершение работы: разрешить завершение работы системы без выполнения входа в систему («Включить»)
Автор: bogdanov_go
