[SRU] libvirt-bin fails to start inside Xen

[Lorin Hochstein]

[Impact]

libvirtd to start within guests of some Xen environments. This has been reported by multiple users of the Rackspace public cloud. libvirt has many use-cases in this environment, most notably driving upstream OpenStack CI efforts. This bug makes libvirt unusable without some manually work arounds.

[Test Case]

On a saucy machine in an affected environment, 'apt-get install libvirt-bin' and watch libvirtd.log for a failure to start up:

2013-11-05 03:46:16.290+0000: 3398: info : libvirt version: 1.1.1
2013-11-05 03:46:16.290+0000: 3398: error : udevGetDMIData:1558 : Failed to get udev device for syspath '/sys/devices/virtual/dmi/id' or '/sys/class/dmi/id'
2013-11-05 03:46:16.368+0000: 3398: error : libxlMakeCapabilities:786 : internal error: Failed to get node physical info from libxenlight
2013-11-05 03:46:16.368+0000: 3398: error : libxlStateInitialize:1320 : cannot create capabilities for libxenlight
2013-11-05 03:46:16.369+0000: 3398: error : virStateInitialize:838 : Initialization of LIBXL state driver failed: internal error: Failed to get node physical info from libxenlight

[Regression Potential]

Minimal. The proposed patch simply causes libvirt to consider these errors as soft errors (like it does others) and continue to start its service.

--- Original Bug ---

On saucy, inside of a Xen virtual machine, libvirt-bin fails to start, with the following error in /var/log/libvirt/libvirtd.log

2013-11-05 03:46:16.290+0000: 3398: info : libvirt version: 1.1.1
2013-11-05 03:46:16.290+0000: 3398: error : udevGetDMIData:1558 : Failed to get udev device for syspath '/sys/devices/virtual/dmi/id' or '/sys/class/dmi/id'
2013-11-05 03:46:16.368+0000: 3398: error : libxlMakeCapabilities:786 : internal error: Failed to get node physical info from libxenlight
2013-11-05 03:46:16.368+0000: 3398: error : libxlStateInitialize:1320 : cannot create capabilities for libxenlight
2013-11-05 03:46:16.369+0000: 3398: error : virStateInitialize:838 : Initialization of LIBXL state driver failed: internal error: Failed to get node physical info from libxenlight

How to reproduce:

* Start a saucy Xen virtual machine (e.g., inside of Rackspace Public Cloud)
* Install libvirt-bin

# lsb_release -rd
Description: Ubuntu 13.10
Release: 13.10

# apt-cache policy libvirt-bin
libvirt-bin:
  Installed: 1.1.1-0ubuntu8
  Candidate: 1.1.1-0ubuntu8
  Version table:
 *** 1.1.1-0ubuntu8 0
        500 http://mirror.rackspace.com/ubuntu/ saucy/main amd64 Packages
        100 /var/lib/dpkg/status

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Joe Breu (breu)]

Getting a somewhat similar error:

root@breu-ubuntu-grizzly-neutron-node4:/etc/libvirt# /usr/sbin/libvirtd -l -v
2014-02-18 00:29:42.945+0000: 6009: info : libvirt version: 1.1.1
2014-02-18 00:29:42.945+0000: 6009: error : virExec:418 : Cannot find 'usr/lib/xen-common/bin/xen-toolstack' in path: No such file or directory
2014-02-18 00:29:42.947+0000: 6009: error : libxlMakeCapabilities:786 : internal error: Failed to get node physical info from libxenlight
2014-02-18 00:29:42.947+0000: 6009: error : libxlStateInitialize:1320 : cannot create capabilities for libxenlight
2014-02-18 00:29:42.947+0000: 6009: error : virStateInitialize:838 : Initialization of LIBXL state driver failed: internal error: Failed to get node physical info from libxenlight
2014-02-18 00:29:42.947+0000: 6009: error : daemonRunStateInit:905 : Driver state initialization failed

