Sorry for the break-in, Just wanted to say good info James! Thanks for sharing that ;) We have been doing a couple of Xen production setups along with heartbeat clustering on SLES 10 SP1 (using fiber and iSCSI SANs). It's working quite nicely and all hosts are running 64bit versions of SLES, one thing I would absolutely recommend. The kernel version thing between paravirtual host & guest is something that was/is not all to clear to me & your post just gave me some new clues! As a side note for VM migration: Once the xen config files are setup for it (e.g. permitting hosts to migrate guest vms to each other) the Linux guests migrate fine. Windows guests (all 32bit) on the other hand give us trouble as instead of migrating the guest gets destroyed on one side and created on the other side (eg hard power of and startup). Not the best way to do things ;) A friend already hinted me to pause and resume the windows guests instead of doing a migration, but still have to sort that out & I read this is a limitation of the xen 3.0.4 version included in SLES 10 SP1. As I understand 3.1+ does not have this windows vm migration issue? So hoping this will be fixed soon with SP2. Cheers, Wj On Mon, 2008-05-19 at 13:11 -0600, Jason Douglas wrote:

...

...

...

On Sun, May 18, 2008 at 10:32 AM, in message <20080518163240.56670@gmx.net>, wrote: I have got one more challenge to master:

As I'm doing clustertest I'm installing the VMs on one host and test them on this host. The

next step is to spread the VMs across to hosts. So I need to migrate on of the DomUs. With VMware I simply copied the VM to the other physical node and started it. I tried the same with the DomU and copied the configfile as well as the Diskfile.

When I try to start the DomU on the other node, I get the error message:

mpiphysicaltest2:~ # /usr/sbin/xm create /etc/xen/vm/test2 -c Using config file "/etc/xen/vm/test2". Error: (2, 'Invalid kernel', 'xc_dom_compat_check: guest type xen-3.0-x86_32 not supported

by xen kernel, sorry\n')

I checked the kernel via 'uname':

stephan@mpiphysicaltest1:~> uname -a Linux mpiphysicaltest1 2.6.22.17-0.1-xen #1 SMP 2008/02/10 20:01:04 UTC i686 i686 i386 GNU/Linux stephan@mpiphysicaltest1:~> uname -r 2.6.22.17-0.1-xen

stephan@mpiphysicaltest2:/usr/lib/xen/boot> uname -a Linux mpiphysicaltest2 2.6.22.17-0.1-xenpae #1 SMP 2008/02/10 20:01:04 UTC i686 i686 i386 GNU/Linux stephan@mpiphysicaltest2:/usr/lib/xen/boot> uname -r 2.6.22.17-0.1-xenpae

On the second node (target node), the kernel seems to have a PAE-extension. Might that hinder the migration? I don't know where it derives from - I installed both kernel from the same CD from scratch...

There are two different 32-bit xen kernels shipped with openSUSE 10.3: kernel-xen and kernel-xenpae. (Note that there are different hypervisor versions that match these kernel versions as well [xen.gz and xen-pae.gz]). These kernels mirror the kernel-smp and kernel-bigsmp that are typical in SuSE distributions, and they are installed automatically based on the amount of memory in your system (basically <= 2GB installs the kernel-xen; > 2G installs the kernel-xenpae). The kernel within the guest* has to match the flavor of the kernel that is running on the host (i.e. if you are running -xenpae, your guest must be running -xenpae).

NOTE: I am only speaking of paravirtualized guests in this case. The kernel in a fully virtualized guest does not need to match the "flavor" of the hypervisor/dom0 kernel with the exception that you have to be running a 64-bit xen in order to run any 64-bit guest.

...

How can I harmonize this??

There are a couple of different approaches that you can take here. One option is to make both hosts run the same flavor of xen. Since there are only a handful of processors newer than the Pentium Pro that do not have PAE support, my recommendation would be to install the kernel-xenpae package into your host that is currently running the -xen kernel. This will automatically create a new entry in your grub menu that will load the right hypervisor as well.

However, if you choose this route, you will want to install the kernel-xenpae kernel into all of your guests BEFORE you move to the xenpae kernel on the host. Otherwise, your VM won't boot on either system and you'll have to use some tricks to install the correct kernel in the vm (read "Requires you to be somewhat of a Linux expert"). You'll also need to change your config file to point at the -xenpae kernel, but I'll explain that in a moment.

This leads me to the second option which is to install BOTH kernels in your VM. That way, by changing a single line in your vm config file, you'll be able to boot the VM on either machine without changing the hypervisor that is currently running. The line that you'll need to change is the one that references /boot/kernel-xen and /boot/initrd-xen (I believe it is the bootargs line, but without looking at your config file, I can't be sure). Once you have installed the kernel-xenpae package into the guest, you can copy it to the PAE host and change those entries to -xenpae. If you have problems with this, attach your vm config file and any error messages, and I'll take a look.

Have a lot of fun!

Jason

P.S. If you are interested in actual VM migration (movement of the VM while it is still running), you'll need to have both hosts running the same flavor of xen, and you'll need the VM disk to be accessible to both machines in the exact same way (i.e. iscsi target, nfs mount, or other). But for now, this should be plenty to get you started. Good luck!

-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-virtual+help@opensuse.org