Local creation with a apparmor seclabel fails the same as the migration,
so we can ignore all "migration specials".
To test that add:
to /usr/share/uvtool/libvirt/template.xml
And run uvt-kvm create again
--
You received this bug notification because you are a member of Ubuntu
Bugs,
This bug was fixed in the package libvirt - 2.1.0-1ubuntu9.1
---
libvirt (2.1.0-1ubuntu9.1) yakkety; urgency=medium
* d/p/u/apparmor-fix-other-seclabels.patch fixes an issue parsing non
apparmor security labels (LP: #1633207).
-- Christian Ehrhardt
Since there was no reply to verify in a week I felt I had to clear the
queue and tested it myself again.
@bugproxy: In general - a.k.a. for next time - I'd really like to have
3rd party verification. Not to save me the 15 minutes, but to make sure
it really addresses your issue and get further
Hello bugproxy, or anyone else affected,
Accepted libvirt into yakkety-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/libvirt/2.1.0-1ubuntu9.1 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
Prepared SRU Template and Uploaded into the (Y) SRU review queue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1633207
Title:
VM fails to start with dac security driver added
To manage
** Description changed:
+ [Impact]
+
+ * Due to an upstream change in libvirt 2.0 users of libvirt >=2.0
+(that is >=Yakkety) can't use non apparmor security labels anymore.
+
+ * That means old guest definitions that should still work fail to start
+now
+
+ * The issue was in
The refreshed upstream accepted fix is now available in Zesty as 2.1.0-1ubuntu14
With that ready now preparing the SRU into Yakkety.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1633207
Title:
VM
FYI - The backport SRU to Yakkety will have to wait until we have a
upstream accepted solution.
** Also affects: libvirt (Ubuntu Yakkety)
Importance: Undecided
Status: New
** Changed in: libvirt (Ubuntu Yakkety)
Status: New => Triaged
** Changed in: libvirt (Ubuntu Yakkety)
This bug was fixed in the package libvirt - 2.1.0-1ubuntu13
---
libvirt (2.1.0-1ubuntu13) zesty; urgency=medium
* drop d/p/ubuntu/fix-ftbfs-for-gnutls-3-5-6.patch as the offending change
in gnutls has been reverted (LP: #1641615)
* Build depend on gnutls >= 3.5.6-4ubuntu2 to
FYI - v2 of the patch in discussion upstream
https://www.redhat.com/archives/libvir-list/2016-November/msg00991.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1633207
Title:
VM fails to start
What worked last week doesn't have to this week - I ran into an FTBFS -
please wait a bit until resolved.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1633207
Title:
VM fails to start with dac
Unfortunately upstream response is super slow on this.
I think the patch is right and therefore I'm willing to put it into zesty as
being a dev release in development.
That will also give us more coverage if there is anything we might have missed.
That said pushed it to Zesty now the way it was
** Changed in: libvirt (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1633207
Title:
VM fails to start with dac security driver added
To manage
Thank you a lot for verifying the ppa.
Since this isn't critically urgent I'll wait with a fix upload to the
package until the upstream discussion settled (better than to revert in
two weeks again).
Once https://www.redhat.com/archives/libvir-list/2016-October/msg01297.html
followed in November
FYI discussion started at https://www.redhat.com/archives/libvir-
list/2016-October/msg01297.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1633207
Title:
VM fails to start with dac security
Thanks a lot Guido for your feedback - it helped me better "reading the
case".
I see the same issue throughout latest libvirt upstream as of today.
So I'm gonna submit the fix upstream for discussion as I could easily overlook
something here.
E.g. parseOpaque is quite close as it is passed up to
dfbc9a83 was necessary since libvirt changed the paths of the monitor
socket in a89f05ba8df095875f5ec8a9065a585af63a010b. We had to switch
from VIR_DOMAIN_DEF_PARSE_INACTIVE to active since we need the domain id
(ctl->def->id) as it is part of the socket path now. It would probably
o.k. to skip
I subscribed agx, the author of the conflicting patch upstream.
Questions:
agx - Could you please comment on my finding?
agx - Please describe your case that let you write dfbc9a83?
IBM - I don't think it helps yet, but if you can please try to verify the ppa I
provide at
I made an experimental fix available at
https://launchpad.net/~paelzer/+archive/ubuntu/libvirt-bug-1633207
In the pure aa-helper tests that continues to work with all my usual minor
tests and it fixes dac and dac+apparmor label issues.
But I seem to run into issues with doing full guests:
TL;DR:
- a dac sec label is parsed
- it has no label, but due to a bug it searches one
- label can't be found for an inactive domain
- exit with Error
- expected fix is reverting part of dfbc9a83
Debug-Analysis:
Interesting part of the call chain:
get_definition -> virDomainDefParseString ->
Again at:
sudo virsh start yakkety-doubleseclabel
error: Failed to start domain yakkety-doubleseclabel
error: internal error: cannot load AppArmor profile
'libvirt-8746b00d-aad1-4346-8784-2d4331465153'
In the log I found the related:
Okt 27 13:45:50 horsea libvirtd[10370]: internal error: Child
After a bit of twiddling I found a somewhat reasonable repro with the
virt-aa-helper tool.
diff -Naur yakkety-sec-dac.xml yakkety-sec-nodac.xml
--- yakkety-sec-dac.xml 2016-10-27 14:32:39.565995840 +
+++ yakkety-sec-nodac.xml 2016-10-27 14:32:45.097973456 +
@@ -60,6 +60,5 @@
Once more confirmed that it worked in Xenial - adding regression-release
** Tags added: regression-release
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1633207
Title:
VM fails to start with dac
Ok, I found why those templates didn't get on my BM test system to begin with.
They were conffiles and I had none of them modified, but some more in the same
directories.
So while not that clear still the usual "protect custom conffiles" mechanism
that blocked me.
A full purge + manual extra
Three way check on fresh installs:
dpkg -S $((find /etc/apparmor.d/ -name '*libvirt*' && find /etc/apparmor.d/
-name '*TEMPLATE*' )| xargs) | sort
X Y
X-Y upgrade
While debugging I found the first level of oddities that I'll continue
on and hopefully gives us a solution (or at least eliminate one
roadblock).
I think I found that things work with the error described in the bug on
Xenial->Yakkety upgraded systems. But on all others I see:
error: unsupported
I realized that part of my former verification was caused by the kvm-in-
lxd env I use to avoid needing too much metal. So I retried on x86 again
as these code paths shouldn't be arch specific at all. And now I was
able to recreate on x86 as well.
The summary looks like this now:
* - xenial -
Ha - got my container trick working again.
So testing on Yakkety, adding the double seclabel.
Finally - able to reproduce - yeah!
Looking deeper into that now...
** Changed in: libvirt (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a
2nd level kvm failed me as well :-/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1633207
Title:
VM fails to start with dac security driver added
To manage notifications about this bug go to:
I have to report that my usual trick to run KVM from inside a container
doesn't work the same way on ppc64el. It might take a while for me to
get a Yakkety ppc64el BM system, so more than before I'm dependent on
you reporting the extended logs as I requested.
--
You received this bug
Thanks satheera for the reply.
I wonder why it works for me than as I explicitly tested ppc as well just as
you do ... ?
It works fine on x86 with Yakkety.
As well as fine on ppc64el with Xenial.
I don't have a Yakkety around yet and machines are scarce.
I assume the xml is how avocado creates
Hi,
I tested a simple guest as created with uvt-kvm:
$ uvt-kvm create --memory 2048 --cpu 4 --password=ubuntu
paelzer-yakkety-test-libvirt release=yakkety arch=ppc64el label=daily
plus the two lines:
That works on:
Xenial: ok
Yakkety: ok
I did the same on ppc64el, but only had a Xenial
32 matches
Mail list logo
