Regression testing has passed successfully.
zesty-ocata-proposed with stable charms:
==
Totals
==
Ran: 102 tests in 1897.0150 sec.
- Passed: 93
- Skipped: 9
- Expected Fail: 0
- Unexpected Success: 0
- Failed: 0
Sum of execute time for each test: 1011.5607 sec.
zesty-ocata-proposed
This bug was fixed in the package qemu - 1:2.8+dfsg-3ubuntu2.7
---
qemu (1:2.8+dfsg-3ubuntu2.7) zesty; urgency=medium
* d/p/ubuntu/virtio-Fix-no-interrupt-when-not-creating-msi-contro.patch:
on Arm fix no interrupt when not creating msi controller. That fixes
broken networki
** Tags removed: verification-needed-zesty
** Tags added: verification-done-zesty
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719196
Title:
[arm64 ocata] newly created instances are unable to ra
Thanks Christian - I've now verified this. I took a stepwise approach:
1) We originally observed this issue w/ the ocata cloud archive on
xenial, so I redeployed that. I verified that I was still seeing the
problem. I then created a PPA[*] w/ an arm64 build of QEMU from the
ocata-staging PPA, whic
Ok, Zesty actually had an override for the arm test (had to learn the placement
of those for SRUs).
So only up to the verification now.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719196
Title:
As assumed s390x passed now (so a flaky test), and as outlined before armhf we
just have to give up.
Looking at the history an override might be the right thing to do.
Other than that all looks good, waiting for the verify by Sean/Andrew
now.
--
You received this bug notification because you ar
Thanks for the FYI Brian.
I see it in pending-SRUs as it should be.
I added the -needed tags to be "correct".
@Andrew/Sean - could you test proposed and set verified then (assuming
it works like the ppa did)
Odd - this really seems to hit everything, not only LP timeouts.
There are also dep8 reg
I accepted this but Launchpad timed out when the SRU testing comment was
being added.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719196
Title:
[arm64 ocata] newly created instances are unable t
** Changed in: qemu (Ubuntu Zesty)
Status: Incomplete => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719196
Title:
[arm64 ocata] newly created instances are unable to raise
Regression tests on the ppa are good as well, we need to double check the
auto-run on proposed then to ensure this doesn't behave differently on other
arches.
I cleaned up the changelog and UCA backport noise and made a proper SRU for
zesty.
Note: there is currently another SRU in flight (alrea
** Description changed:
+ [Impact]
+
+ * A change in qemu 2.8 (83d768b virtio: set ISR on dataplane
+notifications) broke virtio handling on platforms without a
+controller. Those encounter flaky networking due to missed IRQs
+
+ * Fix is a backport of the upstream fix b4b9862b: virt
Ok, driving that into an SRU then - thanks for verifying.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719196
Title:
[arm64 ocata] newly created instances are unable to raise network
interfaces
I've testing with the same packages listed in comment #28, Confirmed
that this now works..
See attached log
** Attachment added: "novaout.txt"
https://bugs.launchpad.net/libvirt/+bug/1719196/+attachment/4977254/+files/novaout.txt
--
You received this bug notification because you are a memb
I've tested with the packages from the ppa:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2995
qemu:
Installed: 1:2.8+dfsg-3ubuntu2.7~ppa5cloud
qemu-system-arm:
Installed: 1:2.8+dfsg-3ubuntu2.7~ppa5cloud
qemu-system-aarch64:
Installed: 1:2.8+dfsg-3ubuntu2.7~ppa5cloud
Reboot
will test these and report back shortly.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719196
Title:
[arm64 ocata] newly created instances are unable to raise network
interfaces
Status in Ubunt
Since the fix mentioned in the previous comments is already in upstream
QEMU, I'm setting the upstream status to "Fix released".
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
h
Since we wait for the zesty verification I'm setting the status to
incomplete for now.
** Changed in: qemu (Ubuntu Zesty)
Status: In Progress => Incomplete
** Changed in: libvirt (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member
Yeah, the offending patch in RH-BZ 1422413 appeared in qemu 2.8.
So it would make sense to work with newtwon (2.6.1), and pike (2.10), but fail
on Ocata (2.8).
I checked the ppa, in general it seems to work for me, so I'm now waiting for
your verification if that really addresses the issue you a
** Also affects: cloud-archive
Importance: Undecided
Status: New
** Also affects: cloud-archive/pike
Importance: Undecided
Status: New
** Also affects: cloud-archive/ocata
Importance: Undecided
Status: New
** No longer affects: cloud-archive/pike
** Changed in: clo
This appears to be: https://bugzilla.redhat.com/show_bug.cgi?id=1422413
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719196
Title:
[arm64 ocata] newly created instances are unable to raise netwo
Hi,
@admcleod as discussed on IRC I realized Ocata maps to Zesty so that is qemu
2.8.
Therefore the referred patch is released in Artful, but not in Zesty.
I tagged up the bug tasks and provide a fix in [1] to test.
[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2995
** Change
To further reinforce what Christian said, the Newton cloud-archive also
uses virtio-mmio for its address type. (See my comment#15)
Newton XML:
but we have proven this works with Newton. Is it fair to say this could
be attributed to a change i
So,
libvirt knew about some change and picks the right default if you do not
specify it.
But if you (Openstack in this case) specify virtio-mmio as type, then it fails
- is that correct?
The patch in the referred RH-BZ is already in the qemu we have in Artful (and
thereby Ocata).
So if that is
The problem is with virtio-mmio.
https://bugzilla.redhat.com/show_bug.cgi?id=1422413
Instances launched with virtio-mmio on aarch64 will not get DHCP (will
not have a nic)
xml with libvirt 2.5.0
I have updated libvirt-daemon to 3.6.0 on a particul
I spent some time today trying to modify the ocata xml templates
produced in /etc/libvirt/qemu/.xml for each of the
generated instances. Destroying & Undefining the existing instance,
making some changes and redefining the xml, however it appears that nova
regenerates these templates upon instance
Note - be careful if you mean upstream qemu/libvirt (as the bug was filed) or
the packages in Ubuntu (I added tasks for these).
I try to spot both, but will be more on-track for the latter.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
Hi,
I was reading into this after being back from PTO (actually back next monday).
I was wondering as I tested (without openstack) just that last week with Dannf
on the Rally).
And indeed it seems to work for me on Artful (which as we all know is =Ocata in
terms of SW stack).
$ cat arm-template.
Thanks so much for doing that Sean.
Omitting expected changes (uuid, mac address, etc), here's are the
significant changes I see:
1) N uses the QEMU 'virt' model, O uses 'virt-2.8'
2) N and O both expose a pci root, but N also exposed 2 PCI bridges that O does
not.
3) N exposes an additional ser
I was able to gather libvirt XMLs from both Newton and Ocata Instances,
see attached
sfeole@BSG-75:~$ diff xmlocata xmlnewton
1,2c1,2
<
< main type='kvm' id='1'>
---
> ubuntu@lundmark:/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c$
> sudo virsh dumpxml instance-0001
>
4c4
<
Taken from the upgraded hypervisor:
ubuntu@awrep3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$
sudo qemu-system-aarch64 --version
QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3~cloud0)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
ubuntu@awre
Taken from the upgraded hypervisor
ubuntu@aw3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo
qemu-system-aarch64 --version
QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3~cloud0)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
ubuntu@aw3:/var
Today I ran some tests and installed a Newton Deployment on arm64, which
we already know works. I upgraded QEMU and Libvirt on one of the
hypervisors from the xenial-updates/ocata cloud-archive.
See attached notes.
Libvirt - 1.3.1-1ubuntu10.14 -> 2.5.0-3ubuntu5.5~cloud0
QEMU - 1:2.5+dfsg-5ubuntu
32 matches
Mail list logo
