Xen devel - Jan 2010 - Two recent patches that broke my stubdoms

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@lists.xensource.com
http://lists.xensource.com/xen-devel

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



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

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



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

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



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