VMs go to 100% CPU after live migration from Trusty to Bionic

Bug #1826051 reported by Corey Melanson on 2019-04-23
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
qemu (Ubuntu)
Undecided
Unassigned

Bug Description

We are seeing issues after live migrating a KVM VMs from a Trusty to Bionic where about 1 in 10 VMs go to 100% cpu and become unresponsive. When this happens, virsh returns error code 0, and there are no logs in /var/log/libvirt/qemu, /var/log/syslog or dmesg to indicate an error/issue.

We expect that the VM should migrate successfully, as it's a supported option to go +2 LTS releases according to https://wiki.ubuntu.com/QemuKVMMigration#Support_Matrix. The VM in this instance was also running Trusty.

Unfortunately we are unable to reproduce this on demand, and it seems random whether a VM will successfully live migrate or not. We also tried migrating to Bionic 18.04.0 with 4.15.0-43-generic with the same results.

Please let me know if there is further information you require to look into this.

Thank you,
Corey Melanson

Source hypervisor:
OS: Ubuntu 14.04.5
Kernel: Linux kvm-207-38 3.13.0-157-generic #207-Ubuntu SMP Mon Aug 20 16:44:59 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Hardware: HP ProLiant DL360 Gen9
CPU: Dual Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz
Packages:
$ dpkg -l | egrep '(qemu|libvirt|linux-image)'
ii ipxe-qemu 1.0.0+git-20131111.c3d1e78-2ubuntu1.1 all PXE boot firmware - ROM images for qemu
ii libvirt-bin 1.2.2-0ubuntu13.1.27 amd64 programs for the libvirt library
ii libvirt0 1.2.2-0ubuntu13.1.27 amd64 library for interfacing with different virtualization systems
ii linux-image-3.13.0-157-generic 3.13.0-157.207 amd64 Linux kernel image for version 3.13.0 on 64 bit x86 SMP
ii linux-image-extra-3.13.0-157-generic 3.13.0-157.207 amd64 Linux kernel extra modules for version 3.13.0 on 64 bit x86 SMP
ii python-libvirt 1.2.2-0ubuntu2 amd64 libvirt Python bindings
ii qemu-keymaps 2.0.0+dfsg-2ubuntu1.44 all QEMU keyboard maps
ii qemu-kvm 2.0.0+dfsg-2ubuntu1.44 amd64 QEMU Full virtualization
ii qemu-system-common 2.0.0+dfsg-2ubuntu1.44 amd64 QEMU full system emulation binaries (common files)
ii qemu-system-x86 2.0.0+dfsg-2ubuntu1.44 amd64 QEMU full system emulation binaries (x86)
ii qemu-utils 2.0.0+dfsg-2ubuntu1.44 amd64 QEMU utilities

Destination hypervisor:
OS: Ubuntu 18.04.2
Kernel: Linux kvm-207-39 4.18.0-15-generic #16~18.04.1-Ubuntu SMP Thu Feb 7 14:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Hardware: HP ProLiant DL360 Gen9
CPU: Dual Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz
Packages:
$ dpkg -l | egrep '(qemu|libvirt|linux-image)'
ii ipxe-qemu 1.0.0+git-20180124.fbe8c52d-0ubuntu2.2 all PXE boot firmware - ROM images for qemu
ii ipxe-qemu-256k-compat-efi-roms 1.0.0+git-20150424.a25a16d-0ubuntu2 all PXE boot firmware - Compat EFI ROM images for qemu
ii libvirt-bin 4.0.0-1ubuntu8.6 amd64 programs for the libvirt library
ii libvirt-clients 4.0.0-1ubuntu8.6 amd64 Programs for the libvirt library
ii libvirt-daemon 4.0.0-1ubuntu8.6 amd64 Virtualization daemon
ii libvirt-daemon-system 4.0.0-1ubuntu8.6 amd64 Libvirt daemon configuration files
ii libvirt0:amd64 4.0.0-1ubuntu8.6 amd64 library for interfacing with different virtualization systems
ii linux-image-4.18.0-15-generic 4.18.0-15.16~18.04.1 amd64 Signed kernel image generic
ii qemu-block-extra:amd64 1:2.11+dfsg-1ubuntu7.10 amd64 extra block backend modules for qemu-system and qemu-utils
ii qemu-kvm 1:2.11+dfsg-1ubuntu7.10 amd64 QEMU Full virtualization on x86 hardware
ii qemu-system-common 1:2.11+dfsg-1ubuntu7.10 amd64 QEMU full system emulation binaries (common files)
ii qemu-system-x86 1:2.11+dfsg-1ubuntu7.10 amd64 QEMU full system emulation binaries (x86)
ii qemu-utils 1:2.11+dfsg-1ubuntu7.10 amd64 QEMU utilities

