This bug was fixed in the package qemu - 1:4.2-3ubuntu6.9
---
qemu (1:4.2-3ubuntu6.9) focal; urgency=medium
* d/p/ubuntu/define-ubuntu-machine-types.patch: update to fix 15.04 wily
machine type to match how it originally was released (LP: #1902654)
-- Christian Ehrhardt
This bug was fixed in the package qemu - 1:5.0-5ubuntu9.1
---
qemu (1:5.0-5ubuntu9.1) groovy; urgency=medium
* d/p/ubuntu/define-ubuntu-machine-types.patch: update to fix 15.04 wily
machine type to match how it originally was released (LP: #1902654)
-- Christian Ehrhardt
The armhf build is resolved (third was a charm)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1902654
Title:
failure to migrate virtual machines with pc-i440fx-wily type to ubuntu
20.04
To
Thanks for the ping Łukasz,
during RTL pass: reload
/<>/fpu/softfloat.c: In function ‘soft_f64_muladd’:
/<>/fpu/softfloat.c:1535:1: internal compiler error:
Segmentation fault
1535 | }
| ^
that is bug 1890435 which should be flaky in groovy.
I'd really prefer not to switch to
I see that the armhf binaries FTBFS with the latest version. Could
someone take a look at it?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1902654
Title:
failure to migrate virtual machines with
This bug was fixed in the package qemu - 1:5.1+dfsg-4ubuntu1
---
qemu (1:5.1+dfsg-4ubuntu1) hirsute; urgency=medium
* Merge with Debian testing, remaining changes:
Fixes qemu-arm-static Assertion `guest_base != 0' failed (LP: #1897854)
- qemu-kvm to systemd unit
-
On Wed, Nov 18, 2020 at 8:15 PM trya uuum <1902...@bugs.launchpad.net> wrote:
>
> Everything works. I tested migration to focal and groovy.
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Everything works. I tested migration to focal and groovy.
focal: migration fails on 1:4.2-3ubuntu6.8, works on 1:4.2-3ubuntu6.9
groovy: migration fails on 1:5.0-5ubuntu9, works on 1:5.0-5ubuntu9.1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Setting verified tags as I confirmed in GDB and qtree.
@trya - still if there would be a chance to also try the windows guests
on these before we release that would be great.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
GDB check attributes of the wily type in gdb in regard to
virtio-blk-pci
virtio-balloon-pci
virtio-serial-pci
virtio-9p-pci
virtio-rng-pci
migration send-configuration
migration send-section-footer
migration store-global-state
Focal (2.10 is starting at 62)
(gdb) p
First of all - the upgrades to the versions in proposed worked just
fine.
Groovy
root@g-wily:~# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
alsa-ucm-conf apport
The originally reported check via qtree (just looking at
virtio-balloon-pci) now correctly reports true for any_layout.
Focal
dev: virtio-balloon-pci, id "balloon0"
...
bus: virtio-bus
type virtio-pci-bus
dev: virtio-balloon-device, id ""
...
Autopkgtest on systemd/245.4-4ubuntu3.3 (amd64) resolved as well now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1902654
Title:
failure to migrate virtual machines with pc-i440fx-wily type to
Issue in livecd-rootfs/2.694 resolved.
The one in systemd likely as well (known to be flaky) but it is still running.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1902654
Title:
failure to migrate
@trya - do you have a chance to test focal-proposed and groovy-proposed as a
migration target with your windows machines that are affected?
It would be the preferred way to validate this, if you can't please let me know
(then I'll do at least the GDB based attribute check that I did before to
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/393044
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1902654
Title:
failure to migrate virtual
Hello trya, or anyone else affected,
Accepted qemu into groovy-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/qemu/1:5.0-5ubuntu9.1
in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
the fix in 21.04 is in -proposed but will (due to a compiler bug) only fully
release with the 5.1 upload of hopefully next week.
Never the less it is in hirsute-proposed and that is enough to get the SRUs
started.
I uploaded the fix to F/G -unapproved queue
--
You received this bug
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/393488
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/393489
** Merge proposal linked:
FYI: I added the SRU template in preparation and opened three MPs for
the required packaging changes. Waiting for review on those now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1902654
Title:
** Description changed:
+ [Impact]
+
+ * History: Xenial's qemu as once released with a machine type that was
+very broken. This was later on fixed in bug 1621042 but for
+compatibility reasons we need to carry the broken type as well (to e.g.
+allow migrations from guests
Yeah I understand that it is bad i you realize only rather later that it
is a release, but the full name references the Ubuntu release quite
literally.
$ qemu-system-x86_64 -M ? | grep wily
pc-i440fx-wily Ubuntu 15.04 PC (i440FX + PIIX, 1996)
We can't change the actual type names but the
Also thanks for testing the PPA @Trya!
Once this has become an SRU you'll be asked once more to test it, but until
then I need to first fix it in the current Ubuntu release in Development and
then do SRUs.
** Changed in: qemu (Ubuntu)
Status: Triaged => In Progress
--
You received this
Thank you for your time!
The fix from PPA works. It fixes both problems that I described in original
message:
- problem with migration of windows guests from bionic to focal
- problem with cpu feature 'arat' when migrating from focal to bionic
---
on the unrelated note, I wish that I had known
Good - now the compat attributes in Focal for a wily type machine fully
match what was present in Bionic.
@Trya - could I ask you to try qemu - 1:4.2-3ubuntu6.9~ppa3 from PPA
[1] on Focal and do a migration of the kind of windows-guest that
formerly failed onto a Focal target that has that
Changes:
- "any_layout" "off" no more present (all six entries of the bad compat are
gone)
- 2.4 values in "qemu32-x86_64-cpu" "model-id" (matches Bionic now, formerly
had 2.4+2.3 set)
- "migration" "send-configuration" (still present as before and as in Bionic)
- all other implied compat
4.2 misses:
the three known "moved between HW and PC compat
"migration" "send-configuration" "off", user_provided = false, used = true
"migration" "send-section-footer" "off", user_provided = false, used = true
"migration" "store-global-state" "off", user_provided = false, used = true
4.2 has
Bionic
$ gdb /usr/bin/qemu-system-x86_64
(gdb) handle SIGUSR1 noprint nostop
(gdb) b machine_register_compat_props
(gdb) run -m 128 -M pc-i440fx-wily,accel=kvm --nodefaults --nographic --monitor
stdio -device virtio-balloon-pci,id=balloon0
(gdb) fin
(gdb) set $c=(GList *)global_props
(gdb)
$ gdb /usr/bin/qemu-system-x86_64
(gdb) handle SIGUSR1 noprint nostop
(gdb) b qemu_init_main_loop
(gdb) run -m 128 -M pc-i440fx-wily,accel=kvm --nodefaults --nographic --monitor
stdio -device virtio-balloon-pci,id=balloon0
Thread 1 "qemu-system-x86" hit Breakpoint 3, qemu_init_main_loop
Problem:
- initial broken as HW_COMPAT_2_4 + pc_compat_2_3
- then some options moved between HW_COMPAT_2_4 <-> pc_compat_2_3
- HW_COMPAT_WILY needed to be HW_COMPAT_2_4 + some things that moved to
pc_compat_2_3
- when this was further reworked in later releases this was partially lost
and is
Oh I forgot - false is actually the value we thought to be wrong according to
the report.
But things seem right to be "false" by just looking at the Focal code.
I think I need to look at the very same in Bionic where it should end up
being "true" according to the tests done so far.
--
You
$ gdb /usr/bin/qemu-system-x86_64
(gdb) run -m 128 -M pc-i440fx-wily,accel=kvm --nodefaults --nographic --monitor
stdio -device virtio-balloon-pci,id=balloon0
(gdb) handle SIGUSR1 noprint nostop
/*
* Global property defaults
* Slot 0: accelerator's global property defaults
* Slot 1: machine's
At init of pc_i440fx_wily_machine_options the referred compat is ok:
compat_props_add(m->compat_props, hw_compat_2_3, hw_compat_2_3_len);
It contains any_layout off for virtio-balloon-pci
(gdb) p hw_compat_2_3[1]
$7 = {driver = 0x55ea725c "virtio-balloon-pci", property = 0x55ea2c91
The type does:
1197 compat_props_add(m->compat_props, hw_compat_2_3, hw_compat_2_3_len);
Defined as:
198 GlobalProperty hw_compat_2_3[] = {
199 { "virtio-blk-pci", "any_layout", "off" },
200
BTW all of this is doable without libvirt via:
$ qemu-system-x86_64 -m 128 -M pc-i440fx-wily,accel=kvm --nodefaults
--nographic --monitor stdio -device virtio-balloon-pci,id=balloon0
(qemu) info qtree
You can find the same "any_layout = false" at the device
dev: virtio-balloon-pci, id
I spawned "pc-i440fx-wily" (which is actually xenial in very early days
due to a bug back then) guests on Bionic and Focal.
New types like Bionic and Focal all have "any_layout = true" in all slots.
Which is reasonable as they all are post 2.3 where this was later introduced as
new default.
The following minimal steps can be used to test:
$ cat > layout-test.xml << EOF
layout-test
256
1
hvm
/usr/bin/kvm-spice
EOF
$ virsh define layout-test.xml
$ virsh start layout-test
$ virsh qemu-monitor-command layout-test --hmp info qtree | grep
I have checked further other than the error suggests it isn't console
but "virtio-balloon-pci" that changes and that is indeed known to be
rather different in windows - that could explain why they behave
different.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Thanks for this good report!
And also thanks for providing the workaround for anyone else running into this.
The old types should (tm) not change due to the compat layers that on
any change ensure that former types have the old values set. That is an
issue within qemu.
I don't see yet why that
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1902654
Title:
failure to migrate virtual machines with pc-i440fx-wily type
Forgot to mention that we managed to get around this bug by creating a
libvirt hook that checks XML during migration and adds following
arguments to qemu process for pc-i440fx-wily guests:
-global virtio-balloon-pci.any_layout=on -global virtio-serial-
pci.any_layout=on
--
You received this bug
41 matches
Mail list logo