root@breu-ubuntu-grizzly-neutron-node4:/etc/libvirt# apt-cache policy libvirt-bin
libvirt-bin:
  Installed: 1.1.1-0ubuntu8.5~cloud0
  Candidate: 1.1.1-0ubuntu8.5~cloud0
  Version table:
 *** 1.1.1-0ubuntu8.5~cloud0 0
        500 http://ubuntu-cloud.archive.canonical.com/ubuntu/ precise-updates/havana/main amd64 Packages
        100 /var/lib/dpkg/status
     0.9.8-2ubuntu17.17 0
        500 http://mirror.rackspace.com/ubuntu/ precise-updates/main amd64 Packages
        500 http://mirror.rackspace.com/ubuntu/ precise-security/main amd64 Packages
     0.9.8-2ubuntu17 0
        500 http://mirror.rackspace.com/ubuntu/ precise/main amd64 Packages

[Célio Cidral Junior (ccidral-gmail)]

I'm getting the same error as @breu. Is there some way to workaround it? Is the xen-toolstack bin path hardcoded or can it be configured?

$ uname -a
Linux jupiter 3.11.0-17-generic #31~precise1-Ubuntu SMP Tue Feb 4 21:25:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ cat /var/log/libvirt/libvirtd.log
2014-02-26 19:06:40.765+0000: 19507: info : libvirt version: 1.1.1
2014-02-26 19:06:40.765+0000: 19507: error : virExec:418 : Cannot find 'usr/lib/xen-common/bin/xen-toolstack' in path: No such file or directory
2014-02-26 19:06:40.776+0000: 19507: error : virExec:418 : Cannot find 'pm-is-supported' in path: No such file or directory
2014-02-26 19:06:40.776+0000: 19507: warning : virQEMUCapsInit:896 : Failed to get host power management capabilities
2014-02-26 19:06:42.319+0000: 19507: error : virExec:418 : Cannot find 'pm-is-supported' in path: No such file or directory
2014-02-26 19:06:42.319+0000: 19507: warning : virLXCDriverCapsInit:82 : Failed to get host power management capabilities
2014-02-26 19:06:42.320+0000: 19507: error : virExec:418 : Cannot find 'pm-is-supported' in path: No such file or directory
2014-02-26 19:06:42.320+0000: 19507: warning : umlCapsInit:72 : Failed to get host power management capabilities
2014-02-26 20:13:15.796+0000: 19474: error : virExec:418 : Cannot find 'pm-is-supported' in path: No such file or directory
2014-02-26 20:13:15.797+0000: 19474: warning : virQEMUCapsInit:896 : Failed to get host power management capabilities
2014-02-26 20:22:28.300+0000: 19471: error : virNetSocketReadWire:1377 : End of file while reading data: Input/output error
2014-02-26 20:22:29.020+0000: 19474: error : virExec:418 : Cannot find 'pm-is-supported' in path: No such file or directory
2014-02-26 20:22:29.020+0000: 19474: warning : virQEMUCapsInit:896 : Failed to get host power management capabilities

[Matt Kassawara (ionosphere80)]

I'm seeing this issue on Precise too.

libvirtd.log:

2014-03-03 04:11:05.819+0000: 3454: info : libvirt version: 1.2.1
2014-03-03 04:11:05.819+0000: 3454: error : udevGetDMIData:1558 : Failed to get udev device for syspath '/sys/devices/virtual/dmi/id' or '/sys/class/dmi/id'
2014-03-03 04:11:05.896+0000: 3454: error : libxlDriverConfigNew:1114 : Unable to configure libxl's memory management parameters
2014-03-03 04:11:05.896+0000: 3454: error : virStateInitialize:791 : Initialization of LIBXL state driver failed: Unknown problem
2014-03-03 04:11:05.896+0000: 3454: error : daemonRunStateInit:911 : Driver state initialization failed

libxl-driver.log:

libxl: error: libxl.c:3938:libxl_get_physinfo: getting physinfo: Operation not permitted
xc: debug: hypercall buffer: total allocations:7 total releases:7
xc: debug: hypercall buffer: current allocations:0 maximum allocations:1
xc: debug: hypercall buffer: cache current size:1
xc: debug: hypercall buffer: cache hits:6 misses:1 toobig:0
libxl: error: libxl.c:3938:libxl_get_physinfo: getting physinfo: Operation not permitted
xc: debug: hypercall buffer: total allocations:7 total releases:7
xc: debug: hypercall buffer: current allocations:0 maximum allocations:1
xc: debug: hypercall buffer: cache current size:1
xc: debug: hypercall buffer: cache hits:6 misses:1 toobig:0

[Stefan Bader (smb)]

First question is what kind of Xen guests are the default for Rackspace (PV or HVM). I suspect PV because of the dmi/id errors. Then I wonder whether there is anything more related to Xen installed in the guests than libxen and libxenstore.
The message about xen-toolstack actually shows a glitch in the libvirt package (missing a leading slash) but that should not cause the libvirt daemon to not start.
Could we get the full libvirt.log here? Also could someone check dmesg/syslog for libvirt related messages? It would also be good to get a little more background on why libvirt-bin is installed inside the guest.

[Joe Breu (breu)]

This is a PVHVM kernel. I will attach dmesg, dmidecode, libvirtd log, and list of packages installed.

To answer your question about why libvirt is installed on the guest - we use the public cloud to test certain openstack features with qemu. We understand that you don't get hardware virt with this setup and frankly don't mind. libvirt-bin used to launch just fine and we could use qemu just fine before the latest update of the package in ubuntu cloudarchive

[Joe Breu (breu)]

tried the libvirt-bin in icehouse cloud-archive and different bug so I tried the grizzly one.

I just tested and verified that this issue does not exist in libvirt-bin_1.0.2-0ubuntu11.13.04.5~cloud1_amd64.deb which is available in the grizzly ubuntu cloud-archive.

So, some change between 1.0.2 and 1.1.1 introduced the error with running libvirt-bin in a Xen domU

[Joe Breu (breu)]

This commit in libvirt-bin upstream may be useful for tracking this down:

commit 03ede2f69d294af49642805384d54ac8ac7a4adc
Author: Daniel Veillard <email address hidden>
Date: Fri Apr 1 19:30:53 2011 +0800

    Fix libxl driver startup

      When you happen to have a libvirtd binary compiled with the
    libxenlight driver (say you have installed xen-4.1 libraries)
    but not running a xen enabled system, then libvirtd fails to start.

    The cause is that libxlStartup() returns -1 when failing to initialize
    the library, and this propagates to virStateInitialize() which consider
    this a failure. We should only exit libxlStartup with an error code
    if something like an allocation error occurs, not if the driver failed
    to initialize.

    * src/libxl/libxl_driver.c: fix libxlStartup() to not return -1
      when failing to initialize the libxenlight library

[Stefan Bader (smb)]

Thanks rackerjoe. That change sounds quite plausible. And the explanation helped greatly to understand how things are meant to be. I initially tried to reproduce with a PV guest (because that is at least in EC2 the more common type). Though that did not work (or rather it failed not to work). Will try again with a HVM guest.
Another thing which is now clear is that this has not been a regression within Saucy but was there on release. Just not tried when running in a Xen guest.

[Stefan Bader (smb)]

Hm, ok. Looks like the patch mentioned above was in v0.9.0 already, so at least that would be in 1.1.1 already in the Saucy version.

Unfortunately trying to reproduce locally is not working. The effect is just as I would expect it. In the libxl specific log I get:

xc: error: Could not obtain handle on privileged command interface (2 = No such file or directory): Internal error
libxl: error: libxl.c:87:libxl_ctx_alloc: cannot open libxc handle: No such file or directory

which sounds reasonable as a normal guest won't have the control file under /proc/xen. This looks to be enough to make libvirt not to try any capabilities and my libvirt.log looks just as:

2014-03-04 17:44:15.814+0000: 1126: info : libvirt version: 1.1.1
2014-03-04 17:44:15.814+0000: 1126: error : virExec:418 : Cannot find 'usr/lib/xen-common/bin/xen-toolstack' in path: No such file or directory
2014-03-04 17:44:15.952+0000: 1126: error : virExec:418 : Cannot find 'pm-is-supported' in path: No such file or directory
2014-03-04 17:44:15.952+0000: 1126: warning : virQEMUCapsInit:896 : Failed to get host power management capabilities
2014-03-04 17:44:18.612+0000: 1126: error : virExec:418 : Cannot find 'pm-is-supported' in path: No such file or directory
2014-03-04 17:44:18.612+0000: 1126: warning : virLXCDriverCapsInit:82 : Failed to get host power management capabilities
2014-03-04 17:44:18.613+0000: 1126: error : virExec:418 : Cannot find 'pm-is-supported' in path: No such file or directory
2014-03-04 17:44:18.613+0000: 1126: warning : umlCapsInit:72 : Failed to get host power management capabilities

The virQEMUCapsInit fails too, but it does not prevent the daemon from running. I am wondering what is different in your guest.

[Adam Gandelman (gandelman-a)]

Hitting this on rackspace using on both a saucy instance /w 1.1.1-0ubuntu8.5 and on a precise instance /w cloud archive's 1.1.1-0ubuntu8.5~cloud0. Attached is a debug log of saucy's failure.

[Stefan Bader (smb)]

Adam (or others), in the Saucy instance, which version of libxen does get installed there? The current version should be 4.3.0-1ubuntu1.3. This is the version I have been testing with. Though in the dpkg list from rackerjoe that was back at ubuntu1.1.
Somehow it seems in my case libxl_ctx_alloc fails which is treated as indication of not running in dom0, so returns successful but disables the driver. In your cases that seems to succeed and only fail later in libxlMakeCapabilities which is treated as an error.

[Joe Breu (breu)]

I know this is dirty, but...

removing /usr/lib/libvirt/connection-driver/libvirt_driver_libxl.so and /usr/lib/libvirt/connection-driver/libvirt_driver_xen.so makes libvirt-bin launch on the Rackspace public cloud.

A strace of the libvirt-bin process shows it opening /proc/xen/xenbus and then trying to get the xen properties

892 open("/proc/xen/privcmd", O_RDWR) = 22
4892 fcntl(22, F_GETFD) = 0
4892 fcntl(22, F_SETFD, FD_CLOEXEC) = 0
4892 stat("/var/run/xenstored/socket", 0x7f509c32e6e0) = -1 ENOENT (No such file or directory)
4892 stat("/proc/xen/xenbus", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
4892 open("/proc/xen/xenbus", O_RDWR) = 23
4892 ioctl(22, SNDCTL_DSP_RESET, 0x7f509c32e3c0) = 262145
4892 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0) = 0x7f50ac5d4000
4892 madvise(0x7f50ac5d4000, 4096, 0xa /* MADV_??? */) = 0
4892 ioctl(22, SNDCTL_DSP_RESET, 0x7f509c32e3c0) = 0
4892 ioctl(22, SNDCTL_DSP_RESET, 0x7f509c32e3c0) = 0
4892 ioctl(22, SNDCTL_DSP_RESET, 0x7f509c32e3c0) = 0
4892 ioctl(22, SNDCTL_DSP_RESET, 0x7f509c32e3c0) = 0
4892 ioctl(22, SNDCTL_DSP_RESET, 0x7f509c32e3c0) = 0
4892 ioctl(22, SNDCTL_DSP_RESET, 0x7f509c32e3c0) = 4096
4892 ioctl(22, SNDCTL_DSP_RESET, 0x7f509c32e3c0) = 0
4892 ioctl(22, SNDCTL_DSP_RESET, 0x7f509c32e250) = -1 EPERM (Operation not permitted)
4892 write(19, "libxl: error: libxl.c:3938:libxl_get_physinfo: getting physinfo: Operation not permitted\n", 89) = 89
4892 gettid() = 4892
4892 clock_gettime(CLOCK_REALTIME, {1394225065, 392717879}) = 0
4892 write(4, "2014-03-07 20:44:25.392+0000: 4892: error : libxlMakeCapabilities:786 : internal error: Failed to get node physical info from libxenlight\n", 138) = 138
4892 gettid() = 4892
4892 clock_gettime(CLOCK_REALTIME, {1394225065, 392879907}) = 0
4892 write(4, "2014-03-07 20:44:25.392+0000: 4892: error : libxlStateInitialize:1320 : cannot create capabilities for libxenlight\n", 115) = 115
4892 gettid() = 4892
4892 clock_gettime(CLOCK_REALTIME, {1394225065, 393023723}) = 0
4892 gettid() = 4892
4892 clock_gettime(CLOCK_REALTIME, {1394225065, 393108049}) = 0
4892 write(19, "xc: debug: hypercall buffer: total allocations:7 total releases:7\n", 66) = 66
4892 write(19, "xc: debug: hypercall buffer: current allocations:0 maximum allocations:1\n", 73) = 73
4892 write(19, "xc: debug: hypercall buffer: cache current size:1\n", 50) = 50
4892 write(19, "xc: debug: hypercall buffer: cache hits:6 misses:1 toobig:0\n", 60) = 60
4892 madvise(0x7f50ac5d4000, 4096, 0xb /* MADV_??? */) = 0
4892 munmap(0x7f50ac5d4000, 4096) = 0

