Bug 1853779

Testing, the results will be updated later.

Hi hhaberma 

No hit these issues, guest boot normally.
I opened Red Hat Customer Portal: 02687317 and got an error: There was an error loading case.

1. Is it possible to provide the customer's boot command line or XML file?
2. I saw that the guest kernel in the picture is 3.10.0-1062.el7.ppc64le, so I tested two versions of the guest kernel.
   Let me know if my version is wrong or if you have any questions or concerns.thanks.


test on Power8
host kernel: 3.10.0-1062.12.1.el7.ppc64le
qemu-kvm-ma-2.12.0-44.el7_8.1

guest kernel 1 :3.10.0-1062.el7.ppc64le
guest kernel 2 :3.10.0-1062.12.1.el7.ppc64le 

boot cmd:
/usr/libexec/qemu-kvm \
-name 'avocado-vt-vm1'  \
-sandbox on  \
-machine pseries  \
-nodefaults \
-device VGA,bus=pci.0,addr=0x2 \
-m 20480  \
-smp 64,maxcpus=64,cores=32,threads=1,sockets=2  \
-cpu 'host' \
-chardev socket,path=/var/tmp/59-QuqCUepm,id=qmp_id_qmpmonitor1,nowait,server  \
-mon chardev=qmp_id_qmpmonitor1,mode=control \
-chardev socket,path=/var/tmp/3259-QuqCUepm,id=chardev_serial0,nowait,server \
-device spapr-vty,id=serial0,reg=0x30000000,chardev=chardev_serial0 \
-device qemu-xhci,id=usb1,bus=pci.0,addr=0x3 \
-device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
-device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x4 \
-blockdev node-name=file_image1,driver=file,aio=threads,filename=/home/test/os.qcow2,cache.direct=on,cache.no-flush=off \
-blockdev node-name=drive_image1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_image1 \
-device scsi-hd,id=image1,drive=drive_image1,write-cache=on \
-device virtio-net-pci,mac=9a:58:f2:8e:8d:34,id=idnuRQWo,netdev=idFVAnME,bus=pci.0,addr=0x5  \
-netdev tap,id=idFVAnME,vhost=on  \
-vnc :30  \
-rtc base=utc,clock=host  \
-boot menu=off,order=cdn,once=c,strict=off \
-enable-kvm \
-monitor stdio 

====================guest kernel 1 :3.10.0-1062.el7.ppc64le====================================

