Martin Tröster
2009-Feb-02 19:07 UTC
[Xen-devel] FW: Xen 3.3.0 - QEMU COW disk image with sparse backing file - VM fails to start
Hi, I posted my problem to start QCOW based disk images on Xen 3.3 below at xen-users already, but as I did not get any responses yet, I directly contacted K. Wolf (as a frequent contributor in the QEMU Xen code). He suggested to post my problem here at xen-devel. Please see the quoted mail below for a detailled description on how my problem occurs. Furthermore, Kevin pointed me to this patch on Xen-changelog, which probably introduced the problem I am seeing: http://lists.xensource.com/archives/html/xen-changelog/2008-10/msg00132.html WIth help of this information, I probably might have a try to undo the changes in a private Xen build, but this does not sound like a good long-term option, especially for somebody not too deep into Xen/Qemu development... Therefore, let me kindly ask why it is considered to "handle QCOW backing files correctly" now? The patch, in my eyes, allows to use a raw file as backing file, but breaks the use of a QCOW file (sparse file, in my setup) as a backing file. In my setup, this breaks the use of all current QCOW-files I am running when migrating from Xen-3.2 to Xen-3.3. Although I cannot easily provide a fix by myself, I''d really like to have an approach both allowing to use QCOW- _and_ raw images as backing builds. Any help here is appreciated. Thanks! Cheers, Martin> -----Ursprüngliche Nachricht----- > Von: "Martin Tröster" <TroyMcClure@web.de> > Gesendet: 20.01.09 16:22:12 > An: xen-users@lists.xensource.com > Betreff: Xen 3.3.0 - QEMU COW disk image with sparse backing file - VM fails to start> Hi, > > I upgraded my Xen 3.2-based test system to Xen 3.3. With this installation, I am no longer able to start images with COW disk images based on qcow sparse files. Starting the DomU via xm create gives success status (with "Startig Domain test" message printed to console), but xm list directly afterwards shows no entry for the VM. > > The image structure is: > Base File A.img (sparse QCOW2 file) > COW File B.img (QCOW2 file with A.img as backing file) used as disk in Xen config file (see VM config file below) > > I am running a CentOS 5.2 server with the pre-build packages at http://www.gitco.de/repro and can repro this behaviour on both 3.3.0 and 3.3.1RC1_pre (no 3.3.1 final version available, no time yet to do a build on my own). > > In detail, I see the following behaviour: > -> RAW image with disk using file:/ - works > -> QCOW sparse image using tap:qcow - works > -> QCOW image based on RAW image using tap:qcow - works > -> QCOW image based on QCOW sparse image using tap:qcow - fails. > > Logs of failing case: > ============================> /var/log/xen/xend.log shows that the domain immediately terminates, but no ERROR indication: > [2009-01-20 09:13:55 20596] DEBUG (XendDomainInfo:1443) XendDomainInfo.handleShutdownWatch > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices vif. > [2009-01-20 09:13:55 20596] DEBUG (DevController:160) Waiting for 0. > [2009-01-20 09:13:55 20596] DEBUG (DevController:645) hotplugStatusCallback /local/domain/0/backend/vif/8/0/hotplug-status. > [2009-01-20 09:13:55 20596] DEBUG (DevController:645) hotplugStatusCallback /local/domain/0/backend/vif/8/0/hotplug-status. > [2009-01-20 09:13:55 20596] DEBUG (DevController:659) hotplugStatusCallback 1. > [2009-01-20 09:13:55 20596] DEBUG (DevController:160) Waiting for 1. > [2009-01-20 09:13:55 20596] DEBUG (DevController:645) hotplugStatusCallback /local/domain/0/backend/vif/8/1/hotplug-status. > [2009-01-20 09:13:55 20596] DEBUG (DevController:659) hotplugStatusCallback 1. > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices vscsi. > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices vbd. > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices irq. > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices vkbd. > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices vfb. > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices console. > [2009-01-20 09:13:55 20596] DEBUG (DevController:160) Waiting for 0. > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices pci. > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices ioports. > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices tap. > [2009-01-20 09:13:55 20596] DEBUG (DevController:160) Waiting for 51712. > [2009-01-20 09:13:55 20596] DEBUG (DevController:645) hotplugStatusCallback /local/domain/0/backend/tap/8/51712/hotplug-status. > [2009-01-20 09:13:55 20596] DEBUG (DevController:659) hotplugStatusCallback 1. > [2009-01-20 09:13:55 20596] DEBUG (DevController:155) Waiting for devices vtpm. > [2009-01-20 09:13:55 20596] INFO (XendDomain:1172) Domain test (8) unpaused. > [2009-01-20 09:13:57 20596] INFO (XendDomainInfo:1634) Domain has shutdown: name=test id=8 reason=poweroff. > [2009-01-20 09:13:57 20596] DEBUG (XendDomainInfo:2389) XendDomainInfo.destroy: domid=8 > [2009-01-20 09:13:57 20596] DEBUG (XendDomainInfo:2406) XendDomainInfo.destroyDomain(8) > [2009-01-20 09:13:57 20596] DEBUG (XendDomainInfo:1939) Destroying device model > [2009-01-20 09:13:57 20596] DEBUG (XendDomainInfo:1946) Releasing devices > [2009-01-20 09:13:57 20596] WARNING (image:472) domain test: device model failure: no longer running; see /var/log/xen/qemu-dm-test.log > > /var/log/xen/qemu-dm-test.log shows nothing spectacular at all (at least for me): > domid: 8 > qemu: the number of cpus is 1 > config qemu network with xen bridge for tap8.0 xenbr0 > config qemu network with xen bridge for tap8.1 eth0 > Using xvda for guest''s hda > Strip off blktap sub-type prefix to /path/to/test.img (drv ''qcow'') > Watching /local/domain/0/device-model/8/logdirty/next-active > Watching /local/domain/0/device-model/8/command > qemu_map_cache_init nr_buckets = 10000 size 3145728 > shared page at pfn 3fffe > buffered io page at pfn 3fffc > Time offset set 0 > Register xen platform. > Done register platform. > > /var/log/messages also shows nothing remarkable. Interesting entries never seen before are: > Jan 19 17:50:02 test kernel: tapdisk[21929] general protection rip:40b315 rsp:42900108 error:0 > but they occur all the time on Xen 3.3 and Xen 3.3.1 using qcow images (but seem to be recovered) > > VM config file: > ------------------------------------------------------------------------------------------ > name = "test" > device_model = ''/usr/lib64/xen/bin/qemu-dm'' > builder = "hvm" > kernel = "/usr/lib/xen/boot/hvmloader" > > # hardware > memory = "1024" > disk = [ ''tap:qcow:/path/to/B.img,ioemu:xvda,w'' ] > vcpus=1 > > # network > vif = [ ''type=ioemu,mac=02:00:00:00:00:01'',''type=ioemu,bridge=eth0,mac=02:00:00:00:01:98'' ] > dhcp = "dhcp" > > # visualization > sdl = 0 > vnc = 1 > vncviewer = 0 > ------------------------------------------------------------------------------------------ > > Any help is appreciated. Thanks! > > Cheers, > Martin__________________________________________________________________ Deutschlands größte Online-Videothek schenkt Ihnen 12.000 Videos!* http://entertainment.web.de/de/entertainment/maxdome/index.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2009-Feb-05 15:17 UTC
Re: [Xen-devel] FW: Xen 3.3.0 - QEMU COW disk image with sparse backing file - VM fails to start
Martin Tröster writes ("[Xen-devel] FW: Xen 3.3.0 - QEMU COW
disk> image with sparse backing file - VM fails to start"): Therefore, let
> me kindly ask why it is considered to "handle QCOW backing files
> correctly" now? The patch, in my eyes, allows to use a raw file as
> backing file, but breaks the use of a QCOW file (sparse file, in my
> setup) as a backing file. In my setup, this breaks the use of all
> current QCOW-files I am running when migrating from Xen-3.2 to
> Xen-3.3.
I''m sorry to have to tell you that this isn''t easy to fix in
general,
although I can point you where to make a specific patch which may work
for you.
The feature you were using (qcow backing files) has been disabled as a
security measure. It is also possible that your existing installation
is vulnerable to a the qcow format-guessing vulnerability.
The root cause of the problem is as follows:
> > The image structure is:
> > Base File A.img (sparse QCOW2 file)
> > COW File B.img (QCOW2 file with A.img as backing file)
> > used as disk in Xen config file (see VM config file below)
File B.img contains the filename of A.img - but it does not contain
any information about the format. Prior to fixing the security
problem, qemu (qemu-dm aka ioemu) would read the start of A.img to try
to determine what kind of file it was. Since A.img has a qcow2 header
it would treat it as a qcow2 file.
In your case that''s it, but in the general case A.img will itself have
the filename of a backing file, let us say Z.img. Unfixed qemu would
again guess the format of Z.img by reading the header. Eventually
some raw disk image would be found.
The problem is that if any untrusted guest can ever write the raw disk
image they can write a qcow header on the front of it. That qcow
header can contain a filename which the next invocation of qemu will
open and allow the guest to read (parts of, at least).
So I `fixed'' this by making all backing files of cow images always be
treated as raw images. (In upstream this is being fixed by adding
more metadata to the data format but the exact syntax is still
settling down and this change comes too late for Xen 3.3.)
The code which does this is this line
if (bdrv_open2(bs->backing_hd, backing_filename, open_flags, &bdrv_raw)
< 0)
in bdrv_open2 in block.c. The critical part is here: ^^^^^^^^^
If you change that to bdrv_qcow2 you may find that it all works. But
you will no longer be able to use qcow2 files with raw backing images.
Good luck!
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel