[Xen-users] Xen failing to create domain

[Duncan X Simpson]

I've been running a router in an HVM domU for a year or so, and it just
failed on me. When I try to xl create /etc/xen/chr.hvm.cfg, I get:

Parsing config from /etc/xen/chr.hvm.cfg
libxl: error: libxl_dm.c:2339:device_model_spawn_outcome: Domain 2:domain 2
device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1501:domcreate_devmodel_started: Domain
2:device model did not start: -3
libxl: error: libxl_dm.c:2453:kill_device_model: Device Model already exited
libxl: error: libxl_domain.c:1003:libxl__destroy_domid: Domain
2:Non-existant domain
libxl: error: libxl_domain.c:962:domain_destroy_callback: Domain 2:Unable
to destroy guest
libxl: error: libxl_domain.c:889:domain_destroy_cb: Domain 2:Destruction of
domain failed

I hadn't updated between when that happened and the last time I booted that
domU. I tried updating my system (pacman -Syu), but no change. Any ideas?

[George Dunlap]

Post by Duncan X Simpson
Parsing config from /etc/xen/chr.hvm.cfg
libxl: error: libxl_dm.c:2339:device_model_spawn_outcome: Domain 2:domain 2 device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1501:domcreate_devmodel_started: Domain 2:device model did not start: -3
libxl: error: libxl_dm.c:2453:kill_device_model: Device Model already exited
libxl: error: libxl_domain.c:1003:libxl__destroy_domid: Domain 2:Non-existant domain
libxl: error: libxl_domain.c:962:domain_destroy_callback: Domain 2:Unable to destroy guest
libxl: error: libxl_domain.c:889:domain_destroy_cb: Domain 2:Destruction of domain failed
I hadn't updated between when that happened and the last time I booted that domU. I tried updating my system (pacman -Syu), but no change. Any ideas?

Can you attach your config file, and
/var/log/xen/qemu-dm-${vnmame}.log? (Where ${vmname} is the name of
your VM of course.)

For good measure, could you attach the output of `dmesg` and `xl dmesg` as well?

Thanks.

-George

[Duncan X Simpson]

That log file had the answer. I didn't even know that existed.

/usr/lib/xen/bin/qemu-system-i386: error while loading shared libraries:
libiscsi.so.7: cannot open shared object file: No such file or directory

I updated libiscsi and now have libiscsi.so.8 instead. I just used
downgrade to go back to libiscsi-1.17.0-2 and that fixed it.
Although, why does it need iSCSI? I'm not using any iSCSI disks.

Anyway, thank you very much!

Post by Duncan X Simpson

Post by Duncan X Simpson
I've been running a router in an HVM domU for a year or so, and it just
Parsing config from /etc/xen/chr.hvm.cfg
libxl: error: libxl_dm.c:2339:device_model_spawn_outcome: Domain

2:domain 2 device model: spawn failed (rc=-3)

Post by Duncan X Simpson
libxl: error: libxl_create.c:1501:domcreate_devmodel_started: Domain

2:device model did not start: -3

Post by Duncan X Simpson
libxl: error: libxl_dm.c:2453:kill_device_model: Device Model already

exited

Post by Duncan X Simpson
libxl: error: libxl_domain.c:1003:libxl__destroy_domid: Domain

2:Non-existant domain

Post by Duncan X Simpson
libxl: error: libxl_domain.c:962:domain_destroy_callback: Domain

2:Unable to destroy guest

Post by Duncan X Simpson
libxl: error: libxl_domain.c:889:domain_destroy_cb: Domain 2:Destruction

of domain failed

Post by Duncan X Simpson
I hadn't updated between when that happened and the last time I booted

that domU. I tried updating my system (pacman -Syu), but no change. Any
ideas?
Can you attach your config file, and
/var/log/xen/qemu-dm-${vnmame}.log? (Where ${vmname} is the name of
your VM of course.)
For good measure, could you attach the output of `dmesg` and `xl dmesg` as well?
Thanks.
-George

[Duncan X Simpson]

I used the AUR package with some tweaking, so a bit of both. And yep, it's
Arch.

Post by Duncan X Simpson

Post by Duncan X Simpson
That log file had the answer. I didn't even know that existed.

libiscsi.so.7: cannot open shared object file: No such file or directory

Post by Duncan X Simpson
I updated libiscsi and now have libiscsi.so.8 instead. I just used

downgrade to go back to libiscsi-1.17.0-2 and that fixed it.
Glad to hear it!

Post by Duncan X Simpson
Although, why does it need iSCSI? I'm not using any iSCSI disks.

Hmm -- did you build Xen yourself, or are you using a package managed
by pacman (which is Arch Linux, I'm guessing)?
-George

[George Dunlap]

[In xen lists the standard is to reply in-line, not top-post.]

I used the AUR package with some tweaking, so a bit of both. And yep, it's Arch.

Right -- so the Xen build involves cloning & building qemu; and qemu's
habit, when you run ./configure, is to automatically enable all
features for which the requisite libraries exist, unless explicitly
disabled. Probably what happened is that when you did your local
build, the qemu build system noticed you had libiscsi installed and
enabled some random feature that linked against it.

Did you make an actual package that you then installed with pacman, or
just install Xen some other way?

If you made a package, I'm not sure why pacman didn't notice the
dependency; but you may want to see about building the package in a
chroot or something, with the minimum number of packages installed.

If you installed it directly, I'm afraid you're just going to have to
recompile and install it again whenever a breaking library update
happens. :-)

-George

[Duncan X Simpson]

Post by George Dunlap
[In xen lists the standard is to reply in-line, not top-post.]

Sorry about that, Gmail makes it require a separate action to even see the
previous email, let alone reply inline, so I don't even think about it.

Post by George Dunlap

Post by Duncan X Simpson
I used the AUR package with some tweaking, so a bit of both. And yep,

it's Arch.

Right -- so the Xen build involves cloning & building qemu; and qemu's

Post by George Dunlap
habit, when you run ./configure, is to automatically enable all
features for which the requisite libraries exist, unless explicitly
disabled. Probably what happened is that when you did your local
build, the qemu build system noticed you had libiscsi installed and
enabled some random feature that linked against it.

It seems the author of the PKGBUILD knew that it would do that and
explicitly added a makedepends and a depends on libiscsi.

Did you make an actual package that you then installed with pacman, or

Post by George Dunlap
just install Xen some other way?

The former.

If you made a package, I'm not sure why pacman didn't notice the

Post by George Dunlap
dependency; but you may want to see about building the package in a
chroot or something, with the minimum number of packages installed.

Because the PKGBUILD (basically instructions that tell makepkg what to do
and give it package metadata) depends on libiscsi, not libiscsi-1.17. I'm
on an outdated version of Xen (4.9) anyway. I'm about to upgrade, but I'm
taking a full backup first. We'll see what happens!

If you installed it directly, I'm afraid you're just going to have to

Post by George Dunlap
recompile and install it again whenever a breaking library update
happens. :-)
-George