Системе виртуализации «Proxmox» на Хабре посвещено несколько постов, и, конечно, прежде, чем писать этот пост мне довелось их изучить для собственного эксперимента. Мое исследование сводилось к установке Proxmox 3.1 на «голое железо», его настройке и переносе существующих виртуальных машин с VMWare на новую систему. Установка ОС производилась, как следует из названия поста, с дистрибутива Proxmox 3.1, «как есть». В процессе инсталляции, настройки и импорта виртуальных машин возникли интересные моменты, с которыми я и хотел бы поделиться с сообществом.
После инсталляции ОС с диска происходит перезагрузка и первый пуск Proxmox, в этот момент выводится сообщение «GRUB LOADING..» и запуск замирает.
Проблема «GRUB LOADING..» связана с 2-мя факторами, которые следует учесть при инсталляции proxmox:
После создания в веб интерфейсе контейнера возникает проблема с настройкой сети. При настройке возможно указать ip адрес, однако это будет виртуальный NAT, т.е. доступ в контейнер возможен с vhost, но не из всей сети. Для того чтобы контейнер был доступен из всей сети, необходимо настроить ethernet (eth0). На этапе установки eth0 также можно сконфигурировать, но ip адрес назначен не будет. Причем в самом контейнере eth0 отсутствует (команда ifconfig его не показывает). Вот здесь и возникает проблема: как настроить интерфейс «мост».
Согласно материалам по настройке сетей OpenVZ, необходимо сделать следующее: войти в контейнер («100» — id контейнера)
в системе контейнера определить интерфейс eth0 (без этого шага следующий шаг будет действителен до перезагрузки контейнера)
затем сконфигурировать интерфейс eth0
или на постоянно внести в /etc/network/interfaces
Процедура сжатия для дисков vmdk, на мой взгляд, очень важна, т.к. объем физического диска всегда ограничен.
Процедура восстановления виртуальной гостевой системы в Proxmox посредством веб-интерфейса хорошо знакома, однако, как это происходит в консоли не понятно. Гостевые системы (речь о KVM) бэкапятся в файл vzdump-qemu-id-date-time.vma.gz. Это архив предварительно упакованного виртуального диска и файла конфигурации гостевой ОС.
Логично сначала достать файл .vma:
где 103 — номер гостевой системы в Proxmox
Далее необходимо распокавать файл vzdump-qemu-103-date-time.vma. Для этого в Proxmox 3.1 существует специальная утилита vma
Примечание: команда сработает без ошибок, если в каталоге /var не создавать предварительно каталог «103». В итоге в /var/103/ будет пара файлов:
Примечание: если мы восстанавливали гостевую систему с диском vmdk, то восстановленный диск будет в формате «raw». Исправить это можно, осуществив конвертирование в нужный формат:
«Правильное выключение ОС» для гостевых систем Proxmox (KVM) означает имитация события «нажатия кнопки выключения системы на физической машине». Такое отключение срабатывает корректно в unix-системах. Это достигается командой в QEMU:
Однако, в гостевых Windows системах в фоне команда возвращает ошибку и система не выключается. Отключение происходит «правильно» только в случае успешного входа в систему, либо «принудительно» (событие «отключение кабеля питания») — другой командой (qm stop 103). Исправить данную ситуацию возможно, скорректировав локальную политику гостевой Windows ОС:
Пуск — Панель управления — Администрирование — Локальная политика безопасности — Параметры безопасности — Локальные политики — Параметры безопасности — Завершение работы: разрешить завершение работы системы без выполнения входа в систему («Включить»)
Момент первый: Установка системы и сообщение «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.rawqemu-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 ОС:
Пуск — Панель управления — Администрирование — Локальная политика безопасности — Параметры безопасности — Локальные политики — Параметры безопасности — Завершение работы: разрешить завершение работы системы без выполнения входа в систему («Включить»)
