Xen project Mailing List

Thanks! I am getting some progress with your advice.

Please see below.

On Tue, Nov 17, 2015 at 4:22 AM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:

On Tue, 2015-11-17 at 00:42 -0600, Yaohua Li wrote:
> Thanks for the advice!
>
> I can find the new device in xenstore-ls, but the OS code cannot read it
> out.

"xenstore-ls -fp" will give you the perms on the nodes, perhaps something
is wrong there?

>Â Is it possible to *remove* some xenstore nodes, if the code is too
> wrong?

Do you mean is it possible for a buggy guest to remove a node by mistake?
There are wire protocol commands to remove nodes, and I think the guest
would have permissions to remove them, but it's not the sort of thing I
would expect a guest to be able to do by mistake.

> I can see that the new devices are created, from xenstore-ls.
>
> Below is the output from one run of Ethos OS, with xl -vvv. It will crash
> and destroy the domain, so I won't see xenstore stuff afterwards.

If you "xl -vvv create -p" then it will create the guest paused, which will
give you a chance to inspect.

Have you tried a similar configuration using a known good OS (e.g. Linux or
FreeBSD perhaps)?

> libxl: verbose: libxl_create.c:130:libxl__domain_build_info_setdefault: qemu-xen is unavailable, use qemu-xen-traditional instead: No such file or directory

Ah, now this is interesting.

The use of a file: type device requires a qemu-xen process to provide the
backend, which it cannot find. There is a fallback to qemu-xen-traditional
(Xen's old fork of qemu) but it will not be well tested.

If you built from source you should have gotten a qemu-xen installed by
default unless you deliberately turned it off, if you got this from a
distro package then you may need to install it by hand (and maybe file a
wishlist bug with your distro to add a suitable dependency).

Yes, I tend to think this is the cause.Â

I am using Fedora 20 with Xen 4.3.4. Xen was installed from package.

I tried to look for qemu-xen related package but did not find any. By "install it by hand", do you mean install from package or something else?

I compiled Xen 4.3.4 but have not yet installed it (trying to avoid messing up the test machine that advisor uses).

I would prefer installing needed stuff from packages, since this process will need to be repeated many times by others (if the solution works).

An alternative workaround would be to run losetup by hand on your disk
image and then tell the vm cfg to use phy:/dev/loopN.
[....]

Yes, this worked for me. But I have problem with certain limitations on loop device. For example, I can only create it as /dev/loopX but not in arbitrary directory.

We need to run multiple instances of guest OS, thus such limitation is something to avoid.

So I guess I better use qemu-xen.

> libxl_device.c:959:device_hotplug: calling hotplug script:
> /etc/xen/scripts/vif-ethos online

What does this script do which is different to the stock ones?

I am not familiar with that. But it looks like a very simple wrapper for vif-route, for running Ethos.Â

Ian.

Re: [Xen-users] xl create argument issue with disk config