Process running at 100% after migration:
oneadmin 9483 1 99 18:07 ? 12:03:30 qemu-system-x86_64 -enable-kvm -name guest=one-10837,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-one-10837/master-key.aes -machine pc-i440fx-trusty,accel=kvm,usb=off,dump-guest-core=off -cpu Westmere,pcid=on -m 32768 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid aa0038b1-876e-45eb-96a7-2df9b6fb32ea -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-one-10837/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -object secret,id=virtio-disk0-secret0,data=redacted,keyid=masterKey0,iv=redacted,format=base64 -drive file=rbd:ssd/one-457-10837-0:id=libvirt:auth_supported=cephx\;none:mon_host=ceph-mon-1\:6789\;ceph-mon-2\:6789\;ceph-mon-3\:6789,file.password-secret=virtio-disk0-secret0,format=raw,if=none,id=drive-virtio-disk0,cache=writeback,throttling.bps-total=52428800,throttling.iops-total=500 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/srv/datastores/107/10837/disk.1,format=raw,if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=36,id=hostnet0,vhost=on,vhostfd=38 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=02:23:0a:3e:42:6a,bus=pci.0,addr=0x3 -vnc 0.0.0.0:10837 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on

/var/log/libvirt/qemu/one-10837.log:
2019-04-03 18:07:40.544+0000: starting up libvirt version: 4.0.0, package: 1ubuntu8.6 (Christian Ehrhardt <email address hidden> Fri, 09 Nov 2018 07:42:01 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.10), hostname: kvm-207-39
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name guest=one-10837,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-one-10837/master-key.aes -machine pc-i440fx-trusty,accel=kvm,usb=off,dump-guest-core=off -cpu Westmere,pcid=on -m 32768 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid aa0038b1-876e-45eb-96a7-2df9b6fb32ea -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-7-one-10837/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -object secret,id=virtio-disk0-secret0,data=redacted,keyid=masterKey0,redacted,format=base64 -drive 'file=rbd:ssd/one-457-10837-0:id=libvirt:auth_supported=cephx\;none:mon_host=ceph-mon-1\:6789\;ceph-mon-2\:6789\;ceph-mon-3\:6789,file.password-secret=virtio-disk0-secret0,format=raw,if=none,id=drive-virtio-disk0,cache=writeback,throttling.bps-total=52428800,throttling.iops-total=500' -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/srv/datastores/107/10837/disk.1,format=raw,if=none,id=drive-ide0-0-0,readonly=on -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=36,id=hostnet0,vhost=on,vhostfd=38 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=02:23:0a:3e:42:6a,bus=pci.0,addr=0x3 -vnc 0.0.0.0:10837 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
2019-04-03T20:07:41.740926Z qemu-system-x86_64: terminating on signal 15 from pid 3945 (/usr/sbin/libvirtd)
2019-04-03 20:07:41.941+0000: shutting down, reason=destroyed

/var/log/syslog from that time period:
Apr 3 18:07:40 kvm-207-39 systemd[1]: Started Session 33 of user oneadmin.
Apr 3 18:07:40 kvm-207-39 systemd-networkd[1155]: one-10837-0: Gained carrier
Apr 3 18:07:40 kvm-207-39 networkd-dispatcher[1106]: WARNING:Unknown index 28 seen, reloading interface list
Apr 3 18:07:40 kvm-207-39 kernel: [ 610.162987] onebr.66: port 2(one-10837-0) entered blocking state
Apr 3 18:07:40 kvm-207-39 kernel: [ 610.162990] onebr.66: port 2(one-10837-0) entered disabled state
Apr 3 18:07:40 kvm-207-39 kernel: [ 610.163084] device one-10837-0 entered promiscuous mode
Apr 3 18:07:40 kvm-207-39 kernel: [ 610.163301] onebr.66: port 2(one-10837-0) entered blocking state
Apr 3 18:07:40 kvm-207-39 kernel: [ 610.163303] onebr.66: port 2(one-10837-0) entered forwarding state
Apr 3 18:08:07 kvm-207-39 systemd[1]: Started Session 34 of user oneadmin.
Apr 3 18:08:11 kvm-207-39 systemd[1]: Started Session 35 of user oneadmin.

