[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Bugs in xl that affect stubdom+tapdisk2, and others
|
I took a look at the below concerns
again in 4.3. The summarized concerns were:
1. Multiple domains not being able to use the same read-only
images.
2. "xl destroy" giving error messages when tapdisk2 and stub
domains are used.
3. "xl uptime" not working without an argument.
4. Minor typos in xl output.
5. A mistaken warning printed by "xl sched-credit".
6. Build issues related to /usr/lib being used even though
./configure was run with "--libdir=/usr/lib64"
The current situation:
1. Worked around: It appears that tapdisk2 has been disabled for
read-only images, with qdisk used instead, presumably to work
around this concern.
2. Still an issue: These errors still appear. But, since tapdisk2
is no longer used for CD images, they are mostly harmless now.
3. Still an issue: I am submitting a patch to address this.
4. Still an issue: I am submitting a patch to address this.
5. Fixed: I am no longer seeing the warning.
6. Still an issue: But, not a major one.
I also noticed a newly-introduced bug:
7. rtc_timeoffset is not accepting negative values. Attempting to
use a negative value causes an error to be printed, with domain
creation halted.
I am submitting a patch separately to address #7 along with #3 and
#4. I've tested the patch and it works properly for me.
-John
On 11/8/2012 12:45 PM, John Weekes wrote:
I'm having these problems when using "xl" in the
latest c/s of 4.2 (25912:651d965ee2c0):
- It's not allowing multiple domains to use the same images, at
least under tapdisk2. If I start one domain using an image (a
read-only CD-ROM image, for instance), then start another, I can
see in "tap-ctl list" that only one of the domains actually
receives the proper access. The other either never gets it, or it
is disconnected after it's created -- I can't readily tell which.
- When I use "xl destroy" on a domain that also has an associated
stubdom, "xl" tries to destroy the tapdisk2 entries for both the
domain and its stubdomain, resulting in errors like these:
# xl destroy testvds4
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk:
Unable to find type aio disk /servers/isos/DummyCD.iso: No such
file or directory
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk:
Unable to find type aio disk /servers/customers/testvds4.img: No
such file or directory
libxl: error: libxl_blktap2.c:73:libxl__device_destroy_tapdisk:
Unable to find type aio disk /servers/isos/DummyCD-2.iso: No such
file or directory
libxl: error: libxl.c:1466:devices_destroy_cb:
libxl__devices_destroy failed for 19
libxl: error: libxl.c:1466:devices_destroy_cb:
libxl__devices_destroy failed for 18
If I'm reading the source correctly, it seems as though the
various destruction functions aren't passing down the domid and
ultimately libxl__device_destroy_tapdisk is calling tap_ctl_find,
which just globally matches based on the type and name of the
image, causing the errors on destroy. I was trying to find a quick
fix, but it looks like any proper one will require querying
xenstore for the tapdisk entries specific to the domain, and I'm
not immediately able to make that change, so I've personally just
switched back to using "xm" for the time being. (I don't know if
this relates to the first bug re: multiple domains using the same
image files).
Another, much more minor, bug in "xl" that I've found is that "xl
uptime" will not run without an argument; it is supposed to just
show all uptimes in this circumstance. This is an easy one-liner
fix of modifying line:
tools/libxl/xl_cmdimpl.c:5749: while ((opt = def_getopt(argc,
argv, "s", "uptime", 1)) != -1) {
into this:
tools/libxl/xl_cmdimpl.c:5749: while ((opt = def_getopt(argc,
argv, "s", "uptime", 0)) != -1) {
Also, a couple of small typos in "xl" --
libxl.c:556: LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
"geting domain info list");
libxl.c:575: LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
"geting domain info list");
libxl.c:678: LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
"geting domain info list");
libxl.c:1393: LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
"non-existant domain %d", domid);
Also, running "xl sched-credit" always gives me an error, even
though it seems to work. Maybe it should be silent if cpu pools
aren't defined? Maybe it's supposed to be creating a second
cpupool for the second CPU in this system, and isn't?
# xl sched-credit
libxl: error: libxl.c:596:cpupool_info: failed to get info for
cpupool1
: No such file or directory
Cpupool Pool-0: tslice=5ms ratelimit=500us
Name ID Weight Cap
Domain-0 0 65535 0
As an additional note about 4.2 -- this isn't an "xl" issue, but
rather a build problem -- even though I use "./configure
--libdir=/usr/lib64", the build is still creating a
"dist/install/usr/lib" directory, and because of this, running
./install.sh nukes my system's "/usr/lib" -> "/usr/lib64"
softlink (which in turn causes all sorts of other problems until
it's corrected). Files that are being put in that tree:
xen-4.2-testing.hg # find dist/install/usr/lib
dist/install/usr/lib
dist/install/usr/lib/xen
dist/install/usr/lib/xen/boot
dist/install/usr/lib/xen/boot/xenstore-stubdom.gz
dist/install/usr/lib/xen/boot/ioemu-stubdom.gz
dist/install/usr/lib/xen/boot/pv-grub-x86_64.gz
dist/install/usr/lib/xen/boot/hvmloader
dist/install/usr/lib/xen/boot/pv-grub-x86_32.gz
dist/install/usr/lib/xen/bin
dist/install/usr/lib/xen/bin/stubdom-dm
dist/install/usr/lib/xen/bin/qemu-io
dist/install/usr/lib/xen/bin/qemu-nbd
dist/install/usr/lib/xen/bin/qemu-img
dist/install/usr/lib/xen/bin/xenpaging
dist/install/usr/lib/xen/bin/qemu-dm
dist/install/usr/lib/xen/bin/qemu-system-i386
dist/install/usr/lib/xen/bin/qemu-ga
dist/install/usr/lib/xen/bin/stubdompath.sh
-John
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