There is obviously a problem in the 1.1.1 version of libvirt-bin in cloud-archive here - but I don't know where to look yet.

[Stefan Bader (smb)]

This is dirty but at the same time we could be quite sure this does work as it is clearly the startup going wrong. :)

Maybe I can go the other way round and downgrade my libvirt version to the ubuntu1.1 level to see whether things fail then. Some of the CVE fixes just read to me as fix leaking hypervisor capabilities into guests which would be matching what we see. That for some reason the libxl driver thinks it is running inside a dom0.

[Stefan Bader (smb)]

Downgrading the libxen and libxenstore libraries (sorry, I was referring to those before but wrote libvirt). to previous versions did not help to cause the issue. Also used a precise (Xen-4.1) host for the same Saucy guest. Still libvirtd starts and keeps running.

[Stefan Bader (smb)]

So Adam was giving me access to some Rackspace guests. I found that in those a xenfs was mounted to /proc/xen. This was done by the init script of xe-guest-utilities. I suspect this is something that works together with a XenServer host. There was also a nova-agent running which I could not find a package for. This was attached to /proc/xen/xenbus.
I can get libvirtd to run when I shut down all nova-agents, stop the xe utilities and unmoutn /proc/xen. So the problem is that having /proc/xen running, the initial checks of the libxl driver in libvirt are mislead to think the guest is a dom0. This would just abort loading the driver. But failing to read the capabilities returns an error from the driver load which seems fatal.
Maybe the solution will be as simple as either treating this as a soft failure, too or have a better check for that situation.

At least this gives a good lead to reproduce tomorrow and see whether newer versions of libvirt already handle that case. And if not, discuss and create a fix for upstream which we can pick into our releases.

[Stefan Bader (smb)]

To clarify, I think someone said Precise guests would suffer the same. But that should only be with a libvirt version from Saucy (to be more precise a libvirt compiled against libxen-dev from Saucy as that was the first release that had the packaging fixed so libvirt would build the libxl driver). This is mostly to figure out which libvirt packages we need to fix.

[Stefan Bader (smb)]

Waiting for the outcome of the upstream discussion, but this would be the proposed change for the Saucy libvirt package (fixing the toolstack path and dom0 detection).

[Stefan Bader (smb)]

The change was accepted upstream. So here is the debdiff for Trusty, too. Note that things will need a bit of fiddling as we need to modify xend detection around the same place as Debian packaging is different.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt - 1.2.2-0ubuntu3

