Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
Are you opposed to building Xen from source, or using the official release tarballs? I know its a tricky question. –  Tim Post May 2 '09 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. –  John McAleely May 2 '09 at 22:52
add comment

3 Answers

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.

share|improve this answer
    
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? –  John McAleely Apr 30 '09 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 '09 at 0:24
add comment

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.

share|improve this answer
add comment

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
share|improve this answer
    
did you observe dist-upgrade migrating xen from 3.0 to 3.2 on your setup? That is not what happened for me :-( –  John McAleely May 29 '09 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 '09 at 16:29
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.