@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 ex
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 on
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
ubuntu@s2lp6
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 subscribe
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
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
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
<
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
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
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
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 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 s
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
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
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: 2.7.0-8232-g.6e1dba4ab-0ubuntu
16 matches
Mail list logo
