Op maandag 11 april 2011 10:33:30 schreef Thomas Backlund: > Hi, > > xen-4.1.0-1.mga1 is now avaliable in the repos. > > And as of kernel-2.6.38.2-4.mga1 there has been some cleanups and addons > for xen: > > There is now a kernel-xen-pvops that also should work as dom0. > > Now this is mostly upstream kenel.org code so its not as fully > featured as the old kernel-xen. You can see the features listed here: > http://wiki.xensource.com/xenwiki/XenParavirtOps. > > There is one exception: our 2.6.38 kernel has xen-netback backend driver > added. > > So those of you that have been using xen, please test atleast the > following: > > - check that kernel-server still works as a xen guest > - try to use kernel-xen-pvops as dom0 and see how it works > (you can also try to use kernel-xen-pvops as a normal xen guest) > > Have fun... > > -- > Thomas
i don't know how much people have been testing, but... dom0 xen didn't work with .xz kernels, i put in a patch for that, and now it works. in a kvm guest, i've got a working xen dom0 host, but the libvirtd implementation seems unable to find the cpu architecture, and if i force to be the same as the host, i am unable to boot the dom0 anymore. (i think this is likely due to the nature of a KVM guest not really being suitable for a XEN dom0). i've tried a physical server, but when i finally got to the point of libvirtd, it seemed to not bootup anymore (it was an old disk, which i thought got broken, seeing the IO errors) I put in a new disk, only to note that the X2 suddenly only had 1 core, which i found very odd, and i noticed the IO errors before (and also now) were really sata bus errors... (and if i remember correctly this machine had been used with a semi-exploding PowerSupply)... so i think this mobo/cpu is fried... now i need to find new hardware to restart testing again :-( . note that allthough i can have everything running, i never tested with actual guests, let alone online migrations... however, i did find out that this xenpvops has 2 different toolchains: xm and xl. xl seems to do pretty much the same, but apparently doesn't require xend to be running (it reacts directly to the kernel/hypervisor?) also the xencommons init script seems to start xenconsoled and xenstored on it's own. i'm thinking of removing both those init scripts and having xend not start as default. (allthough i don't know about xendomains). i'll keep you guys posted.