virt-aa-helper Apparmor profile missing rules for name resolution
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | libvirt (Ubuntu) |
High
|
Christian Ehrhardt | ||
| | Xenial |
Medium
|
Christian Ehrhardt | ||
Bug Description
[Impact]
* Apparmor denies several hostname related accesses by libvirt causing
severe slowdowns in some cases.
[Test Case]
* Note: while there are various ways to trigger it - many have seen the
issue, but often it is unclear when exactly it will trigger or does no
more. So some of the repo-cases have proven to be unreliable - thanks
Simon for this Repro howto listed here. (simplified as it turned out
zvols are not needed according to comment #22)
1) Sync Xenial cloud-image
uvt-simplestrea
2) Create a test guest with:
uvt-kvm create --memory 2048 --cpu 4 --password=ubuntu xenial-kernel-test release=xenial arch=amd64 label=daily
3) strop it and add an extra volume in a way like this snippet
$ virsh shutdown xenial-kernel-test
$ virsh edit xenial-kernel-test
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source file='/dev/sda4'/>
<target dev='vdc' bus='virtio'/>
</disk>
4) start the guest
virsh start xenial-kernel-test
6) check for apparmor denial messages
dmesg | tail | grep apparmor
Without the fix, Apparmor would report denials when accessing /etc/nsswitch.conf, /etc/host.conf, /etc/gai.conf, /run/resolvconf
With the fix in place no related Apparmor denials show up.
[Regression Potential]
* The fix is rather small and "only" opens up apparmor confinement a bit.
That makes us assume that the potential for regression should be
minimal.
###############
Original description:
With libvirt-bin 1.3.1, starting a QEMU guest results in those AA denials:
Feb 17 12:06:23 simon-laptop kernel: [15734.513696] audit: type=1400 audit(145572878
Feb 17 12:06:23 simon-laptop kernel: [15734.513718] audit: type=1400 audit(145572878
Feb 17 12:06:23 simon-laptop kernel: [15734.513734] audit: type=1400 audit(145572878
Feb 17 12:06:23 simon-laptop kernel: [15734.513885] audit: type=1400 audit(145572878
virt-aa-helper's AA profile hasn't changed recently so it seems like the helper is doing more in this release.
Additional information:
$ lsb_release -rd
Description: Ubuntu Xenial Xerus (development branch)
Release: 16.04
$ apt-cache policy apparmor libvirt-bin
apparmor:
Installed: 2.10-3ubuntu1
Candidate: 2.10-3ubuntu1
Version table:
*** 2.10-3ubuntu1 500
500 http://
100 /var/lib/
libvirt-bin:
Installed: 1.3.1-1ubuntu1
Candidate: 1.3.1-1ubuntu1
Version table:
*** 1.3.1-1ubuntu1 500
500 http://
100 /var/lib/
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: libvirt-bin 1.3.1-1ubuntu1
ProcVersionSign
Uname: Linux 4.4.0-5-generic x86_64
NonfreeKernelMo
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Feb 17 13:08:04 2016
KernLog:
SourcePackage: libvirt
UpgradeStatus: No upgrade log present (probably fresh install)
modified.
modified.
| Simon Déziel (sdeziel) wrote : | #1 |
| Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1546674] [NEW] virt-aa-helper Apparmor profile missing rules for name resolution | #2 |
| Changed in libvirt (Ubuntu): | |
| status: | New → Confirmed |
| Changed in libvirt (Ubuntu): | |
| importance: | Undecided → High |
| Changed in libvirt (Ubuntu): | |
| status: | Confirmed → Triaged |
| Simon Déziel (sdeziel) wrote : | #3 |
It seems that those Apparmor denials are responsible for severe slowdown of guests boot when the host boots up.
This simple fix makes the guests boot swiftly:
# diff -Naur /etc/apparmor.
--- /etc/apparmor.
+++ /etc/apparmor.
@@ -66,4 +66,9 @@
/**.vmdk r,
/**.[iI][sS][oO] r,
/**/disk{,.*} r,
+
+ # XXX: https:/
+ /etc/hosts r,
+ /etc/host.conf r,
+ /etc/nsswitch.conf r,
}
| tags: | added: bitesize server-next |
| Changed in libvirt (Ubuntu Xenial): | |
| importance: | Undecided → Medium |
| status: | New → Triaged |
| Stefan Bader (smb) wrote : | #4 |
On a updated Xenial as well after a release upgrade to Yakkety, I was not able to see those messages for a VM created with uvtool. Serge, are you still able to confirm? Maybe this was settled somehow indirectly via abstractions/
| Simon Déziel (sdeziel) wrote : | #5 |
My 3 updated Xenial machines are still affected by this. Since comment #3, I also added /etc/gai.conf so the new diff looks like this:
$ diff -Naur /etc/apparmor.
--- /etc/apparmor.
+++ /etc/apparmor.
@@ -66,4 +66,10 @@
/**.vmdk r,
/**.[iI][sS][oO] r,
/**/disk{,.*} r,
+
+ # XXX: https:/
+ /etc/gai.conf r,
+ /etc/hosts r,
+ /etc/host.conf r,
+ /etc/nsswitch.conf r,
}
I'm attaching a guest definition that triggers the bug hoping to help you reproduce it. If I can be of more help, please let me know.
| Christian Ehrhardt (paelzer) wrote : | #6 |
Hi,
I was looking into reproducing this to be able to fix&verify then afterwards.
I don't see the messages either with my setup, but I 100% trust Simon to have a correct report.
It all is for name resolution and the profile change is only for read - so it will be safe.
We just need to able to reproduce.
So I just assume we have to find the bit of config triggering the issue (we will need repro steps for SRU anyway after all).
I'd have expected this to be due to libnss-libvirt (https:/
But the reports are on Xenial so that can't be it.
I usually create my most basic test guests with:
uvt-simplestrea
uvt-kvm create --memory 2048 --cpu 4 --password=ubuntu xenial-kernel-test release=xenial arch=amd64 label=daily
And as smb reports that doesn't trigger the issue.
@Simon could you create a guest with uvt as I shown above and check if that guest is free of the issue for you was well?
If yes - we have to compare the guest xml vs your usually used one.
If now - we have to check your local libvirt setup for what triggers this, so you might report any diff in libvirt.conf or (less likely) /etc/libvirt/
| Changed in libvirt (Ubuntu Xenial): | |
| assignee: | nobody → ChristianEhrhardt (paelzer) |
| Changed in libvirt (Ubuntu): | |
| assignee: | nobody → ChristianEhrhardt (paelzer) |
| Matt LaPlante (cybrmatt) wrote : Re: [Bug 1546674] Re: virt-aa-helper Apparmor profile missing rules for name resolution | #7 |
At least in my instance, and based on at least one other reporter's
description, the issue manifests on upgrade of the host to Xenial with
existing guests. If you create new guests in Xenial or newer they may very
well be configured correctly (I really don't know). My interpretation was
that virt-aa-helper added some functionality in Xenial+ which requires this
access, but configs from older versions have not granted it. Or at least
maybe that would make repro easier?
| Christian Ehrhardt (paelzer) wrote : | #8 |
Thanks Matt for your reply.
AFAIK that is what smb already tried in comment #4.
Never the less I checked the upgrade path once more.
With a modified conffile (just an empty line, but to not get the new one as in the bug report here)
And with an old guest created on Xenial.
It was not triggering the apparmor denies.
https:/
That said - I still look out to understand what bit of config triggers that accesses - as a valid repro is usually recommended for the SRU.
In the worst case, we have luck to have you and Simon being able to verify - but I usually at least try to be able to reproduce.
| Simon Déziel (sdeziel) wrote : | #9 |
Thanks Christian, I'll give uvtool a try.
On 2016-10-18 11:56 AM, ChristianEhrhardt wrote:
> Thanks Matt for your reply.
> AFAIK that is what smb already tried in comment #4.
My hosts were fresh installs but the guests xml were carried from an
older version.
> Never the less I checked the upgrade path once more.
> With a modified conffile (just an empty line, but to not get the new one as in the bug report here)
> And with an old guest created on Xenial.
> It was not triggering the apparmor denies.
>
> https:/
> of differences to my guests that would help me to trigger the issue.
>
> That said - I still look out to understand what bit of config triggers that accesses - as a valid repro is usually recommended for the SRU.
> In the worst case, we have luck to have you and Simon being able to verify - but I usually at least try to be able to reproduce.
I also have a colleague that is affected by the same issue.
FYI, I also get denials related to the zvol:
[Tue Oct 18 12:25:29 2016] audit: type=1400 audit(147680792
apparmor="DENIED" operation="open"
profile=
comm="virt-
[Tue Oct 18 12:25:29 2016] audit: type=1400 audit(147680792
apparmor="DENIED" operation="open"
profile=
pid=5432 comm="virt-
fsuid=0 ouid=0
[Tue Oct 18 12:25:29 2016] audit: type=1400 audit(147680792
apparmor="DENIED" operation="open"
profile=
comm="virt-
The zvol read access seems to be entirely optional but maybe it's what's
causing the NSS stuff? Anyway, I'll try to convert the uvtool qcow2 to a
zvol to make sure. I'll report with my findings.
Regards,
Simon
| Simon Déziel (sdeziel) wrote : | #10 |
On 2016-10-18 12:32 PM, Simon Deziel wrote:
> Thanks Christian, I'll give uvtool a try.
>
> On 2016-10-18 11:56 AM, ChristianEhrhardt wrote:
>> Thanks Matt for your reply.
>> AFAIK that is what smb already tried in comment #4.
>
> My hosts were fresh installs but the guests xml were carried from an
> older version.
>
>> Never the less I checked the upgrade path once more.
>> With a modified conffile (just an empty line, but to not get the new one as in the bug report here)
>> And with an old guest created on Xenial.
>> It was not triggering the apparmor denies.
>>
>> https:/
>> of differences to my guests that would help me to trigger the issue.
>>
>> That said - I still look out to understand what bit of config triggers that accesses - as a valid repro is usually recommended for the SRU.
>> In the worst case, we have luck to have you and Simon being able to verify - but I usually at least try to be able to reproduce.
>
> I also have a colleague that is affected by the same issue.
>
> FYI, I also get denials related to the zvol:
>
> [Tue Oct 18 12:25:29 2016] audit: type=1400 audit(147680792
> apparmor="DENIED" operation="open"
> profile=
> comm="virt-
> [Tue Oct 18 12:25:29 2016] audit: type=1400 audit(147680792
> apparmor="DENIED" operation="open"
> profile=
> pid=5432 comm="virt-
> fsuid=0 ouid=0
> [Tue Oct 18 12:25:29 2016] audit: type=1400 audit(147680792
> apparmor="DENIED" operation="open"
> profile=
> comm="virt-
>
> The zvol read access seems to be entirely optional but maybe it's what's
> causing the NSS stuff? Anyway, I'll try to convert the uvtool qcow2 to a
> zvol to make sure. I'll report with my findings.
So the zvol seems to be the smoking gun. Here is what I did after
creating the xenial-kernel-test guest using Christian's instruction for
uvtool:
# Create a zvol
zfs create -V 8G zlxd/xenial-
# Copy the qcow2 data to the zvol
qemu-img convert -O raw \
/var/
/dev/
# Update the guest definition to use the zvol
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source file='/
<target dev='vda' bus='virtio'/>
</disk>
# boot the guest
virsh start xenial-kernel-test
# check for apparmor denial messages
dmesg | tail | grep apparmor
Regards,
Simon
| Christian Ehrhardt (paelzer) wrote : | #11 |
Thanks Simon,
I found another one to trigger which is when failing to start a guest.
I can't reproduce with a working guest, but still it is a way to trigger - although it doesn't seem reliably.
Still I have a system to verify on for myself reporting e.g.
[85681.586318] audit: type=1400 audit(147686513
[85681.586329] audit: type=1400 audit(147686513
I much more like your approach.
I'll prep something to test early next week (on a business trip the next days)
| Christian Ehrhardt (paelzer) wrote : | #12 |
Hi,
unfortunately after a reboot of my host my local reproducibility is gone :-/
I don't know if you could, but would like to ask if one of you think you can verify that in Yakkety or Zesty.
The way the apparmor rules get created changed in >=Yakkety and since we have to start with the devel releases that is the place to go for the first verification.
Still Y&Z are widely the same, so I build for both in a ppa.
I build the suggested fix (along another one) in https:/
It would be great of one of you could test it there.
If none can please let me know so I know I have to try to recreate again somehow.
| Simon Déziel (sdeziel) wrote : | #13 |
On 2016-10-24 11:08 AM, ChristianEhrhardt wrote:
> Hi,
> unfortunately after a reboot of my host my local reproducibility is gone :-/
Strange, mine is reproducible 100% of the time, I'd like a self-fixing
bug too!
> I don't know if you could, but would like to ask if one of you think you can verify that in Yakkety or Zesty.
> The way the apparmor rules get created changed in >=Yakkety and since we have to start with the devel releases that is the place to go for the first verification.
> Still Y&Z are widely the same, so I build for both in a ppa.
>
> I build the suggested fix (along another one) in https:/
> It would be great of one of you could test it there.
>
> If none can please let me know so I know I have to try to recreate again
> somehow.
In 2 to 3 weeks I should be able to try to reproduce on Y or Z so if you
can reproduce before that, please be my guest! Thank again Christian.
| Simon Déziel (sdeziel) wrote : | #14 |
On 2016-10-24 11:08 AM, ChristianEhrhardt wrote:
> Hi,
> unfortunately after a reboot of my host my local reproducibility is gone :-/
>
> I don't know if you could, but would like to ask if one of you think you can verify that in Yakkety or Zesty.
> The way the apparmor rules get created changed in >=Yakkety and since we have to start with the devel releases that is the place to go for the first verification.
> Still Y&Z are widely the same, so I build for both in a ppa.
>
> I build the suggested fix (along another one) in https:/
> It would be great of one of you could test it there.
Thanks for providing this testing PPA. I was able to test the Yakkety
version of your package. With it, I get the following Apparmor messages
(also attached here):
apparmor="DENIED" operation="open"
profile=
comm="virt-
apparmor="DENIED" operation="open" profile=
name="/
requested_mask="wr" denied_mask="wr" fsuid=111 ouid=111
...
apparmor="DENIED" operation="open" profile=
name="/
requested_mask="wr" denied_mask="wr" fsuid=111 ouid=111
So while the /dev/zd0 denial was expected, the /proc/$
ones were not. To address those, I applied the patch attached.
The attachment "aa-libvirt-
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]
| tags: | added: patch |
| Christian Ehrhardt (paelzer) wrote : | #16 |
>
> So while the /dev/zd0 denial was expected, the /proc/$
> ones were not.
Oh those where expected by me, I just would have hoped they are gone now -
see bug 1615550
But I see you found it already.
> To address those, I applied the patch attached.
Yeah I didn't realize in my quick patch that it doesn't only read but
actually rewrite the comm for the debug threads feature.
I also like your owner and pid check - which makes it more secure but still
allowing the needed access.
I think I need an apparmor training :-);
Thanks for your help!
I updated the ppa and it should now also got rid of these apparmor messages
while keeping your hosts fix in place.
Please if possible retest with that one.
I also think once we have confirmed that these both fixes help I'm gonna
submit them upstream.
They don't have to stay a Ubuntu delta forever.
Since you did most IMHO please let me know if you want to do that.
| Simon Déziel (sdeziel) wrote : | #17 |
On 2016-10-27 02:31 AM, ChristianEhrhardt wrote:
> I updated the ppa and it should now also got rid of these apparmor messages
> while keeping your hosts fix in place.
> Please if possible retest with that one.
2.1.0-1ubuntu10
[*]. I appreciate the quick turnaround, thanks.
> I also think once we have confirmed that these both fixes help I'm gonna
> submit them upstream.
> They don't have to stay a Ubuntu delta forever.
> Since you did most IMHO please let me know if you want to do that.
The Ubuntu delta seems pretty big already. I feel that most of it should
be sent upstream. I'll give it a try.
In the meantime, I'll be available for SRU testing.
*: zvols make good storage backends and virt-aa-helper be aware of them.
I'll open a wishlist bug for this.
| Christian Ehrhardt (paelzer) wrote : | #18 |
On Thu, Oct 27, 2016 at 5:44 PM, Simon Déziel <email address hidden>
wrote:
>
> 2.1.0-1ubuntu10
> [*]. I appreciate the quick turnaround, thanks.
I can only return the thanks for a quick turnover.
Thanks for verifying the ppa.
To confirm - does that also confirm that the issues of bug 1615550
(/proc/
The Ubuntu delta seems pretty big already. I feel that most of it should
> be sent upstream. I'll give it a try.
>
Yes, thank you a lot for up-streaming.
In the meantime I marked you as Author on the two patches and Changelog to
properly credit all your work on that.
> In the meantime, I'll be available for SRU testing.
>
I'm waiting for a confirmation on a third apparmor related bug to make an
upload and SRUs from there.
I will notify you here once there is a Zesty or SRU version available for
verification.
| Simon Déziel (sdeziel) wrote : | #19 |
On 2016-11-03 06:01 AM, ChristianEhrhardt wrote:
> To confirm - does that also confirm that the issues of bug 1615550
> (/proc/
Yes, LP: #1615550 is fixed as well.
> The Ubuntu delta seems pretty big already. I feel that most of it should
>> be sent upstream. I'll give it a try.
>>
>
> Yes, thank you a lot for up-streaming.
> In the meantime I marked you as Author on the two patches and Changelog to
> properly credit all your work on that.
I appreciate it, thanks.
| Changed in libvirt (Ubuntu): | |
| status: | Triaged → In Progress |
| Christian Ehrhardt (paelzer) wrote : | #20 |
FYI - Fix pushed to Zesty
@Simon could you give some extra detail on "severe slowdown" as we need it for the SRU template then. And since we lack a clear "steps to reproduce" maybe those as well if you happened to find the important bit to trigger it in the meantime.
| Christian Ehrhardt (paelzer) wrote : | #21 |
What worked last week doesn't have to this week - I ran into an FTBFS - please wait a bit until resolved.
| description: | updated |
| description: | updated |
| description: | updated |
| Simon Déziel (sdeziel) wrote : | #22 |
It's not specific to zvols after all as I just setup a new hypervisor where I hand out host's partitions to the guests like this:
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source file='/dev/sda4'/>
<target dev='vda' bus='virtio'/>
</disk>
This is enough to get virt-aa-helper to try reading /etc/nsswitch.conf, /etc/host.conf and /etc/gai.conf.
| Launchpad Janitor (janitor) wrote : | #23 |
This bug was fixed in the package libvirt - 2.1.0-1ubuntu13
---------------
libvirt (2.1.0-1ubuntu13) zesty; urgency=medium
* drop d/p/ubuntu/
in gnutls has been reverted (LP: #1641615)
* Build depend on gnutls >= 3.5.6-4ubuntu2 to build after the gnutls fix
migrated
-- Christian Ehrhardt <email address hidden> Thu, 17 Nov 2016 08:43:10 +0100
| Changed in libvirt (Ubuntu): | |
| status: | In Progress → Fix Released |
| description: | updated |
| Christian Ehrhardt (paelzer) wrote : | #24 |
Hi,
now that things are in the development release I could go on with this.
I simplified the reproduction steps according to comment #22 and wrote the SRU Template as required.
I prepared the SRU, tested it locally and uploaded for the SRU team to consider it - it just entered the queue waiting to be accepted - so waiting for the SRU Team to come by the queue next time.
| Robie Basak (racb) wrote : | #25 |
I think it's worth nothing that I think landing this SRU (I haven't verified the destination in the binary package) will cause a conffile prompt for any user who has modified usr.lib.
There is a comment with an explanation and an LP bug reference, which helps. Users who don't see the prompt won't be regressed whichever way the default answer falls. So in this case I think it's probably OK, but I would like an ack on this from another SRU team member please.
| Christian Ehrhardt (paelzer) wrote : | #26 |
Thanks Robie,
it does indeed land in "/etc/apparmor.
I didn't think on that - thanks for catching this!
Yet I think the fix is worth it. And for those few that have the ability to manually modify this file it should be no huge challenge - as you outlined the comment and bug# will help.
I would expect that the non interactive default would be to keep whatever modifications they had in place (unless somebody updates with non default options). In the first case they won't regress (just don't get the fix) and in the second case (-o Dpkg::Options:
Waiting for an ack from another SRU Team member together with you ...
| Martin Pitt (pitti) wrote : | #27 |
Not much that we can do about the conffile prompt indeed. However, I disagree with the actual patch. This should include abstractions/
| Changed in libvirt (Ubuntu): | |
| status: | Fix Released → In Progress |
| Christian Ehrhardt (paelzer) wrote : | #28 |
Thanks Martin for your extra insight into apparmor, working on a fresh fix for Zesty now.
Coming back to an SRU once that is tested and migrated.
I'd drop the Ubuntu Review Team subscription til then.
| Christian Ehrhardt (paelzer) wrote : | #29 |
Hi Simon,
I've created a ppa with the modified fix as suggested by Martin.
They work just as good as the former fix, but staying more future proof by using the abstractions.
=> https:/
I know you are usually only on LTS, but do you think you could take a look at that before I upload?
P.S. I've used one ppa for this and bug 1641618 trying to save you some work on those checks.
| Simon Déziel (sdeziel) wrote : | #30 |
Hello Christian,
On 2016-11-24 03:44 AM, ChristianEhrhardt wrote:
> I've created a ppa with the modified fix as suggested by Martin.
I was not sure that pulling such a big abstraction was needed but in
retrospective, Martin's suggestion makes sense. Why is virt-aa-helper
trying to do name resolution is still unclear to me though.
> They work just as good as the former fix, but staying more future proof by using the abstractions.
> => https:/
> I know you are usually only on LTS, but do you think you could take a look at that before I upload?
FYI, I manually applied your 2 patches on Xenial and it addresses the 2
bugs.
> P.S. I've used one ppa for this and bug 1641618 trying to save you some
> work on those checks.
I appreciate it, I'll get back to you with Zesty testing as soon as
possible.
Thanks
| Simon Déziel (sdeziel) wrote : | #31 |
Christian, I'm happy to report that this LP is fixed in Zesty.
| Christian Ehrhardt (paelzer) wrote : | #32 |
Thanks Simon for the confirmation.
Yet FYI I'll reroll the zesty fix to become equal to the one Pitti suggested for the SRU.
I only want to avoid a proliferation of updates and therefore want to group that with some other things which are stalled just a bit. Should be ready to go in 5-10 days and an SRU to Xenial from there as well.
| Launchpad Janitor (janitor) wrote : | #33 |
This bug was fixed in the package libvirt - 2.1.0-1ubuntu14
---------------
libvirt (2.1.0-1ubuntu14) zesty; urgency=medium
* d/p/u/apparmor-
on the apparmor nameservice abstraction to be future proof (LP: #1546674).
* d/p/ubuntu/
virt-aa-helpers profile (LP: #1641618)
* d/p/u/apparmor-
accepted solution (LP: #1633207).
-- Christian Ehrhardt <email address hidden> Thu, 24 Nov 2016 08:06:38 +0100
| Changed in libvirt (Ubuntu): | |
| status: | In Progress → Fix Released |
| Christian Ehrhardt (paelzer) wrote : | #34 |
Reworked fix in Zesty and working, refreshed the SRU upload which is ready and waiting for SRU review now.
Hello Simon, or anyone else affected,
Accepted libvirt into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
| Changed in libvirt (Ubuntu Xenial): | |
| status: | Triaged → Fix Committed |
| tags: | added: verification-needed |
| tags: |
added: verification-done removed: verification-needed |
| Launchpad Janitor (janitor) wrote : | #36 |
This bug was fixed in the package libvirt - 1.3.1-1ubuntu10.6
---------------
libvirt (1.3.1-1ubuntu10.6) xenial; urgency=medium
* d/apparmor/
resolution to virt-aa-helper Apparmor profile (LP: #1546674).
-- Christian Ehrhardt <email address hidden> Tue, 22 Nov 2016 09:39:18 +0100
| Changed in libvirt (Ubuntu Xenial): | |
| status: | Fix Committed → Fix Released |
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 regressions.
Thanks I see that here too.
status confirmed