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@xxxxxx>
> Gesendet: 20.01.09 16:22:12
> An: xen-users@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home