OF stdout device is: /vdevice/vty@30000000
Preparing to boot Linux version 3.10.0-1062.el7.ppc64le (mockbuild.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Thu Jul 18 20:29:07 UTC 2019
Detected machine type: 0000000000000101
Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
Calling ibm,client-architecture-support... done
command line: BOOT_IMAGE=/vmlinuz-3.10.0-1062.el7.ppc64le root=/dev/mapper/rhel-root ro console=tty0 console=ttyS0,115200 reboot=pci biosdevname=0 crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet LANG=en_US.UTF-8
memory layout at init:
  memory_limit : 0000000000000000 (16 MB aligned)
  alloc_bottom : 0000000004f70000
  alloc_top    : 0000000030000000
  alloc_top_hi : 0000000500000000
  rmo_top      : 0000000030000000
  ram_top      : 0000000500000000
found display   : /pci@800000020000000/vga@2, opening... done
instantiating rtas at 0x000000002fff0000... done
prom_hold_cpus: skipped
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000004f80000 -> 0x0000000004f80b25
Device tree struct  0x0000000004f90000 -> 0x0000000004fa0000
Calling quiesce...
returning from prom_init
CF000012
CF000015ch
Linux ppc64le
#1 SMP Thu Jul 1
Red Hat Enterprise Linux Server 7.7 (Maipo)
Kernel 3.10.0-1062.el7.ppc64le on an ppc64le

dhcp71-226 login: root

=====================guest kernel 2 :3.10.0-1062.12.1.el7.ppc64le =========================================

OF stdout device is: /vdevice/vty@30000000
Preparing to boot Linux version 3.10.0-1062.12.1.el7.ppc64le (mockbuild.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Thu Dec 12 11:47:54 UTC 2019
Detected machine type: 0000000000000101
Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
Calling ibm,client-architecture-support... done
command line: BOOT_IMAGE=/vmlinuz-3.10.0-1062.12.1.el7.ppc64le root=/dev/mapper/rhel-root ro console=tty0 console=ttyS0,115200 reboot=pci biosdevname=0 crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet LANG=en_US.UTF-8
memory layout at init:
  memory_limit : 0000000000000000 (16 MB aligned)
  alloc_bottom : 0000000004ee0000
  alloc_top    : 0000000030000000
  alloc_top_hi : 0000000500000000
  rmo_top      : 0000000030000000
  ram_top      : 0000000500000000
found display   : /pci@800000020000000/vga@2, opening... done
instantiating rtas at 0x000000002fff0000... done
prom_hold_cpus: skipped
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000004ef0000 -> 0x0000000004ef0b25
Device tree struct  0x0000000004f00000 -> 0x0000000004f10000
Calling quiesce...
returning from prom_init
CF000012
CF000015ch
Linux ppc64le
#1 SMP Thu Dec 1
Red Hat Enterprise Linux Server 7.7 (Maipo)
Kernel 3.10.0-1062.12.1.el7.ppc64le on an ppc64le

dhcp71-226 login: root

Update test information

1. The current host libfdt version is libfdt-1.4.6-1.el7.ppc64le, 
   upgraded to libfdt-1.4.7-3.fc30.ppc64le. guest can still boot normally.

2. Rebuilt the guest (same 7.7 iso:RHEL-7.7-20190723.1-Server-ppc64le-dvd1.iso and Minimal install), 
   disables kdump during install.
   guest can still boot normally, then update kernel to 3.10.0-1062.12.1.el7.ppc64le.
   reboot guest can still boot normally.

3. The next step is to try to call the VM through libvirt.

hardware information:
host kernel: 3.10.0-1062.12.1.el7.ppc64le
qemu-kvm-ma-2.12.0-44.el7_8.1

guest kernel 1: 3.10.0-1062.el7.ppc64le
guest kernel 2: 3.10.0-1062.12.1.el7.ppc64le 

hostname: ibm-p8-garrison-04.rhts.eng.bos.redhat.com
# lscpu
Architecture:          ppc64le
Byte Order:            Little Endian
CPU(s):                160
On-line CPU(s) list:   0,8,16,24,32,40,48,56,64,72,80,88,96,104,112,120,128,136,144,152
Off-line CPU(s) list:  1-7,9-15,17-23,25-31,33-39,41-47,49-55,57-63,65-71,73-79,81-87,89-95,97-103,105-111,113-119,121-127,129-135,137-143,145-151,153-159
Thread(s) per core:    1
Core(s) per socket:    10
Socket(s):             2
NUMA node(s):          2
Model:                 1.0 (pvr 004c 0100)
Model name:            POWER8NVL (raw), altivec supported
CPU max MHz:           4023.0000
CPU min MHz:           2394.0000
L1d cache:             64K
L1i cache:             32K
L2 cache:              512K
L3 cache:              8192K
NUMA node0 CPU(s):     0,8,16,24,32,40,48,56,64,72
NUMA node1 CPU(s):     80,88,96,104,112,120,128,136,144,152

# update_flash_nv -d

Firmware version:
 Product Version       : garrison-OP8_v1.12_2.96
 Product Extra         : bmc-firmware-version-2.13
 Product Extra         : buildroot-2019.02.1-16-ge01dcd0
 Product Extra         : capp-ucode-p9-dd2-v4
 Product Extra         : hostboot-p8-c893515-pd6f049d
 Product Extra         : hostboot-binaries-hw041519a.opv23
 Product Extra         : linux-5.0.7-openpower1-p8e31f00
 Product Extra         : machine-xml-c5c35cb
 Product Extra         : occ-p8-a2856b7
 Product Extra         : op-build-v2.3-7-g99a6bc8
 Product Extra         : petitboot-v1.10.3
 Product Extra         : skiboot-v6.3.1

(In reply to hhaberma from comment #0)
> Created attachment 1699900 [details]
> Can't boot with Building dt structure
...
> ======
> 
> The can't boot hung on building the device tree at post.
> 
> ~~~
> Building dt strings..
> Building dt structure..
> ..
> .
> returning from prom_init

Generally, when we have only this on the graphical display it means all the interesting information have been sent to the serial console.

So, please, provide:
- the output on the guest serial console,
- the full qemu command line
- the SLOF version
- the host and guest kernel version (it's not clear if this is the same version for both)
- the output of "lscpu" on the host
- the output of "update_flash_nv -d" on the host
- the output of "lsmod | grep kvm"

Thanks

(In reply to zhenyzha from comment #6)
> Update test information
> 
> 1. The current host libfdt version is libfdt-1.4.6-1.el7.ppc64le, 
>    upgraded to libfdt-1.4.7-3.fc30.ppc64le. guest can still boot normally.
> 
> 2. Rebuilt the guest (same 7.7
> iso:RHEL-7.7-20190723.1-Server-ppc64le-dvd1.iso and Minimal install), 
>    disables kdump during install.
>    guest can still boot normally, then update kernel to
> 3.10.0-1062.12.1.el7.ppc64le.
>    reboot guest can still boot normally.
> 
> 3. The next step is to try to call the VM through libvirt.
> 


Use libvirt-4.5.0-33.el7_8.1.ppc64le to call the above version VM can boot normally.

Therefore, I need to wait for further information before proceeding to the next bug verification.


=================Serial port information during boot=========================================
Installing QEMU fb



Scanning USB 
  XHCI: Initializing
    USB Keyboard 
    USB mouse 
No console specified using screen & keyboard
     
  Welcome to Open Firmware

  Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
  This program and the accompanying materials are made available
  under the terms of the BSD License available at
  http://www.opensource.org/licenses/bsd-license.php


Trying to load:  from: /pci@800000020000000/scsi@4 ...   Successfully loaded
CF000012
CF000015ch
Linux ppc64le
#1 SMP Thu Dec 1
Red Hat Enterprise Linux Server 7.7 (Maipo)
Kernel 3.10.0-1062.12.1.el7.ppc64le on an ppc64le

dhcp70-221 login: 


=================The xml file is as follows:=========================================
<domain type='kvm'>
  <name>avocado-vt-vm1</name>
  <uuid>5ea6f0a4-51e3-4b62-9434-b95c5a0a7d37</uuid>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='ppc64le' machine='pseries'>hvm</type>
    <boot dev='hd'/>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/bug/rhel7.7.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='sda' bus='scsi'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='usb' index='0' model='qemu-xhci'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'>
      <model name='spapr-pci-host-bridge'/>
      <target index='0'/>
    </controller>
    <controller type='scsi' index='0'>
      <address type='spapr-vio' reg='0x2000'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:dc:9f:47'/>
      <source bridge='switch'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
      <address type='spapr-vio' reg='0x30000000'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
      <address type='spapr-vio' reg='0x30000000'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='keyboard' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='usb'>
      <address type='usb' bus='0' port='2'/>
    </input>
    <graphics type='vnc' port='-1' autoport='yes'>
      <listen type='address'/>
    </graphics>
    <video>
      <model type='vga' vram='16384' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
    <panic model='pseries'/>
  </devices>
</domain>

I strongly suspect that the fdt stuff is a red herring here - I think this is probably a mostly unrelated problem to bug 1624539.  AFAICT from comment 0, the "FDT_ERR_BADSTATE" message is *not* appearing in this case, just the VSMT message, which is not closely connected.


But, in any case, we'll need the customer's command line and/or XML file in order to work out what's going on here.

hhaberma,

Is the customer still seeing this problem?  Have you managed to gather any extra information.

Without some of the information requested in comment 11, we'll have to close this as INSUFFICIENT_DATA.

Unable to reproduce, and we have no further information from the customer.  Closing.

Gibson,  I apologize for delay. I have made one last request from customer for VMs xml, but more than likely I believe they moved on to another project. I will re-open if customer still wants to pursue.

Gibson, the customer has responded with the data needed and so I am reopening BZ. Please find requested data below:


VM Ecom2 does boot but only to the original: kernel-3.10.0-1062.el7.ppc64le

kernel-3.10.0-1127.13.1.el7.ppc64le hangs on boot with following XML

virsh -r dumpxml Ecom2
<domain type='kvm' id='33'>
  <name>Ecom2</name>
  <uuid>1f529bb8-4f96-456a-9dc8-b367c7723410</uuid>
  <memory unit='KiB'>8388608</memory>
  <currentMemory unit='KiB'>0</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='ppc64le' machine='pseries-rhel7.6.0'>hvm</type>
  </os>
  <cpu mode='host-model' check='partial'>
    <model fallback='forbid'/>
  </cpu>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/ppro/VMs/Ecom2.qcow2'/>
      <backingStore/>
      <target dev='sda' bus='scsi'/>
      <boot order='1'/>
      <alias name='scsi0-0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu'/>
      <target dev='sdb' bus='scsi'/>
      <readonly/>
      <alias name='scsi0-0-0-1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0' model='qemu-xhci'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'>
      <model name='spapr-pci-host-bridge'/>
      <target index='0'/>
      <alias name='pci.0'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <alias name='virtio-serial0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </controller>
    <controller type='scsi' index='0' model='ibmvscsi'>
      <alias name='scsi0'/>
      <address type='spapr-vio' reg='0x2000'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:ca:de:8b'/>
      <source bridge='br0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/13'/>
      <target type='spapr-vio-serial' port='0'>
        <model name='spapr-vty'/>
      </target>
      <alias name='serial0'/>
      <address type='spapr-vio' reg='0x30000000'/>
    </serial>
    <console type='pty' tty='/dev/pts/13'>
      <source path='/dev/pts/13'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
      <address type='spapr-vio' reg='0x30000000'/>
    </console>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-33-Ecom2/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='keyboard' bus='usb'>
      <alias name='input0'/>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='usb'>
      <alias name='input1'/>
      <address type='usb' bus='0' port='2'/>
    </input>
    <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>
    <video>
      <model type='vga' vram='16384' heads='1' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </memballoon>
    <panic model='pseries'/>
  </devices>
  <seclabel type='dynamic' model='dac' relabel='yes'>
    <label>+107:+107</label>
    <imagelabel>+107:+107</imagelabel>
  </seclabel>
</domain>

(In reply to hhaberma from comment #15)
> Gibson, the customer has responded with the data needed and so I am
> reopening BZ. Please find requested data below:
> 


OK, got it.

Testing, the results will be updated later.

Update test information

No hit these issues, the guest can be started normally by using the customer's XML file(comment15).

test on Power8
host kernel: 3.10.0-1062.el7.ppc64le
qemu-kvm-ma-2.12.0-44.el7_8.1
SLOF-20171214-3.gitfa98132.el7.noarch
libvirt-4.5.0-33.el7_8.1.ppc64le.rpm
hostname:ibm-p8-kvm-01-qe.khw1.lab.eng.bos.redhat.com

guest kernel 1 :3.10.0-1062.31.1.el7.ppc64le 

==updata kernel 1 to 2== 
guest kernel 2 :3.10.0-1062.12.1.el7.ppc64le  

==updata kernel 2 to 3== 
guest kernel 3 :3.10.0-1127.13.1.el7.ppc64le



===================== guest kernel 2 :3.10.0-1062.31.1.el7.ppc64le =========================================
Trying to load:  from: /vdevice/v-scsi@2000/disk@8000000000000000 ...   Successfully loaded
CF000012
CF000015ch
Linux ppc64le
#1 SMP Mon Jul 1
Red Hat Enterprise Linux Server 7.7 (Maipo)
Kernel 3.10.0-1062.31.1.el7.ppc64le on an ppc64le

dhcp16-201-162 login: 

===================== guest kernel 2 :3.10.0-1062.12.1.el7.ppc64le =========================================
Trying to load:  from: /vdevice/v-scsi@2000/disk@8000000000000000 ...   Successfully loaded
CF000012
CF000015ch
Linux ppc64le
#1 SMP Thu Dec 1
Red Hat Enterprise Linux Server 7.7 (Maipo)
Kernel 3.10.0-1062.12.1.el7.ppc64le on an ppc64le

dhcp16-201-162 login: 


===================== guest kernel 2 :3.10.0-1127.13.1.el7.ppc64le =========================================
Trying to load:  from: /vdevice/v-scsi@2000/disk@8000000000000000 ...   Successfully loaded
CF000012
CF000015ch
Linux ppc64le
#1 SMP Fri Jun 1
Red Hat Enterprise Linux Server 7.7 (Maipo)
Kernel 3.10.0-1127.13.1.el7.ppc64le on an ppc64le

dhcp16-201-162 login: 


==================== check dmesg no coredump Core Dump Call Trace ====================
[root@dhcp16-201-162 ~]# dmesg | grep Call

[root@dhcp16-201-162 ~]# dmesg | grep coredump

[root@dhcp16-201-162 ~]# dmesg | grep Core
[    1.320739] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    3.998252] ip_tables: (C) 2000-2006 Netfilter Core Team
[   10.529213] ip6_tables: (C) 2000-2006 Netfilter Core Team

==================== check /var/log/libvirt/qemu/ ====================
qemu-cmd:
/usr/libexec/qemu-kvm \
-name guest=Ecom1,debug-threads=on \
-S \
-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-Ecom1/master-key.aes \
-machine pseries-rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off \
-cpu host \
-m 8192 \
-realtime mlock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid 1f529bb8-4f96-456a-9dc9-b367c7723411 \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=26,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
-device qemu-xhci,id=usb,bus=pci.0,addr=0x2 \
-device spapr-vscsi,id=scsi0,reg=0x2000 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \
-drive file=/home/test/os.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 \
-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \
-drive if=none,id=drive-scsi0-0-0-1,readonly=on \
-device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 \
-netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ca:de:8b,bus=pci.0,addr=0x1 \
-chardev pty,id=charserial0 \
-device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \
-chardev socket,id=charchannel0,fd=30,server,nowait \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
-device usb-kbd,id=input0,bus=usb.0,port=1 \
-device usb-mouse,id=input1,bus=usb.0,port=2 \
-vnc 0.0.0.0:30 \
-device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x5 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on

Generally, when we have only this on the graphical display it means all the interesting information have been sent to the serial console.

So, please, provide the output on the guest serial console,

Unable to reproduce, and we have no further information from the customer.  Closing.