4

I manage a server that currently runs Debian/Etch, and Xen 3.0. Each virtual machine is also running Debian/Etch.

Lenny is the next release of Debian, and includes Xen 3.2. Unfortunately, I believe there is no automatic upgrade path (via dist-upgrade) between Xen 3.0 and Xen 3.2. (Xen 3.0 is listed as an obsolete package in the lenny release notes).

What steps should I follow to end up with the server running lenny/xen3.2 and the virtual machines running lenny?

2
  • Are you opposed to building Xen from source, or using the official release tarballs? I know its a tricky question.
    – Tim Post
    May 2, 2009 at 19:29
  • 1
    I want to use official debian packages, so I can benefit from debians general security update management, etc. So yes, I am opposed to building Xen from source. May 2, 2009 at 22:52

3 Answers 3

1

I was able to migrate a Debian Etch/Xen 3.0 server to Lenny/Xen 3.2 using dist-upgrade. All apt-get did was download the appropriate packages and install them. After making sure the grub config is correct and will be booting 3.2 all of my paravirtual machines booted up. All of the PV machines are Gentoo so I can't comment on the client upgrade for Debian but it shouldn't be that difficult. I did have some issues with an HVM machine and had to rebuild it.

2
  • On my etch setup, the apt-get dist-upgrade did not touch xen, leaving 3.0 in the lenny image. Unfortunately, xen 3.0 was dependent on python 2.4, and lenny replaces this with 2.5. This resulted in machine that could no longer boot any xen vms. The issue appears to be a problem for many folks on the interweb. I wonder why it did not impact your configuration? Apr 30, 2009 at 14:40
  • Lenny still has python 2.4, it's just no longer the default. Install xen 3.2 package by hand and remove the 3.0 ones.
    – womble
    May 3, 2009 at 0:24
1

I find changing Xen packages on the fly extremely risky. Since this is virtualization, you should build a new lenny Xen 3.2 server (or maybe 3.3 or 3.4 from source since it's out), do a migration test with a copy of your actual domains and then update your actual server to see if it works. This allows you to be on the safe side of things and avoid a potential server crash/reinstallation/downtime.

I have had several bad experiences so I tend to try to avoid these updates unless really necessary.

1

I have performed the same upgrade, and have taken some notes:

Start with the guests:

  • dist-upgrade
  • Install packages. Some scripts I used had removed udev, so had to reinstall it.

    aptitude install udev linux-modules-2.6-xen-amd64

  • Add the following to /etc/inittab, otherwise you lose your xm console option (Then no ssh means no access without manual mount & modify)

    0:2345:respawn:/sbin/getty 38400 hvc0

I shut down guests at this stage, until dom0 reboot. This may not be suitable for all, but I do to be on the safe side.

Continue with host:

  • dist-upgrade
  • Have all relevant packages installed, make sure xen package versions are all 3.2

    aptitude install xen-utils bridge-utils xen-hypervisor linux-image-xen-amd64 linux-modules-xen-amd64

  • Check grub menu.lst

  • Check domU configs and update them with new kernel
  • Reboot
2
  • did you observe dist-upgrade migrating xen from 3.0 to 3.2 on your setup? That is not what happened for me :-( May 29, 2009 at 10:19
  • I guess the lack of metapackages(xen-hypervisor etc.) prevented that upgrade, so the second step in the upgrade of dom0 takes care of it.
    – hayalci
    May 29, 2009 at 16:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .