WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Re: [Xen-devel] tap:qcow causes dom-U to hang in 3.0.3


On 10 Nov 2006, at 14:00, Roland Paterson-Jones wrote:

Julian Chesterfield wrote:

Can you also verify whether there's an active tapdisk process running in Dom0 for each tap:{aio,qcow} vbd. We are aware of a bug with the qcow implementation that we hope to submit a fix for very soon. It's likely that you are seeing the same issue.

Sorry, this is not what you asked for, but this is what an 'ls' of the qcow file shows:

[root@dom0-0-50-45-5d-6a-bc ~]# ls -als /mnt/instance_image_store_0/
total 1564108
     4 drwxr-xr-x  2 root root          4096 Nov 10 15:42 .
     8 drwxr-xr-x  8 root root          4096 Nov  7 17:56 ..
1563132 -rw-r--r--  1 root root    1599078400 Nov 10 15:42 2
   964 -rw-r--r--  1 root root 1099645846016 Nov 10 15:50 2.qcow

It looks like the qcow file has grown to > 1000GB in (apparent) size(!) Could this be the root of the problem?

Hmm, this shoudn't happen. Looks like the block offset lookup is screwed up.


At this stage the dom-U is still running, but the qcow file is clearly not right. The file called '2' is a loopback image backing the qcow file.

The qcow overlay was created using '/usr/sbin/qcow-create $((10*1024)) /mnt/instance_image_store_0/2.qcow /mnt/instance_image_store_0/2'. I'm guessing there's no danger in making the qcow overlay extent (10GB) larger than the underlying loopback file extend (1.5GB) but please correct me if I'm wrong.

So the current overlay support actually ignores the size value and creates a sparse overlay file with the same virtual size as the original. Technically it would be possible to create an overlay file larger than the source and fault read/writes for larger block offsets to the overlay disk, however I'm not certain this is a good idea.


Earlier, an ls of the same directory (soon after dom-U creation) looked like:

[root@dom0-0-50-45-5d-6a-bc ~]# ls -als /mnt/instance_image_store_0/
total 1564052
     4 drwxr-xr-x  2 root root       4096 Nov 10 15:42 .
     8 drwxr-xr-x  8 root root       4096 Nov  7 17:56 ..
1563132 -rw-r--r--  1 root root 1599078400 Nov 10 15:42 2
   908 -rw-r--r--  1 root root     925696 Nov 10 15:43 2.qcow

Could this be the root of the problem - i.e. something in the qcow driver is getting it's offsets in the qcow file mangled?

Can I try to compile the qcow (tapdisk) driver with debug enabled? Where would the output go?
There's a bunch of DPRINTFs in the code which send debug output to syslog. You can play with syslog settings to switch on the debug messages and direct them to a log file.

Thanks for the file size tip, I'll explore further.

Thanks,
Julian


Regards
Roland



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