On Tue, Sep 29, 2015 at 12:37:25PM +0100, George Dunlap wrote: > On Sat, Sep 26, 2015 at 9:29 PM, Pasi Kärkkäinen <pasik at iki.fi> wrote: > > On Sat, Sep 26, 2015 at 09:04:23PM +0300, Pasi Kärkkäinen wrote: > >> Hello, > >> > >> I just upgraded some of my el6xen boxes to latest CentOS 6.7, Xen 4.4.3 and dom0 3.18.17 rpms, and noticed these new problems: > >> > > > > And third issue aswell: > > > > 3) Creating an HVM guest using virt-manager with file-based storage uses loopback-mount, not blktap > > > > When I manually create a new Xen HVM guest using virt-manager, and choose file-based image for storage of the VM, it seems to be set up to use file: backend/driver with loopback-mounted image file: > > > > <disk type='file' device='disk'> > > <driver name='file'/> > > <source file='/var/lib/libvirt/images/testvm2.img'/> > > <backingStore/> > > <target dev='hda' bus='ide'/> > > </disk> > > > > # losetup -a > > /dev/loop0: [fd00]:1709109 (/var/lib/libvirt/images/testvm2.img) > > > > With earlier versions of rpms similar setup used blktap2 backend.. (and yes, I do have blktap module loaded in dom0 kernel). > > I remember having to patch some dependency of virt-manager to give it > the correct default driver name (something like, it got 'tap' but > needed to be 'tap2'). In all likelihood, someone has sussed that > 'tap' doesn't work and just replaced it with 'file'. Actually, it's > fairly likely if they've updated stuff in CentOS that you're not > getting the re-build virt-manager stuff either -- I may have to respin > that one as well. > I think it's specified at least in python-virtinst. See these emails from a few years back about the tap/tap2-issue: https://www.redhat.com/archives/virt-tools-list/2013-June/msg00037.html https://www.redhat.com/archives/virt-tools-list/2013-June/msg00039.html > While we're here, could you give me a couple of virt-install and > virt-viewer "smoketest" commands that I could add to my automated test > scripts? ATM I'm testing libvirt by using virsh to import an xl .cfg > file, but it would be better to have something that created the config > end-to-end. Using virt-manager directly is probably more work than > I'm up for in most cases, but hopefully if I can test the things it > depends on I can notice this sort of breakage. > The problem with virt-viewer issue is that it gives the "error popup" in the GUI, so there's no way to figure out it didn't work without looking at the GUI and interacting with the gui.. Not easy to script/automate.. > Thanks, > -George -- Pasi