It would appear that this bug is once again causing problems with some of our
automated testing.
S390x KVM deployments are failing for Focal. When attempting to investigate a
big I found that it is indeed this bug.
Our MAAS Server is Version:
maas:
Installed:
Also, please note that the libvirt version did not change on the s390x
Virtual Machine Host.
On S390x VM Host
ii libvirt-clients 4.0.0-1ubuntu8.14
s390xPrograms for the libvirt library
ii libvirt-daemon4.0.0-1ubuntu8.14
After looking at the original description it does appear that I upgraded
maas since originally filing this bug, that upgrade was done to
workaround a different issue which was resolved since 2.6.1
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
Here is my pkg versions as things are now.
maas:
Installed: 2.6.2-7841-ga10625be3-0ubuntu1~18.04.1
Candidate: 2.6.2-7841-ga10625be3-0ubuntu1~18.04.1
On the s390x Lpar, Bionic, Linux s2lp6 4.15.0-74-generic #84-Ubuntu SMP
Thu Dec 19 08:05:42 UTC 2019 s390x s390x s390x GNU/Linux
To add to this discussion today, I noticed that some of the maas
deployments for s390x are working. I took a look and I was able to
successfully deploy 19.10/18.04/20.04
I have not changed anything on the MAAS host, I have not upgraded / altered
any packages.
I have not upgraded libvirt,
The
@paelzer, Aye and thanks for your comment #27 , I was already aware of
that, and yes that does work. However, it's a shoddy workaround at best
and if this is going to be a solution to be presented to a customer MAAS
would be scoffed at.
I'm aware of the issue at hand here, I think the problem
Please note# https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1790901
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM machine after initial deploy
I tried the above workaround mentioned by Christian last week also, I
did not mention that in comment #6.
I tried using the boot order configuration as outlined in the
example(comment #9)
After the machine deploys, the same symptom occurs. So we are sort of
stuck again still.
Domain s2lp6g001
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
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
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 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
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
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
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 -
16 matches
Mail list logo