Corey Melanson (cmelanson) wrote :
Corey Melanson (cmelanson) wrote :
Corey Melanson (cmelanson) wrote :
Corey Melanson (cmelanson) wrote :

Hi Corey,
that is bad news - I literally migrated 10s of thousands of VMs T->B now and newer hit that so far.

A few questions to get an initial hold on this:
1. is libvirt or the actual guest (qemu) going to 100% CPU?
2. can you provide an libvirt XML of one of the failing guests (to check if they have anything special)
3. are one or all thready going insane on 100% CPU, maybe check with
   $ pidstat -t -p <pid-that-hogs> 5 10
4. If it is at 100% it must spin "somewhere" could you take a look with a few tools:
   strace -f -r -T -p <pid-that-hangs>
   If you can install `perf` that would be great as well.

Changed in qemu (Ubuntu):
status: New → Incomplete
Corey Melanson (cmelanson) wrote :

Hi Christian,

Yeah it's an unfortunate and annoying issue I can't figure out :-(

So it's the qemu process that goes to 100% after live migration, and the guest becomes unresponsive via VNC console and over the network. Libvirt seems fine, and the live migration appears to complete successfully as "virsh migrate --live" returned error code 0 and the VM shows as "running" in virsh list.

I have attached the "virsh dumpxml" output from a different dead VM along with the pidstat and strace output. I can run "perf" if you let me know what options you need.

Thanks for your help,
Corey Melanson

Corey Melanson (cmelanson) wrote :
Corey Melanson (cmelanson) wrote :
Download full text (3.5 KiB)

Thanks for the data so far,
the guest does not look very "special" other than the ceph storage and that looks fine at a first glance.

It seems 4 of the 6 guest vCPU threads are what is in this 100% hog.
None of the other helper threads seems busy.
Of these vCPU threads we see that they are about 50% in host-kernel and 50% guest and not much more.
I wonder what they are doing ...

We can see in the strace that the vCPUs never leave to userspace (which they'd do for heavy exits).
Instead those seem to really just spin between kernel and guest as seen in the cpu utilization.
   ioctl(34, KVM_RUN, 0 <unfinished ...>

Every now and then we can see most of the other threads to show up on Futex locks.
Sometimes a few ceph/rbd related messages also show up like
  read(25, 0x7fe9f8006ec0, 4096) = -1 EAGAIN (Resource temporarily unavailable) <0.00001
Both could be a red herring or not - no message is clear enough to point that out yet.

So for the next step the guest still seems to do soemthing (even if it might spin in a bad loop) and regularly exits to the host kernel.
Lets try to find where that is, once you have a guest in that situation you might:
1. check which kind of host exits we see
2. check where the guest is atm

If the affected guest is the only one for #1 you can e.g. run perf kvm stat like:
  $ sudo perf kvm stat --live
But since you know the PID of one of the vCPU threads that we are interested in this would be better (also add -d 30 for some more reliability in the numbers):
  $ sudo perf kvm stat --live -d 30 --vcpu 0 --pid=<pid-of-one-vcpu-thread>
Let it run for a while and then report what exits you are seeing in your case. An example of an idle guest is below.

Maybe also worth could be the KVM tracepoints, you can check that (globally) with:
  $ sudo perf stat -e 'kvm:*' sleep 30s

[2]: has more general info on perf counters with KVM e.g. how to get kallsysms and modules files.
For some of these actions (to get more details) you might want to get a dbgsym of the guest kernel [1] has more about that.
For your #2 you could maybe run:

# Record data to file (on Host)
$ sudo perf kvm --host --guest --guestkallsyms=kallsyms --guestvmlinux=debug-kernel/usr/lib/debug/boot/vmlinux-5.0.0-13-generic --guestmodules=modules record
# Host info
$ sudo perf kvm --host report -i perf.data.kvm
$ sudo perf kvm --guest report -i perf.data.kvm

In general it would help to clean results by isolating the host that the affected guest runs on to only run this guest and nothing else - not sure how doable that is for your case thou :-/

Lets see from here what we get ...

[1]: https://wiki.ubuntu.com/Kernel/CrashdumpRecipe#Inspecting_the_crash_dump_using_crash
[2]: https://www.linux-kvm.org/page/Perf_events#Recording_events_for_a_guest

Example idle guest exits:
Analyze events for pid(s) 14470, VCPU 0:

             VM-EXIT Samples Samples% Time% Min Time Max Time Avg time

           MSR_WRITE 1585 75.55% 0.00% 0.00us 7.83us 0.85us ( +- 2.09% )
                 HLT 473 22.55% 100.00% 0.00us 100138.85us 58658.26us ( +- 2.88% )
            MSR_READ 30 1.43% 0.00% ...

Read more...

@James/Corey: I subscribed you in case you have heard on other places about migrations from trusty->bionic level qemu (with ceph) that end up with a stuck guest that has some vCPUs on 100% and no more responds.

Corey Melanson (cmelanson) wrote :
Download full text (13.6 KiB)

Hi Christian,

I cleared off the host leaving just the hung VM on it before running those commands. Because the VM is hung up, I'm not able to grab /proc/kallsyms and /proc/modules from it. I tried grabbing it from another VM using the same image/kernel, but it has kernel page tables isolation enabled, so I presume that's why it hasn't worked properly. If this output it critical, I would need to stage some VMs and grab those files and hope they fail live migration.

Below is the output you requested. This is new to me, so hopefully it's correct.

Thank you,
Corey Melanson

$ sudo perf kvm stat --live
Analyze events for all VMs, all VCPUs:

             VM-EXIT Samples Samples% Time% Min Time Max Time Avg time

           MSR_WRITE 269190 38.63% 42.74% 0.65us 855.99us 1.60us ( +- 2.06% )
    PREEMPTION_TIMER 222622 31.95% 28.06% 0.61us 946.08us 1.27us ( +- 2.46% )
   PENDING_INTERRUPT 203862 29.25% 29.11% 0.62us 799.59us 1.44us ( +- 2.57% )
  EXTERNAL_INTERRUPT 1209 0.17% 0.09% 0.43us 123.06us 0.78us ( +- 13.36% )

Total Samples:696883, Total events handled time:1009576.31us.

$ sudo perf kvm stat live -d 30 --vcpu 0 --pid=53454
Analyze events for pid(s) 53454, VCPU 0:

             VM-EXIT Samples Samples% Time% Min Time Max Time Avg time

           MSR_WRITE 2227999 50.05% 54.64% 0.64us 1228.11us 1.78us ( +- 0.74% )
   PENDING_INTERRUPT 1112941 25.00% 25.20% 0.61us 1080.49us 1.64us ( +- 1.10% )
    PREEMPTION_TIMER 1109447 24.92% 20.13% 0.63us 1017.27us 1.32us ( +- 1.07% )
  EXTERNAL_INTERRUPT 1350 0.03% 0.03% 0.44us 366.12us 1.56us ( +- 28.55% )

Total Samples:4451737, Total events handled time:7264173.95us.

$ sudo perf stat -e 'kvm:*' sleep 30s

 Performance counter stats for 'sleep 30s':

                 0 kvm:kvm_entry
                 0 kvm:kvm_hypercall
                 0 kvm:kvm_hv_hypercall
                 0 kvm:kvm_pio
                 0 kvm:kvm_fast_mmio
                 0 kvm:kvm_cpuid
                 0 kvm:kvm_apic
                 0 kvm:kvm_exit
                 0 kvm:kvm_inj_virq
                 0 kvm:kvm_inj_exception
                 0 kvm:kvm_page_fault
                 0 kvm:kvm_msr
                 0 kvm:kvm_cr
                 0 kvm:kvm_pic_set_irq
                 0 kvm:kvm_...

Download full text (4.0 KiB)

"This is new to me, so hopefully it's correct."

We are just wandering together the road of "hopefully getting ideas here to actually look for", your active help on this is great!

Ok, so we see that PREEMPTION_TIMER and PENDING_INTERRUPT are high.
This almost seems as if a IRQ shall be delivered but isn't properly cleared/handled by the guest.
So it forever would spin as:
1. IRQ is pending -> exit PENDING_INTERRUPT
2. Use preemption timer for immediate VMExit [1]
3. Guest receives and mis-handles IRQ (MSR writes ont hat path)
4. guest leaves IRQ disabled area, but IRQ is still pending (or there is an infinite amount or anything), goto #1

I'd have hoped that the further counters would help a bit more but they are all zero which seems wrong. At least the exits should somewhat match. I rechecked the command that I told you and yes (sorry), in the form I added it it would only probe for the sleep command which obviously doesn't do anything.
But since you cleared the affected host you are good to just add -a to check globally for KVM counters.
 $ sudo perf stat -a -e 'kvm:*' sleep 30s
That should give you some numbers here as well.

I don't have a great idea yet what it is, but for the sake of "trying things" you might flip the IRQ delivery mechanism on the target system before migrating there. You could switch from the preemption_timer based mode to the older exit path with:
  kvm-intel.preemption_timer=0
On your kernel commandline or as option in /etc/modprobe.d/
After reboot check the value at:
  $ cat /sys/module/kvm_intel/parameters/preemption_timer
  Y
This should be Y by default and then flip to N.

Give this a try and report back the exits now that I fixed my missing -a.
If the numbers with disabled preemption_timer are massively different feel free to report those as well.

The perf profile of the host looks pretty much as expected matching the ongoing run/irq-delivery loop. The better numbers will help here if there are outliers we might miss.

Unfortunately the guest is unresponsive (so we can't easily check its /proc/interrupts for the types that are looping here. Furthermore your guest samples have no symbols (likely due to the kallysyms missing) which makes the guest still kind of a black box.
Unfortunately while attaching a debugger to the guest is possible [2] I'd not know a way to do this after the fact and since you need ti migrate to another host to trigger your issue we can't use that :-/
Until we have an idea for that guest debugging that works better in your case we might be in the dark here.

One approach we haven't started yet is checking for fixes in newer versions. For example bug 1791286 was somewhat similar, yet newer versions had it fixed and there were patches to backport.
Qemu 4.0 was just very recently released that isn't ready yet, but you could at your Bionic target install UCA-Stein [3]. That would lift the qemu 2.11 in Bionic to 3.1 which still is rather new. In the same fashion your target systems of the migrations could use e.g. Xenial+UCA

This would allow us to probe a few qemu releases for your case:
Xenial / Xenial+Ocata / Bionic / Bionic-Stein
Which matches qemu versions:
2.5 / 2.8 / 2.11 / 3.1

At a m...

Read more...

Corey Melanson (cmelanson) wrote :

Hi Christian,

I've been working on testing the Bionic+UCA-Stein combination (libvirt 5.0.0-1ubuntu2~cloud0, qemu 1:3.1+dfsg-2ubuntu3~cloud0) and have been finding live migration to be very unstable from stock Bionic hypervisors (libvirt 4.0.0-1ubuntu8.8, qemu 1:2.11+dfsg-1ubuntu7.12). Also tried in-place package upgrade from stock-> UCA-Stein. The VMs randomly end up stuck "paused" on both source/destination while the live migration is in progress, and qemu is unresponsive to monitor commands and logs show messages such as:
2019-04-11 18:41:41.349+0000: 6102: warning : qemuDomainObjBeginJobInternal:4933 : Cannot start job (query, none) for domain one-362495; current job is (query, none) owned by (43880 remoteDispatchDomainBlockStatsFlags, 0 <null>) for (31s, 0s)
2019-04-11 18:41:41.349+0000: 6102: error : qemuDomainObjBeginJobInternal:4945 : Timed out during operation: cannot acquire state change lock (held by remoteDispatchDomainBlockStatsFlags)
2019-04-11 18:41:41.350+0000: 6099: error : virNetSocketReadWire:1796 : Cannot recv data: Connection reset by peer
2019-04-11 18:42:38.811+0000: 6100: warning : qemuDomainObjBeginJobInternal:4933 : Cannot start job (query, none) for domain one-362495; current job is (query, none) owned by (43880 remoteDispatchDomainBlockStatsFlags, 0 <null>) for (88s, 0s)
2019-04-11 18:42:38.811+0000: 6100: error : qemuDomainObjBeginJobInternal:4945 : Timed out during operation: cannot acquire state change lock (held by remoteDispatchDomainBlockStatsFlags)
2019-04-11 18:42:38.812+0000: 6099: error : virNetSocketReadWire:1811 : End of file while reading data: Input/output error
2019-04-11 18:42:49.434+0000: 6104: warning : qemuDomainObjBeginJobInternal:4933 : Cannot start job (query, none) for domain one-362495; current job is (query, none) owned by (43880 remoteDispatchDomainBlockStatsFlags, 0 <null>) for (99s, 0s)

It never finishes so I have to do virsh destroy to "recover" from it.

But that's not really what this ticket is about... Because of these issues I haven't been able to test the Trusty -> Bionic+UCA-Stein migration, as Bionic+UCA-Stein seems even more unstable :-(

Not sure how best to proceed with troubleshooting for you at this point, I feel that Xenial is my only option...

Corey Melanson

@Corey M.: Very odd/uncommon, but unfortunately with nothing actionable/fixable identified yet.
If you find anything more that could help leading us to the root cause and maybe a fix let me know.

@James/Corey C.B.: once more I wanted to ask if you have seen similar issues with cross release migrations related to maybe ceph which is used here?

Paul Hawkins (moonwatcher) wrote :

Just starting to use QEMU/KVM VMs on Ubuntu 18.04.1 Desktop. Both host and quest are same release.

Today after doing an ubuntu update to 18.04.2 on guest (apt update; apt upgrade) and rebooting the VM its display resolution changed to 800x600 and it cannot be changed as no other resolution is given.

I can repeat this every time:
1. clone 18.04.1 vm
2. boot clone and check resolution is highest offer of many
3. apt update; apt upgrade; reboot
4. only 800x600 is avail.

Tried updating host to 18.04.2 but did not help. Beside same issue above when I log out of guest VM gdm3 display manager screen is not shown but only a black screen (user VMM on host to open VM)

Downloaded 18.04.2 iso and created new VM with it and got same issue.

Did see guest cpu at 100% after apt upgrade and then apt install of xubuntu desktop.

I think I read in 18.04.2 QEMU has been upgraded (but maybe only in 18.04 server).

At a bit of loss now. I will have to rebuild the host to 18.04.1 and start again.

Still new to QEMU/KVM, but not VMs in general. So maybe this is just a newbie mistake around correct video config in VMM. I have tried several of the others VMM gives but nothing helps.

On Mon, May 27, 2019 at 5:25 AM Paul Hawkins <email address hidden> wrote:
>
> Just starting to use QEMU/KVM VMs on Ubuntu 18.04.1 Desktop. Both host
> and quest are same release.

Hi Paul,
I'll answer the first few bits here, but generally this seems to be a
different issue than the bug you replied on.
Not every 100% hang is the same :-)
I'd appreciate if - going further - you'd carry that to a new bug
report instead.

> Today after doing an ubuntu update to 18.04.2 on guest (apt update; apt
> upgrade) and rebooting the VM its display resolution changed to 800x600
> and it cannot be changed as no other resolution is given.
>
> I can repeat this every time:
> 1. clone 18.04.1 vm
> 2. boot clone and check resolution is highest offer of many
> 3. apt update; apt upgrade; reboot
> 4. only 800x600 is avail.
>

I still had a 18.04.1 Desktop guest around.
I cloned it and booted it as is to verify what I had before.
848x480 to 1920x1200
After an Upgrade to 18.04.2 it sees:
848x480 to 1920x1200 (The same list)

So I can not reproduce your issue as-is.
When you open a new bug for this could you please supply for both
good/bad cases these logs from your guest:
- ~/.local/share/xorg/Xorg.0.log
- journalctl -b 0

> Tried updating host to 18.04.2 but did not help. Beside same issue
> above when I log out of guest VM gdm3 display manager screen is not
> shown but only a black screen (user VMM on host to open VM)
>
> Downloaded 18.04.2 iso and created new VM with it and got same issue.
>
> Did see guest cpu at 100% after apt upgrade and then apt install of
> xubuntu desktop.

Seems to be another independent issue of yours, if you happen to file
a bug this is another extra bug please.

>
> I think I read in 18.04.2 QEMU has been upgraded (but maybe only in
> 18.04 server).

No, they all come from the same place in the archive, there is no
updating "update one or the other".
Qemu got plenty of bug and security fixes since it got released in
18.04 - so yes there are some.
But that does not need 18.04.x - you just get it on upgrades.

> At a bit of loss now. I will have to rebuild the host to 18.04.1 and
> start again.
>
> Still new to QEMU/KVM, but not VMs in general. So maybe this is just a
> newbie mistake around correct video config in VMM. I have tried several
> of the others VMM gives but nothing helps.
>

As I said please file extra bugs so that we can leave this one here
alone until new data is found for the issue that really is meant to be
discussed here.

Launchpad Janitor (janitor) wrote :

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]

Changed in qemu (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers