[Xen-devel] Re: qcow image fail to work with xl

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 9 Dec 2010, Zhang, Yang Z wrote:
> Hi stafano
> I am working on moving our test scenario to xl now. But there are some bugs 
> block it.
> 1. qcow and qcow2 image fail to work.
> it will stall at booting guest when using cow image and it will show 
> "had:dma_timer_expiry: dma status ==0x21" in guest console and guest 
> hangs(See attachment).
> Then I use xl destroy to shutdown it. But it fail too, xl list shows the 
> guest was destroyed successfully, but the guest's console still exist and use 
> ps -ax, I can see
> "8432 pts/1    Zl     3:13 [qemu-dm] <defunct>"
> After seen this, I cannot use xl create to create guest again. It will show:
> [root@vt-nhm7 var]# xl create config.vmxCPL_MEM_29
> Parsing config file config.vmxCPL_MEM_29
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->0000000000179710
>   TOTAL:         0000000000000000->000000001f800000
>   ENTRY ADDRESS: 0000000000100000
> xc: info: PHYSICAL MEMORY ALLOCATION:
>   4KB PAGES: 0x0000000000000200
>   2MB PAGES: 0x00000000000000fb
>   1GB PAGES: 0x0000000000000000
> libxl: error: libxl_device.c:471:libxl__wait_for_device_model Device Model 
> not ready
> xl: fatal error: xl_cmdimpl.c:1699, rc=-1: 
> libxl_confirm_device_model_startup(&ctx, dm_starting)
> 
> Here is the log from /var/log/xen/:
> Waiting for domain vCPL_MEM_29_1291859410 (domid 1) to die [pid 8470]
> Domain 1 is dead
> Unknown shutdown reason code 255. Destroying domain.
> Action for shutdown reason code 255 is destroy
> Domain 1 needs to be cleaned up: destroying the domain
> libxl: error: libxl.c:909:libxl_destroy_device_model Couldn't find device 
> model's pid: No such file or directory
> libxl: error: libxl.c:973:libxl_domain_destroy libxl_destroy_device_model 
> failed for 1
> libxl: error: libxl_device.c:324:libxl__devices_destroy 
> /local/domain/1/device is empty
> Done. Exiting now
> 

There are two bugs regarding qcow2: one in libxl and one in blktap.
I have just fixed the one in libxl, you need the patch "return "tap" as
backend type for PHYSTYPE_QCOW2".
With that patch applied I can use qcow2 without problems using qemu-xen
as disk backend.
While waiting for a fix to blktap you can use qemu-xen simply
removing CONFIG_XEN_BLKDEV_BACKEND and CONFIG_XEN_BLKDEV_TAP from your
dom0 kernel config: xl will automatically use qemu-xen as disk backend
instead. The current qemu-xen is not going to be very fast though, you
have to use the new one (still experimental) if you care about
performances.



> 2. xl vnc cannot work but xm vnc works well
> 3.If use the default config(/xen/etc/xmexample.hvm), it assign ',hdc:cdrom,r' 
> to disk and xl create will raise segment fault when to parse it.
> 

Gianni, if I recall correctly you were the last one to touch this code,
can you reproduce these two errors?



> Another question is that do we need to start xend when using xl. If no, how 
> to create the bridge.
> 

Just create a bridge named xenbr0, then add eth0 to xenbr0:

brctl addbr xenbr0
brctl addif xenbr0 eth0
dhclient xenbr0

but you shouldn't do it manually, you should use your distro's tools
instead; for example for Debian:

http://wiki.debian.org/BridgeNetworkConnections


Also if you pass dom0_mem to the xen command line options, remember to
disable autoballooning in /etc/xen/xl.conf.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel