xen 4 on debian squeeze

It's time to upgrade my xen servers to squeeze. I've already put this off too long and now I've to task to go from etch to squeeze in one long step. In order to avoid problems I just did a first upgrade etch -> lenny and then to squeeze. However, since so much has changed in the meantime, and so much twicking of essential components is needed (such as Xen !), I guess I could have gone directly from etch to squeeze in one go, and fix everthing in the process... Anyway, to late for this kind of considerations.

 
The xen debian wiki is full of invaluable information. Kudos to the xen team for their hard work. To get you started on squeeze you need to install the xen hypervisor. Everything is provided by one package:
aptitude install xen-linux-system-2.6-xen-amd64 xen-hypervisor-4.0-amd64

This will pull the latest linux kernel and xen-hypervisor to run on dom0 .

By default the hypervisor is probably not going to be the default kernel. If you want to change this, you should edit the grub default values :

vi /etc/default/grub

to make sure that the default kernel on dom0 is the xen-hypervisor. This is tricky, because grub let you define a default w.r.t the list of available kernels. so if you install a new kernel, you have to change the default accordingly with the list of kernels in /boot/grub/grub.cfg. It would be nice if I could define the default kernel with a label instead of a number... ( ref #505517 )

Alternatively, as suggested in the wiki, you can just move the xen kernel out of the way ...

mv -i /etc/grub.d/10_linux /etc/grub.d/50_linux

When installing xen related tools, aptitude will also probably install by default rinse and xenwatch. The first one is to boostrap redhat machines and maybe you don't need it. The second one is a GUI and will pull in a lot of X-related dependencies. If we have similar needs, you can just remove what is not needed...

aptitude purge rinse rpm rpm-common
aptitude purge xenwatch

Something that is new, is the new schema for virtual devices. Now all vms will see /dev/xdva1 instead of /dev/sda1 as before. This needs to be changed in the domU as well as in the xen config files (/etc/xen/vm.cfg).

One fantastic news is that xen 4 now uses pyGrub. It is not mandatory (so if you want, you can stick with the old configuration file). But if you use pygrub, on the domU you can install whatever kernel you want. Finally, your users will have complete freedom to pick and choose their kernels !

There was a small detail I didn't notice on the debian wiki, that is, if you try to use grub2 in squeeze, it will fail when probing the device#601974 . The workaround described in the wiki is to use xvd{a,b,c,...} as device names (and not xvd{1,2,3,...}) to make grub happy. Once you have changed then naming schema, grub will be able to see the disks and install the bootloader. Another solution is to install the os-prober from unstable / experimental. It seems a patch is on the works.

On newly created images, you can also pass the --scsi parameter to xen-create-image to ignore this problem altogeher... I'm not sure if this will have other implications...

 
The console name is also changes from tty to xhv0 . To get back the console you should add this line in the inittab of all you VMs.
vc:2345:respawn:/sbin/getty 38400 hvc0

A last note is about the merge upstream of the xen patch !! \o/ yeiiii !!

Average: 1 (54 votes)

Comments

Hi Pietro, That's a good

Hi Pietro,

That's a good article of yours.

It seems like you've managed to upgrade Xen-3 to Xen-4 on Squeeze without having to modify domUs.

I'm struggling to do the same but facing same messages over and over. Device XXXX (vbd) could not be connected. Hotplug scripts not working.

Would you happen to have had such errors and tackled them?

Many thanks in advance!

Very helpful ! But, there

Very helpful !

But, there are some other issues.

Where is "xenkopt" in Grub2 ???

Where is "clock source" ? https://wiki.umiacs.umd.edu/VirtualMeshTest/index.php/Xen_clock_sync_issues

LVM crash: http://help.lockergnome.com/linux/Bug-614400-linux-image-32-xen-amd64-Kernel-Crash-initiating--ftopict533036.html

Without "pygrub", I can't boot any DomU. "Grub2" bug again?

Bye

uhmmm I did not encounter

uhmmm I did not encounter (yet!) any of these problems. All my VMs use ntp to keep their clock syncronized and for the moment I didn't have any problems with lvm. But thanks for pointing these out as I'm going to upgrade my SAN next week and I hope that the lvm bug won't hit me.

Reg pygrub. I managed to boot all my vm **without** pygrub. You just need to specify a kernel that is in your dom0 and copy the modules for this kernel in the vm. This is how it works with xen 3.x ... and as far as I can see it works the same with xen 4