Two recent patches that broke my stubdoms

Two recent patches that broke my stubdoms

[John Weekes]

[-- Attachment #1.1: Type: text/plain, Size: 1859 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 3465 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Two recent patches that broke my stubdoms

[Keir Fraser]

On 13/01/2010 18:14, "John Weekes" <lists.xen@nuclearfallout.net> wrote:

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

Cc'ing the patch author. My default response on this one would be just to
revert the changeset. But there's probably something stubdom-specific that
could be engineered instead.

 -- Keir

Re: Two recent patches that broke my stubdoms

[Keir Fraser]

On 13/01/2010 18:14, "John Weekes" <lists.xen@nuclearfallout.net> wrote:

> 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).

Should be fixed by c/s 20804.

>                 if count > 100:
>                     break

Should be fixed by c/s 20805.

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

We'll see if patch author comes up with a solution. Else I will revert the
changeset before doing an -rc2 next week.

 Thanks,
 Keir

Re: Two recent patches that broke my stubdoms

[Keir Fraser]

On 13/01/2010 18:14, "John Weekes" <lists.xen@nuclearfallout.net> wrote:

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

I've reverted this changeset now. So hopefully all your issues are dealt
with ahead of 4.0.0-rc2.

 -- Keir