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-devel

[Xen-devel] Two recent patches that broke my stubdoms

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Two recent patches that broke my stubdoms
From: "John Weekes" <lists.xen@xxxxxxxxxxxxxxxxxx>
Date: Wed, 13 Jan 2010 10:14:17 -0800
Delivery-date: Wed, 13 Jan 2010 10:14:59 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
Importance: Normal
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
In testing 4.0-0rc1, I found that I could no longer start file-backed stubdom-based domUs. They worked fine under a November changeset, so I took a closer look. After a bit of digging, I found two patches that prevent them from starting. It would be best if these were reverted, or preferably retooled by their authors, before the next -rc.
 
c/s 20631 :
 
When starting a stubdom-based domain, I found that "xm create" would simply hang.
 
In the qemu-dm-domain.log file, I saw:
 
Error: Device 768 (vbd) could not be connected. losetup /dev/loop0 /path/to/file.img failed
 
Reverting c/s 20631 made it work again. I run Gentoo, and losetup -f works fine, but the new method apparently doesn't (I suspect it has something to do with having to start up the two domains so close together).
 
The hanging problem also highlighted an issue with image.py. This line around line 491 caused an endless wait for a domain that would never start ("continue" makes no sense in this context, because it's in a "while True" loop already):
 
                if count < 100:
                    continue
 
I suspect this was closer to the author's intent:
 
                if count > 100:
                    break
 
c/s 20746 :
 
I tried to start my domain again, and it still wouldn't go. With the original image.py, it would just hang and show the main domain as --p--- and the stubdom as -b----. This told me that something was probably wrong with the stubdom or its configuration, so I took a look at the autogenerated stubdom file and found "monitor=null" in the vfb line, which was different than what previous versions put in. I simply edited image.py to revert c/s 20746, and this got rid of "monitor=null", allowing the domain to start.
 
As this problem seems to relate to stubdoms specifically, an exception may need to just be put in for them.
 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>