---------------
libvirt (1.2.2-0ubuntu3) trusty; urgency=low

  * d/p/libxl-Check-for-control_d-string-to-decide-about-dom.patch: Prevent
    using the libxl driver when not running in dom0 but having xenfs mounted.
    (LP: #1248025)
 -- Stefan Bader <email address hidden> Wed, 12 Mar 2014 14:16:14 +0100

[Stefan Bader (smb)]

For the Saucy upload, please hold back. There is some follow up to avoid an unnecessary error logged by libvirt when there is no Xen capabilities file (functionality not impacted). I will push out some revised debdiff.

[Brian Murray (brian-murray)]

Hello Lorin, or anyone else affected,

Accepted libvirt into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/libvirt/1.1.1-0ubuntu8.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Sebastien Bacher (seb128)]

(seems like there is nothing left to sponsor here, unsubsribing sponsors)

[Adam Gandelman (gandelman-a)]

Was hoping to test this today but the 1.1.1-0ubuntu8.8 package that was uploaded to saucy-proposed seems to be FTBFS for all arches ATM

[Serge Hallyn (serge-hallyn)]

yes there is a 1.1.1-0ubuntu8.9 package awaiting acceptance into
saucy-proposed.

[Brian Murray (brian-murray)]

Hello Lorin, or anyone else affected,

Accepted libvirt into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/libvirt/1.1.1-0ubuntu8.9 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Adam Gandelman (gandelman-a)]

Confirmed the proposed package fixes the issue.. Previous package in -updates vs whats in -proposed:

Unpacking libvirt-bin (from .../libvirt-bin_1.1.1-0ubuntu8.7_amd64.deb) ...
Processing triggers for ureadahead ...
Processing triggers for man-db ...
Setting up libvirt0 (1.1.1-0ubuntu8.7) ...
Setting up libvirt-bin (1.1.1-0ubuntu8.7) ...
libvirt-bin start/running, process 14966
root@sauce:~# service libvirt-bin status
libvirt-bin stop/waiting

# enable proposed
root@sauce:~# apt-get install libvirt-bin
.. <SNIP> ..
Setting up libvirt0 (1.1.1-0ubuntu8.9) ...
Setting up libvirt-bin (1.1.1-0ubuntu8.9) ...
libvirt-bin start/running, process 16282
Setting up libvirt-bin dnsmasq configuration.
Processing triggers for libc-bin ...
root@sauce:~# service libvirt-bin status
libvirt-bin start/running, process 16282

[Brian Murray (brian-murray)]

Hello Lorin, or anyone else affected,

Accepted libvirt into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/libvirt/1.1.1-0ubuntu8.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Stefan Bader (smb)]

Downloaded built binaries and installed inside Saucy Xen guest. libvirtd starts up while xenfs is mounted.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt - 1.1.1-0ubuntu8.10

---------------
libvirt (1.1.1-0ubuntu8.10) saucy-proposed; urgency=medium

  * remove lp1264465/* as it did not pass verification

libvirt (1.1.1-0ubuntu8.9) saucy-proposed; urgency=medium

  * fix badly applied patch
    0001-qemu-hotplug-only-label-hostdev-after-checking-device-conflicts

libvirt (1.1.1-0ubuntu8.8) saucy-proposed; urgency=medium

  [ Stefan Bader ]
  * debian/patches/ubuntu-xend-probe.patch: Fix search path for xen-toolstack
    command (LP: #1248025)
  * debian/patches/libxl-fix-dom0-detection.patch: Check contents of
    /proc/xen/capabilities to decide whether running in dom0. (LP: #1248025)

  [ Serge Hallyn ]
  * debian/libvirt-dev.install: add libvirt-lxc.so (LP: #1287232)
 -- Serge Hallyn <email address hidden> Thu, 17 Apr 2014 09:57:23 -0500

[Stéphane Graber (stgraber)]

The verification of the Stable Release Update for libvirt has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.