From: John Weekes <lists.xen@nuclearfallout.net>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Bugs in xl that affect stubdom+tapdisk2, and others
Date: Thu, 08 Nov 2012 12:45:18 -0800 [thread overview]
Message-ID: <509C19DE.6010108@nuclearfallout.net> (raw)
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
next reply other threads:[~2012-11-08 20:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-08 20:45 John Weekes [this message]
2012-11-09 13:29 ` Bugs in xl that affect stubdom+tapdisk2, and others Ian Campbell
2012-11-09 19:55 ` Matt Wilson
2012-11-12 9:49 ` Ian Campbell
2013-08-15 21:13 ` John Weekes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=509C19DE.6010108@nuclearfallout.net \
--to=lists.xen@nuclearfallout.net \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).