Установка Fedora 16 в качестве полнофункциональной PV-guest системы в XenServer

В этой заметке хотелось бы рассказать, как можно установить Fedora 16 в качестве PV-гостевой машины в XenServer/Xen Cloud Platform. В принципе, описанный ниже способ установки не поддерживаемых напрямую дистрибутивов хорошо известен, однако при установке Fedora 16 возник ряд затруднений, с которыми пришлось немного повозиться. Готовое решение под катом.

Шаг 1. Установка HVM

Так как в XenServer нет теплейтов для Fedora, мы начинаем установку с создания абстрактной HVM-машины из теплейта ”Other install media”. Здесь все стандартно, задаем память, сеть, создаем диск, присоединяем образ с дистрибутивом, запускаем. На первом же появивщемся экране (Install or update...) нажимаем клавишу Tab и добавляем в командную строку загрузки ядра параметр nogpt. Иначе установщик разметит диск под gpt и в дальнейшем PV-загрузчик pygrub не сможет найти ядро и рамдиск установленной системы.

Момент номер 2. По умолчанию, установщик создает раздел /boot в формате ext4, что опять же недоступно пониманию pygrub. Поэтому не забываем указать, что /boot необходимо отформатировать в ext2

В остальном настраиваем систему по своему вкусу.

Шаг 2. Переделываем HVM в PV

Перед тем, как изменить параметры запуска машины, необходимо внести пару изменений в grub:

1. Традиционно, файл настроек grub.cfg находится в каталоге /boot/grub. Однако в Fedora 16 grub переехал в каталог /boot/grub2, и соотвктственно pygrub не может его найти. Чтобы это преодолеть делам линк:
   [root@localhost ~]# ln /boot/grub2/grub.cfg /boot/grub
   
2. Несмотря на то, что pygrub в целом понимает формат grub2, некоторые конструкции приводят к его краху с весьма невнятными сообщениями. Конкретно в данном случае pygrub взрывается, встретив такую строчку в grub.cfg:
   set default="${saved_entry}"
   меняем ее на
   set default=0
   

Все, теперь можно со спокойной совестью менять параметры машины:
[root@xcp01 bin]# xe vm-list name-label=f16
uuid ( RO) : da8d401c-93b9-67a5-5275-39c6f76e67c9
name-label ( RW): f16
power-state ( RO): halted

[root@xcp01 bin]# xe vm-param-set uuid=da8d401c-93b9-67a5-5275-39c6f76e67c9 HVM-boot-policy=""
[root@xcp01 bin]# xe vm-param-set uuid=da8d401c-93b9-67a5-5275-39c6f76e67c9 PV-bootloader=pygrub
[root@xcp01 bin]# xe vm-disk-list uuid=da8d401c-93b9-67a5-5275-39c6f76e67c9
Disk 0 VBD:
uuid ( RO) : 37301b8f-c490-c1b3-ee11-09ea749289af
vm-name-label ( RO): f16
userdevice ( RW): 0

Disk 0 VDI:
uuid ( RO) : 8259df56-47d2-494d-a1a8-437ce5388cf5
name-label ( RW): f16
sr-name-label ( RO): NetApp XCP NFS
virtual-size ( RO): 32212254720

[root@xcp01 bin]# xe vbd-param-set uuid=37301b8f-c490-c1b3-ee11-09ea749289af bootable=true
[root@xcp01 bin]# xe vm-start uuid=da8d401c-93b9-67a5-5275-39c6f76e67c9
[root@xcp01 bin]#

Убеждаемся, что все нормально работает, устанавливаем XS Tools и получаем полноценную виртуалку со всеми вкусностями в виде live snapshots, live migration и прочая.

P.S.

1. Чтобы set default не вылезал в будущем, нужно поправить файл /etc/grub.d/00_header
2. Аналогичная проблема вылезла при апгрейде Ubuntu 10.10 В Ubuntu 11.04, но там pygrub ломался на обработке submenu в grub.cfg. Я у себя просто вырезал генерацию submenu из скриптов /etc/grub.d