On Tue, Jan 06, 2015 at 12:15:25AM +0200, Pasi Kärkkäinen wrote: > On Tue, Dec 16, 2014 at 10:29:53PM +0200, Pasi Kärkkäinen wrote: > > > > > > * xend is now disabled by default. You can enable it by running > > > chkconfig. xend has been removed from the tree entirely in Xen 4.5, > > > so this should (hopefully) serve as a "wake-up-call" for people to > > > begin the transition over to xend. > > > > > > * A lot have things have changed -- please to test this so we can get > > > a good idea what may have broken. > > > > > > > I'll test soon. Thanks a lot! > > > > > Ok I just used a couple of hours testing Xen 4.4.1 rpms on CentOS 6.6 with Linux 3.10 dom0 kernel. > This session was all about xm/xend testing. I manually enabled xend first. > > > What Works OK: > - Manually creating/managing guests with xm and domU cfgfiles in /etc/xen and LVM volumes as storage (phy backend). > - Manually creating/managing guests with xm and domU cfgfiles in /etc/xen and file images as storage (tap2:aio backend). > - Using virt-install to install PV domUs using LVM volumes as storage (phy backend). > - Using virt-manager to install PV domUs using LVM volumes as storage (phy backend). > > What doesn't work: > - Using virt-manager to install PV domUs using file images as storage (tap:aio backend). > Oh, and obviously "virt-install" fails aswell when trying to use file images, same problem as with virt-manager. Here's the virt-install commandline example you can use for testing: virt-install -d -n blktaptest01 -r 2048 --vcpus=2 --disk /var/lib/libvirt/images/blktaptest01.img,size=8 --vnc -p -b virbr0 -l "http://ftp.funet.fi/pub/mirrors/centos.org/6.6/os/x86_64" obviously you need to have a working libvirt-setup before running that command, and the libvirt/dnsmasq virbr0 bridge as created by libvirtd: - yum install libvirt libvirt-daemon libvirt-daemon-network libvirt-driver-network libvirt-driver-xen virt-install virt-viewer virt-manager python-virtinst xorg-x11-xauth - service xend restart - service libvirtd restart > > This libvirt/blktap2 file images failure with Xen 4.4 rpms is a regression from Xen 4.2 rpms, where blktap2 works OK with libvirt/virt-install/virt-manager. > > The problem is most probably the fact that we had custom patches included in the xen4c6 libvirt rpms that we shipped with the Xen 4.2 rpms. > We had to add two patches, one patch to fix the blktap2 backend type in libvirt, and one patch to fix the blktap2 backend type in virt-install or virt-manager, i'm not totally sure which one it was. Those patches should be included in the earlier libvirt source rpms, so we can check there. Or I can search thru my emails, because I hunted that down earlier aswell. > > It seems we still need those patches with the latest libvirt rpms too. > > The actual problem is libvirt/virt-manager tries to configure tap:aio: backend, which won't work. > It needs to be tap2:aio. > > I get the exactly same behaviour with xm/xend. "tap:aio" stalls and fails. "tap2:aio" works OK. > Ok so digging into the email archives it seems earlier we patched python-virtinst src.rpm, which seems to be the component used by both virt-install and virt-manager for new domain installations. So we need to modify the virtinst/VirtualDisk.py file and change the: DRIVER_TAP = "tap" to DRIVER_TAP = "tap2" To change the default. After that change the libvirt generated domain xml looks like this, from both virt-install and virt-manager and works OK: <disk type='file' device='disk'> <driver name='tap2' type='aio'/> <source file='/var/lib/libvirt/images/blktaptest01.img'/> <target dev='xvda' bus='xen'/> </disk> (virsh dumpxml <domain>) -- Pasi