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