Reviewed: https://review.openstack.org/448253
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=8142d526dfd6f4a56dbe382d25cf4110abf57f44
Submitter: Jenkins
Branch:stable/newton
commit 8142d526dfd6f4a56dbe382d25cf4110abf57f44
Author: Matt Riedemann
Date: Tue Mar 21 13:18:
This bug was fixed in the package libvirt - 2.1.0-1ubuntu9.4
---
libvirt (2.1.0-1ubuntu9.4) yakkety; urgency=medium
* no change rebuild to properly pick up all the changes since the last
release to yakkety-updates.
libvirt (2.1.0-1ubuntu9.3) yakkety; urgency=medium
* d/p/ubu
Reviewed: https://review.openstack.org/448242
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=cc495a24656893c94031f491a3fed2bc94fe1850
Submitter: Jenkins
Branch:stable/ocata
commit cc495a24656893c94031f491a3fed2bc94fe1850
Author: Matt Riedemann
Date: Tue Mar 21 13:18:0
@Matt, nova: Can we get some eyes on the Newton and Ocata fix you have
up? It is a pretty severe bug for me since I'm running a
vif_type=ethernet plugin with regular Ubuntu distro libvirt, so I
haven't been able to use any nova sha since early Feb due to this bug.
--
You received this bug notific
This bug was fixed in the package nova - 2:14.0.4-0ubuntu1.2
---
nova (2:14.0.4-0ubuntu1.2) yakkety; urgency=medium
* d/p/libvirt-set-vlan-tag-for-macvtap.patch: Pick dependent patch
for fix for libvirt 1.3.1 compatibility (LP: #1665698).
nova (2:14.0.4-0ubuntu1.1) yakkety; urg
This bug was fixed in the package nova - 2:14.0.4-0ubuntu1.2~cloud0
---
nova (2:14.0.4-0ubuntu1.2~cloud0) xenial-newton; urgency=medium
.
* New update for the Ubuntu Cloud Archive.
.
nova (2:14.0.4-0ubuntu1.2) yakkety; urgency=medium
.
* d/p/libvirt-set-vlan-tag-for-macvtap.
The automated proposed regression check on qemu/libvirt passed and confirmed
that there should be no regression.
Also I was able to test the explicit fix of this vs proposed.
That said - verification-done (libvirt)
** Description changed:
SRU - Nova
[Impact]
OpenStack deployments using vif
Hello Logan, 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.4 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https:/
Uploaded a no change rebuild as version 2.1.0-1ubuntu9.4 to help
properly linking the other linked SRU bug 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/1665698
Title:
/etc/qemu-ifup not al
Since we have one "issue" but two related fixes we had two SRU
Templates, one in the bug description and one in comment #62 - I copied
the one in the comment up and marked them as libvirt/nova so that an SRU
Team member finds this information more easily.
** Description changed:
+ SRU - Nova
+ [I
yakkety-newton test failure was the:
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
tests; I've re-run this independently and it passes OK:
==
Totals
==
Ran: 1 tests in 178.5077 sec.
- Passed: 1
- Skipped: 0
- Expected Fail: 0
- Unexpected Su
yakkety-newton test failure was the:
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
tests; I've re-run this independently and it passes OK:
==
Totals
==
Ran: 1 tests in 178.5077 sec.
- Passed: 1
- Skipped: 0
- Expected Fail: 0
- Unexpected Su
** Tags removed: verification-newton-needed
** Tags added: verification-newton-done
** Tags removed: verification-needed
** Tags added: verification-done
** Tags removed: verification-done
** Tags added: verification-needed
--
You received this bug notification because you are a member of Ubunt
Xenial newton verification testing:
10:00:49 ==
10:00:49 Totals
10:00:49 ==
10:00:49 Ran: 103 tests in 1427. sec.
10:00:49 - Passed: 97
10:00:49 - Skipped: 6
10:00:49 - Expected Fail: 0
10:00:49 - Unexpected Success: 0
10:00:49 - Failed: 0
10:00:49 Sum of execute time for each tes
Yakkety newton verification testing:
09:23:00 ==
09:23:00 Totals
09:23:00 ==
09:23:00 Ran: 103 tests in 1556. sec.
09:23:00 - Passed: 96
09:23:00 - Skipped: 6
09:23:00 - Expected Fail: 0
09:23:00 - Unexpected Success: 0
09:23:00 - Failed: 1
09:23:00 Sum of execute time for each test: 9
For the libvirt portion:
- testing of the issue of this bug itself - done
- in & cross version migration tests - done
- upgrade tests - done
- general QA regression testing - done
That said verification (for the yakkety-libvirt portion, not Nova) -
done.
P.S. James will also add a statement once
Hello Logan, 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.3 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https:/
Hello Logan, or anyone else affected,
Accepted nova into yakkety-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/nova/2:14.0.4-0ubuntu1.1 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wi
Ubuntu SRU Information
[Impact]
OpenStack deployments using vif types `tap`, `ivs`, `iovisor`, `midonet`, and
`vrouter` are unable to boot instances using libvirt 1.3.1 from Ubuntu 16.04
(as used by the Newton Ubuntu Cloud Archive). Note that this impacts the nova
package which is currently in
Due to libvirt/nova combinations this bug does not impact either zesty
or the ocata UCA (marking tasks Invalid).
** Changed in: nova (Ubuntu)
Status: Triaged => Invalid
** Also affects: cloud-archive/newton
Importance: Undecided
Status: New
** Changed in: cloud-archive/newton
** Also affects: nova (Ubuntu)
Importance: Undecided
Status: New
** Changed in: nova (Ubuntu)
Status: New => Triaged
** Changed in: nova (Ubuntu Yakkety)
Status: New => Triaged
** Changed in: nova (Ubuntu)
Importance: Undecided => High
** Changed in: nova (Ubuntu Yakk
Reviewed: https://review.openstack.org/448203
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=a41d265a19b7bcb1af8fc179bf864e00023c6cc6
Submitter: Jenkins
Branch:master
commit a41d265a19b7bcb1af8fc179bf864e00023c6cc6
Author: Matt Riedemann
Date: Tue Mar 21 13:18:08 2017
Fix proposed to branch: stable/newton
Review: https://review.openstack.org/448253
** Changed in: nova/newton
Status: Confirmed => In Progress
** Changed in: nova/newton
Assignee: (unassigned) => Matt Riedemann (mriedem)
--
You received this bug notification because you are a member
Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/448242
** Changed in: nova/ocata
Status: Confirmed => In Progress
** Changed in: nova/ocata
Assignee: (unassigned) => Matt Riedemann (mriedem)
--
You received this bug notification because you are a member of
** Changed in: nova
Importance: Undecided => High
** Changed in: nova/ocata
Status: New => Confirmed
** Changed in: nova/newton
Status: New => Confirmed
** Changed in: nova/newton
Importance: Undecided => High
** Changed in: nova/ocata
Importance: Undecided => High
--
Y
Fix proposed to branch: master
Review: https://review.openstack.org/448203
** Changed in: nova
Status: New => In Progress
** Changed in: nova
Assignee: (unassigned) => Matt Riedemann (mriedem)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
@mriedem
Yes I believe that's correct.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifup not allowed by apparmor
To manage notifications about this bug go to:
https://bug
On Tue, Mar 21, 2017 at 5:19 PM, Matt Riedemann
wrote:
> if libvirt < 1.3.3:
>script.path = '' (as before the change)
> else:
>script.path = None (as in the change)
>
Sounds right to me at least.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
To clarify my understanding of this, per comment 50 and the release note
that went with the change:
https://review.openstack.org/#/c/425637/1/releasenotes/notes/libvirt-
script-with-empty-path-2b49caa68b05278d.yaml
We basically want:
if libvirt < 1.3.3:
script.path = '' (as before the change)
The former SRU was waiting in unapproved still while this SRU was already
prepared here.
I checked with SRU Team and so we rejected the current upload to bundle it with
the next one.
This is now as 2.1.0-1ubuntu9.3 in unapproved queue for yakkety.
--
You received this bug notification because
** Description changed:
+ [Impact]
+
+ * Please do note that this SRU statement is about the libvirt portion
+of it, this is a fix of essentially an API break from Xenial to
+Yakkety. This is independent to any decision to the Openstack context
+discussion about the change to drop sp
FYI on the delay for yakkety: To fix the issue of "" being a nop in
yakkety as well requires the former SRU to complete first. But that is
totally orthogonal to any of the Openstack considerations we did in the
last few comments.
--
You received this bug notification because you are a member of U
(FTR we'll hold bug 1664306 - Newton stable point releases - until this
is resolved one way or the other).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifup not allowed by
Marking Cloud Archive task as Invalid (as the Newton UCA does not have
any libvirt/qemu packages).
** Also affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpa
Adding bug task for Nova as its not currently compatible in
stable/newton with the documented minimum libvirt version of 1.2.1.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu
To summarize:
Before 1.3.3)
- qemu executed the script
- passing: "" got to qemu and it and knew about it being a nop
- not passing anything: means qemu will run the default path /etc/qemu-ifup
Since 1.3.3)
- libvirt executes the script
- passing "": libvirt does not know "" should be a nop and m
I believe the fixes for bug 1649527 fixed things for libvirt >= 1.3.3,
but broke compatibility with the documented baseline version of libvirt
for Nova breaking drivers that use the 'tap' vif type on Ubuntu Xenial.
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
OK so reading the code and reading:
https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
The Newton nova libvirt driver should maintain compatibility with 1.2.1,
with Pike being compatible with 1.2.9 and Queens with 1.3.1 (the current
Xenial version).
** Changed in: cloud-archive
newton and ocata are both:
MIN_LIBVIRT_VERSION = (1, 2, 1)
MIN_QEMU_VERSION = (1, 5, 3)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifup not allowed by apparmor
To manage
Looks like that is defined here:
https://github.com/openstack/nova/blob/stable/newton/nova/virt/libvirt/driver.py#L190-L208
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifu
Add what's the baseline libvirt version compatibility that nova
documents?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifup not allowed by apparmor
To manage notification
Yes it only affects the "tap" vif type.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifup not allowed by apparmor
To manage notifications about this bug go to:
https://bug
http://lists.openstack.org/pipermail/openstack-
dev/2016-December/109080.html and
https://bugs.launchpad.net/nova/+bug/1649527 contain additional info
about the bug and nova fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://
Having read through the history on this bug I'm a little confused;
Newton UCA does not contain any version of libvirt - Newton deployments
on Xenial will use the libvirt version shipped in Xenial itself, which I
think is the same version that will be used in all gates for OpenStack
so I'm not clear
The OpenStack change is not just in Ocata. It was also backported to
Newton. Please note the merged OpenStack patch in #4 is on branch
stable/newton. We need this fix in Newton UCA as well please.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed t
The change in Openstack is in Ocata only, if you run Ocata on Zesty or
Xenial+UCA-Ocata you should be good already with the fix above.
I'm considering to backport it to Yakkety where libvirt is in the broken
state (script is handled by libvirt, but it doesn't know about "" being
meant to be a no-o
Will the libvirt fix be back-ported? We can't effectively use noscript
in OpenStack with any versions missing the fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifup not
This bug was fixed in the package libvirt - 2.5.0-3ubuntu4
---
libvirt (2.5.0-3ubuntu4) zesty; urgency=medium
* d/p/ubuntu/qemu-Allow-empty-script-path-to-interface.patch: in the past
it was possible to have which now fails - fix to match
the old behavior (LP: #1665698)
-
It is still right to fix the empty script execution (#4 in my timeline
post) in the version that is in Zesty. Tests are mostly good, should hit
zesty-proposed soon.
As it is not called on Yakkety in any supported case there is no real
reason to SRU there. And it won't help you as we just clarified
Ok, that confirms my theory of new Openstack vs (too) old libvirt.
But IIRC UCA Newton should be Newton form openstack and virtualization bits
from Yakkety Ubuntu release.
That would be libvirt 2.1.0-1ubuntu9.1
$ lxc launch ubuntu-daily:xenial xenial-uca-newton
$ lxc exec xenial-uca-newton -- add
Also in regard to: "Reading your Deny log again comm="qemu-system-x86".
Hmm, could it be that you run the "new" openstack against the "old" libvirt?
I see you said "with libvirt and non-openstack bits sourced from
cloud-archive", but then I'd have expected the apparmor fail against libvirt -
if a
Sorry for the delay on getting this info.
root@ubuntu-xenial-6494:~# dpkg -l 'libvirt-bin' 'libvirt-daemon-system'
'qemu-kvm'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: upperc
Hi Neil,
1) on what /etc/qemu.ifup (as being the default) actually does
You can look at Debian/Ubuntus script (unchanged since 2013)
https://anonscm.debian.org/cgit/pkg-qemu/qemu.git/tree/debian/qemu-ifup.linux
AFAIK Fedora provides no default, but in most cases it is meant for custom
scripts any
@Christian: what does the default /etc/qemu-ifup do?
Although I'm inclined to accept your argument that my recent change to
Nova was a step in the wrong direction, I'm wondering why it seems to
work (at least in my testing) in practice.
Also, if there was now a change in libvirt to interpret '' a
Note: a backport of the upstream libvirt fix is building here -
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2559
Feel free to test, but I really think we need to understand the dependencies to
consider the apparmor change at the right place first.
--
You received this bug notifi
So we have:
- old openstack: sets script=''
- new openstack: sets nothing
- old libvirt: passes to qemu, which does nothing on ''
- new libvirt: executes script, but can't handle ''
- any libvirt: if nothing is set defaults to /etc/qemu-ifup
Instead of the rule to allow that to qemu, I'd prefer to
Thank you so much for confirming that Logan!
That kind of reset my sanity on understanding the issue.
But I wonder that if one uses cloud archive Ocata he would also get this combo
IMO.
It would use Ocata and the libvirt 2.5 th you also have - just as you do with
your combo.
I don't know why th
I must've done something wrong when originally testing the abstraction
fix. I re-tested based on your advice and it does indeed fix the
problem. The abstraction file that I just tested, which worked, is
http://cdn.pasteraw.com/9u16uk9938mp5t3x530ok0w791nkooc.
Regarding upstream vs. packaged, I wen
Thanks to you already listing an example of a full profile from your
system in the description and a libvirt xml in
http://cdn.pasteraw.com/b3tw4cjefomfi3e9k09hvodrfun85z both seem pretty
standard and includes the abstractions/libvirt-qemu.
Maybe when you added "/etc/qemu-ifup ixr," you added it t
Yep, just to confirm with the suggested workaround applied and
restarting apparmor + rebooting the system it did not work.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifup
On Fri, Feb 24, 2017 at 4:50 PM, Logan V wrote:
> is there an
> additional step necessary after modifying the abstractions/libvirt-qemu
> file with the additional rule? Ie. some command to reload the file? I
> restarted apparmor, libvirt-bin, and nova-compute services and it is
> still failing wi
I also tested hacking in conf.script = "/bin/true" to nova. You
suspected it might fail with apparmor preventing /bin/true execution, I
can confirm that it did indeed fail.
type=AVC msg=audit(1487951915.530:99345): apparmor="DENIED" operation="exec"
profile="libvirt-5ea8f14c-73c8-4e21-9f64-28d60c
I'm having a hard time testing the workaround in #1 -- is there an
additional step necessary after modifying the abstractions/libvirt-qemu
file with the additional rule? Ie. some command to reload the file? I
restarted apparmor, libvirt-bin, and nova-compute services and it is
still failing with th
I tried to puzzle together the timeline on this.
Thanks rbasask for discussing with me to refocus on this issue.
Timeline:
#1 libvirt passed script to qemu, qemu executed
1.3.1 as in Xenial or UCA-Mitaka still do that
But Openstack passed script='' and qemu silently ignored it
#2 libvirt ch
Just found that the report was for 1.3.1-1ubuntu10.6~cloud0 and only
stated to "also apply" to 1.3.1-1ubuntu10.8. By that dropping the
regression-update tag.
** Tags removed: regression-update
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
Hi Christian,
I have not tested the workaround yet. What I have done since I posted
this was tried to narrow it down to the specific nova commit that I
suspected triggered this. To be specific, I am deploying Newton using
OpenStack-Ansible.
OSA pulls nova directly from upstream openstack git sour
I have checked with our support people, but they somewhat calmed me down
that this is not lighting up everywhere (?yet?). So keeping the state as
is for now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bu
Summarizing open questions to stop referring back:
Questions to Logan:
- Did the workaround suggested by Jamie fix it for you?
- Could you also try downgrading to 1.3.1-1ubuntu10.7 (or before) if that get
you working again?
- I have made assumptions so far, but want to confirm what are the releas
Just wanted to make one more thing clear, the libvirt in Xenial (and here in
the bug) is 1.3.1.
That means it is pre
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=9c17d66
So the prereq to need https://review.openstack.org/#/c/425637/ is not given.
Maybe those two bite each other, but I sti
Even with that things are still working correctly for me:
Here the "no" case re-ran with the device being set up externally.
$ tunctl -t manualdevname
$ ip link set manualdevname up
$ ip link set manualdevname master virbr0
For the config:
This case worked p
FYI - while not confirmed I marked it regression-update for now until we know
for sure it is not (to get the right attention).
I also pinged some Cloud Archive people on IRC to take a look.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
** Tags added: regression-update
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifup not allowed by apparmor
To manage notifications about this bug go to:
https://bugs.launc
I think I found the guest definition in the attached raw log, analyzing
...
The important snippet is:
That is my "no" case which should still fail the same way.
Yet I think I need to run that with an externally created tap device to fully
match the Openstack+Openvsw
I was testing various type=ethernet XML configurations.
Cases:
defaultpath =>
emptyattrib =>
noattrib => no script tag at all
The target statement which the error of the known bug refers to is optional, so
add another set of cases with
the same three again without a attribute called "notgt-*"
I'm going off some more testing with that in mind what I documented on
the bug already.
I really want to understand why it hits you now and if this is a SRU-
regression, so here some questions.
Questions to Logan:
- Could you share your guest XML to help me to understand what combination
drives
The function the upstream fix relates to in Openstack is:
def set_vif_host_backend_ethernet_config(conf, tapname):
"""Populate a LibvirtConfigGuestInterface instance
with host backend details for an externally configured
host device.
Before the change it was part of "get_config(self, i
Marking Critical as it is a potential SRU-regression
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifup not allowed by apparmor
To manage notifications about this bug go to
Let me outline on the /etc/qemu-ifup a bit - or at least my understanding of it.
If you happen to run "type=ethernet" networking the script gets to be important.
See https://libvirt.org/formatdomain.html#elementsNICSEthernet
In general this is not recommended for various security reasons (you have
Hi Logan, thank you for your report.
And also tanks Jamie to already provide a workaround for thew apparmor case.
We just SRUed a fix to Xenial to "allow execution of those scripts".
See https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1620407
>From your report I see that you likely have Cl
Thank you for responding. Marking back to New so a member of the cloud
team can take a further look.
** Changed in: libvirt (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchp
I wonder if https://review.openstack.org/#/c/425637/ has broken this on
my version of libvirt by removing the script='' entry, which is maybe
causing qemu to revert to its default of calling /etc/qemu-ifup, which
as we know is not allowed by apparmor.
--
You received this bug notification because
That has been my challenge this morning in figuring this out. As far as
I know, I don't use it or need what it provides. I can't find anything
in /etc/libvirt or even /etc or my Openstack venv that is calling toward
qemu-ifup. I grepped thru /usr looking for 'qemu-ifup' and the only hits
were from
Also thanks for the workaround suggestion. I was looking at adding a
workaround like that to the abstraction earlier but wasn't sure on the
syntax :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/16656
/etc/qemu-ifup is a non-standard command. Can you give details of how
you setup your system to use this?
WORKAROUND: add the following to /etc/apparmor.d/abstractions/libvirt-qemu:
/etc/qemu-ifup ixr,
and restart your VMs.
** Changed in: libvirt (Ubuntu)
Status: New => Incomplete
--
You
84 matches
Mail list logo
