Kernel 4.4.0-122 Breaks qemu-system-x86

[Skipper]

Fully updated xubuntu 16.04 running kernel 4.4.0-122 breaks qemu-system-x86: black screen displays and qemu-system-x86 runs at 100% cpu indefinitely. Boot the same system with kernel 4.4.0-119 and qemu-system-x86 works fine running a Windows 10 VM.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: qemu-system-x86 1:2.5+dfsg-5ubuntu10.25
ProcVersionSignature: Ubuntu 4.4.0-122.146-generic 4.4.117
Uname: Linux 4.4.0-122-generic i686
ApportVersion: 2.20.1-0ubuntu2.16
Architecture: i386
CurrentDesktop: XFCE
Date: Sun Apr 29 15:58:25 2018
InstallationDate: Installed on 2014-04-29 (1460 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release i386 (20140416.2)
KvmCmdLine:
 COMMAND STAT EUID RUID PID PPID %CPU COMMAND
 kvm-irqfd-clean S< 0 0 394 2 0.0 [kvm-irqfd-clean]
MachineType: Dell Inc. Inspiron 518
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-122-generic root=UUID=7cffb293-c044-4b2c-8343-dc50fd16db97 ro --verbose nosplash nmi_watchdog=0
SourcePackage: qemu
UpgradeStatus: Upgraded to xenial on 2016-08-10 (627 days ago)
dmi.bios.date: 03/30/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.0.8
dmi.board.name: 0K068D
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: OEM
dmi.modalias: dmi:bvnDellInc.:bvr1.0.8:bd03/30/2009:svnDellInc.:pnInspiron518:pvr00:rvnDellInc.:rn0K068D:rvrA00:cvnDellInc.:ct3:cvrOEM:
dmi.product.name: Inspiron 518
dmi.product.version: 00
dmi.sys.vendor: Dell Inc.

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.4.0-121 as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

[Andreas Hasenack (ahasenack)]

Could you please paste the full command line that the qemu process is using (ps fauxwww should be enough), and perhaps a xml dump of the vm, like this: "virsh dumpxml <vm-name> > vm.xml" and attach that to this bug as well.

I was not able to reproduce this in a nested vm, using linux as a guest. I don't have a 16.04 host at hand, nor a windows vm at the moment.

[Christian Ehrhardt  (paelzer)]

Also a per qemu thread view is often useful, you might also add
$ pidstat -t -p <pidofqemu>

Further since this is reported as kernel update regression I'll flag it as that for now.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Skipper (nskipper1-gmail)]

QEMU command:
qemu-system-i386 -name windows-10-pro -pidfile /tmp/windows-10-pro.pid -m 2047M -cpu host -smp 1 -enable-kvm -rtc clock=host,base=localtime -machine type=ubuntu -k en-us -drive file=/media/V-BOX/KVM/Win10/Win10-VM.qcow2,if=virtio,media=disk,format=qcow2,index=0 -drive file=/media/Big_NTFS/G/Backup/KVM/Win10/Win10-VM_Backup_Disk.qcow2,if=virtio,media=disk,format=qcow2,index=1 -drive file=/media/Shared/E/Win10-VM_Page_File.qcow2,if=virtio,media=disk,format=qcow2,index=2 -usb -device usb-ehci,id=ehci -device usb-host,vendorid=0x13fe,productid=0x3100 -device usb-host,vendorid=0x090c,productid=0x1000 -device usb-host,vendorid=0x14cd,productid=0x1212 -device piix3-usb-uhci -device usb-tablet

I don't use Virt Manager.

[Christian Ehrhardt  (paelzer)]

Hi Skipper,
thanks for sharing the qemu cmdline, there is nothing odd in this and I can run a system like that (not a win 10 guest) just fine.

What about the per thread stats I asked, which threads are busy and where do they consume time?
Depending on your experience you could even check "perf kvm stat" and such to see which exists you trigger (unless it is mostly in guest anyway).

@Kernel Team - have you had similar reports?

[Skipper (nskipper1-gmail)]

ChristianEhrhardt:

I assume you want stats from when qemu is failing while running kernel 4.4.0-122. Since I am running kernel 4.4.0-119 so that I can use the VM, that would require a reboot which would be inconvenient at this time. If you could give me some specific commands to use to get what you want I will try next time I reboot.

[Christian Ehrhardt  (paelzer)]

For the per thread view use:
 $ sudo pidstat -t -p <pidofqemu>

For perf to track kvm exits you can install it like:
$ sudo apt install linux-tools-common

And then run while your guest hangs (or not in the good case) as:
$ sudo perf stat -e 'kvm:*' -a sleep 1h

More on [1] if you want.

[1]: https://www.linux-kvm.org/page/Perf_events

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.4.0-124 as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

[Skipper (nskipper1-gmail)]

sudo pidstat -t -p 4063
Linux 4.4.0-124-generic (desktop) 05/08/2018 _i686_ (2 CPU)

09:43:39 PM UID TGID TID %usr %system %guest %CPU CPU Command
09:43:39 PM 1000 4063 - 0.01 3.01 0.01 3.04 1 qemu-system-i38
09:43:39 PM 1000 - 4063 0.02 0.00 0.00 0.02 1 |__qemu-system-i38
09:43:39 PM 1000 - 4064 0.00 0.00 0.00 0.00 1 |__qemu-system-i38
09:43:39 PM 1000 - 4066 0.00 3.01 0.01 3.02 0 |__qemu-system-i38
09:43:39 PM 1000 - 4068 0.00 0.00 0.00 0.00 1 |__qemu-system-i38

sudo perf stat -e 'kvm:*' -a sleep 1h
^Csleep: Interrupt

 Performance counter stats for 'system wide':

         4,221,248 kvm:kvm_entry (100.00%)
                 0 kvm:kvm_hypercall (100.00%)
                 0 kvm:kvm_hv_hypercall (100.00%)
                 0 kvm:kvm_pio (100.00%)
                 0 kvm:kvm_fast_mmio (100.00%)
                 0 kvm:kvm_cpuid (100.00%)
                 0 kvm:kvm_apic (100.00%)
         4,222,925 kvm:kvm_exit (100.00%)
                 0 kvm:kvm_inj_virq (100.00%)
                 0 kvm:kvm_inj_exception (100.00%)
                 0 kvm:kvm_page_fault (100.00%)
                 0 kvm:kvm_msr (100.00%)
                 0 kvm:kvm_cr (100.00%)
                 0 kvm:kvm_pic_set_irq (100.00%)
                 0 kvm:kvm_apic_ipi (100.00%)
                 0 kvm:kvm_apic_accept_irq (100.00%)
                 0 kvm:kvm_eoi (100.00%)
                 0 kvm:kvm_pv_eoi (100.00%)
                 0 kvm:kvm_nested_vmrun (100.00%)
                 0 kvm:kvm_nested_intercepts (100.00%)
                 0 kvm:kvm_nested_vmexit (100.00%)
                 0 kvm:kvm_nested_vmexit_inject (100.00%)
                 0 kvm:kvm_nested_intr_vmexit (100.00%)
                 0 kvm:kvm_invlpga (100.00%)
                 0 kvm:kvm_skinit (100.00%)
       169,094,024 kvm:kvm_emulate_...

[Christian Ehrhardt  (paelzer)]

Hmm,
so it is not even burning CPU for anything neither in the Host (usr ~=qemu, sys ~=kernel) nor in the guest itself (~=guest).
The KVM exits confirm that, it doesn't do a a lot entry/exit is the pass in/out of guest context and the only meaningful exit means it emulates an instruction.

So if it is not hogged on a CPU it is waiting for something. Unfortunately this is too windows and x86-arch specific for me to read, even if you get the info. BTW getting the info what instructions it is spinning on can be done via [1] - this might be helpful for others coming by to help. To bad that I still can't reproduce that locally :-/, but at least I haven't heard of anyone else hitting this yet so it must be sort of special to maybe your guest?

Especially I can't see yet how a host kernel update would trigger this :-/
Sorry, but this is up for the kernel Team to consider the changes that happened between those versions in regard to this issue.

[1]: https://lkml.org/lkml/2012/6/27/241

[Skipper (nskipper1-gmail)]

Also fails (4.4.0-124 kernel) when trying to boot from WinPE ISO - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

qemu-system-i386 -name windows-10-PE -pidfile /tmp/windows-10-PE.pid -m 2047M -cpu host -smp 1 -enable-kvm -rtc clock=host,base=localtime -machine type=ubuntu,accel=kvm -k en-us -boot d -cdrom /media/Shared/E/ISO/AOMEI_Bootable_Rescue_WinPE.iso -hda /media/V-BOX/KVM/Win10/Win10-VM.qcow2 -hdb /media/Big_NTFS/G/Backup/KVM/Win10/Win10-VM_Backup_Disk.qcow2 -usb -device usb-ehci,id=ehci -device piix3-usb-uhci -device usb-tablet

[Skipper (nskipper1-gmail)]

Also fails (4.4.0-124 kernel) when trying to boot from xubuntu-18.04-desktop-i386 ISO - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

qemu-system-i386 -name xubuntu-18.04-desktop-i386 -pidfile /tmp/xubuntu-18.04-desktop-i386.pid -m 2047M -cpu host -smp 1 -enable-kvm -rtc clock=host,base=localtime -machine type=ubuntu,accel=kvm -k en-us -boot d -cdrom /media/Shared/E/ISO/xubuntu-18.04-desktop-i386.iso -hda /media/V-BOX/KVM/Win10/Win10-VM.qcow2 -hdb /media/Big_NTFS/G/Backup/KVM/Win10/Win10-VM_Backup_Disk.qcow2 -usb -device usb-ehci,id=ehci -device piix3-usb-uhci -device usb-tablet

ergo - not related to guest being Windows 10.

Works fine when host booted with 4.4.0-119 kernel.

[Christian Ehrhardt  (paelzer)]

I re-deployed one of my systems to Xenial.
For the complexity of going back I took what kernel is currently active which was 4.4.0-224
With that I spun up the Xubuntu 32 bit iso you referred.

For the sake of completeness I also did the same on 4.15.0-20-generic (also with newer qemu of bionic).

$ qemu-system-i386 -name xubuntu-18.04-desktop-i386 -m 2047M -cpu host -smp 1 -enable-kvm -machine type=ubuntu,accel=kvm -boot d -cdrom /tmp/xubuntu-18.04-desktop-i386.iso

And while the initial loading from the ISO takes quite some time I was easily able to go from the installer into "try Xubuntu" and once the desktop loaded up it was actually quite responsive and just fine. This is true for both kernels/releases that I had tried.

Now since we have this yet-unknown relation to the host kernel version, I wanted to ask if you could try the even newer 4.4.0-224 kernel?

[Skipper (nskipper1-gmail)]

"... try the even newer 4.4.0-224 kernel?"

Could not find 4.4.0-224 kernel.

Installed and booted 4.8.0-58-generic and qemu-system-i386 worked OK.

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.4.0-127 as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

[Christian Ehrhardt  (paelzer)]

Odd, I don't remember where I had the -224 kernel from exactly - even in proposed it isn't :-/.
The next one still is a bit out it seems per bug 1772960
I agree that the last you can currently get is linux-image-generic 4.4.0.127.133
But with that as well it just works fine for me.

I suffer with you on every comment seeing you are still blocked, but lacking any way to circle in closer on the actual issue from your data or reproduce it on my side my hands are tied.

For now I have to wait on the kernel Teams POV to this, maybe they know some changes they had in this ares?

[Ante Karamatić (ivoks)]

I've hit the same problem on 32bit 14.04 with both latest 3.13.0-149 and 4.4.0-127 kernels. I can confirm it works with 4.4.0-119. I could provide some kernel version bisection (both 3.13 and 4.4), but only over the weekend. These are production machines during the week :/

[Ante Karamatić (ivoks)]

I can confirm that, while 4.4.0-119 works just fine, 4.4.0-121 doesn't work.

[Christian Ehrhardt  (paelzer)]

You also said this only applies to the full 32bit stack for you (32bit host + guest) is that correct?
Had you the chance to try the same on 64bit host to know if this is a real constraint to see this issue? It would at least explain why I didn't see it as I had 32bit-Guest on 64-bit Host.

Never the less, this more and more seems to be a kernel bug if
a) you all can point it so clearly to these kernel versions
b) affecting qemu's from Trusty to Bionic

I'll directly ask one in the kernel Team to pop up on their radar.

[Christian Ehrhardt  (paelzer)]

And given we have two reporters that point to the upgrade lets tag it a regression due to that.

[Ante Karamatić (ivoks)]

Host needs to be 32bit. Guest arch is irrelevant for the problem.

On 64bit host everything works fine.
pon, 28. svi 2018. u 07:50  Christian Ehrhardt  <
<email address hidden>> napisao je:

> And given we have two reporters that point to the upgrade lets tag it a
> regression due to that.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1767857
>
> Title:
> Kernel 4.4.0-122 Breaks qemu-system-x86
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1767857/+subscriptions
>
--
Ante Karamatić
<email address hidden>
Canonical

[Juerg Haefliger (juergh)]

I'm not able to reproduce this on a physical host. Works just fine for all the 32-bit kernels that I tested. When you say 'black screen', do you not get anything at all? Not even some BIOS flickering in the beginning?

What do you get when you run the following:
$ qemu-system-i386 -cdrom xubuntu-18.04-desktop-i386.iso -enable-kvm -m 2047
$ qemu-system-i386 -enable-kvm -nographic -kernel /boot/vmlinuz-4.4.0-122-generic -append "console=ttyS0 earlyprintk"

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.4.0-128 as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

Totally black screen immediately - no bios flashes.

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.4.0-130 as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

Totally black screen immediately - no bios flashes.

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.4.0-131 as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

Totally black screen immediately - no bios flashes.

[Skipper (nskipper1-gmail)]

Upgraded to xubuntu 18.04.1 (sudo do-release-upgrade) and kernel 4.15.0-29-generic. Same problem when running qemu-system-x86 (1:2.11+dfsg-1ubuntu7.4) - black screen displays and qemu-system-x86 runs at 100% cpu indefinitely. Totally black screen immediately - no bios flashes.

I thought this would be fixed by now, considering that I "Installed and booted 4.8.0-58-generic and qemu-system-i386 worked OK" (see comment #16).

[Christian Ehrhardt  (paelzer)]

That implies that for you it is some other config than the current kernel (or a combination thereof), so far multiple people including me have not been able to reproduce this - so to further fix things we have to spot what is different within your setup triggering the issue for you.

Unfortunately we have checked the obvious (32bit host) with varying results comment #19 and comment #24. So it must be something else than "just" the kernel, but what?

[Ante Karamatić (ivoks)]

Christian are you testing this on real hardware or on 32bit VMs?

Regression is isolated to just kernel. Same machine, if only kernel is
downgraded works just fine.

On Mon, Aug 6, 2018 at 6:45 AM  Christian Ehrhardt  <
<email address hidden>> wrote:

> That implies that for you it is some other config than the current
> kernel (or a combination thereof), so far multiple people including me
> have not been able to reproduce this - so to further fix things we have
> to spot what is different within your setup triggering the issue for
> you.
>
> Unfortunately we have checked the obvious (32bit host) with varying
> results comment #19 and comment #24. So it must be something else than
> "just" the kernel, but what?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1767857
>
> Title:
> Kernel 4.4.0-122 Breaks qemu-system-x86
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1767857/+subscriptions
>
--
Ante Karamatić
<email address hidden>
Canonical

[Christian Ehrhardt  (paelzer)]

Hi Ante, being a Kernel introduced issue Jürg was testing it (not me as I had no spare HW at the time anyway) - see comment #24.

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.15.0-30-generic as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

Totally black screen immediately - no bios flashes.

[Skipper (nskipper1-gmail)]

I booted from the Xubuntu 18.04.1 Install ISO, installed qemu, copied and modified some files to adjust for user name and permissions, and ran my Windows 10 qemu-system-x86 script - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely). Totally black screen immediately - no bios flashes.

Therefore, it appears to me that the problem is not my Xubuntu software setup.

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.15.0-32-generic as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

Totally black screen immediately - no bios flashes.

[Juerg Haefliger (juergh)]

Chances are slim that this will fix itself automagically. And as long as we're not able to reproduce this, it's going to be difficult. I'll try to take another look in a couple of days once
the current kernel respin frenzy is over.

[Skipper (nskipper1-gmail)]

Since it appears that the problem is not my Xubuntu software setup (see post #33), I thought that maybe it is my hardware setup, which is rather old. So here is my hardware setup for you to consider:

Dell Inspiron 518 desktop (2008?)
Dell DG33M04/Foxconn G33M Motherboard
Intel G33 + ICH9 chipset
8GB memory
Intel Core 2 Duo E8400 CPU (replaced original E7300 - no VT-x)

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.15.0-33-generic as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

Totally black screen immediately - no bios flashes.

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.15.0-34-generic as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

Totally black screen immediately - no bios flashes.

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.15.0-36-generic as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

Totally black screen immediately - no bios flashes.

Fully updated Xubuntu 18.04.

[Skipper (nskipper1-gmail)]

qemu-system-x86 broken when running kernel 4.15.0-38-generic as well - same result (black screen displays and qemu-system-x86 runs at 100% cpu indefinitely).

Totally black screen immediately - no bios flashes.

Fully updated Xubuntu 18.04.

[Skipper (nskipper1-gmail)]

I could not upgrade from Xubuntu 18.04 to Xubuntu 18.10, due to possible demise of 32-bit support, so I have done a fresh install of Xubuntu 18.10 64-bit. Windows 10 guest will still not boot, but now I get the BIOS flash and the Windows 10 Logo, on which it stays indefinitely with 100% cpu. Here is my qemu command:

qemu-system-x86_64 \
-name windows-10-pro \
-pidfile /tmp/windows-10-pro.pid \
-m 2047M \
-cpu host \
-smp 1 \
-enable-kvm \
-rtc clock=host,base=localtime \
-machine type=ubuntu \
-k en-us \
-drive file=/media/V-BOX/KVM/Win10/Win10-VM.qcow2,if=virtio,media=disk,format=qcow2,index=0 \
-drive file=/media/Big_NTFS/G/Backup/KVM/Win10/Win10-VM_Backup_Disk.qcow2,if=virtio,media=disk,format=qcow2,index=1 \
-drive file=/media/Shared/E/Win10-VM_Page_File.qcow2,if=virtio,media=disk,format=qcow2,index=2 \
-usb \
-device usb-ehci,id=ehci \
-device piix3-usb-uhci \
-device usb-tablet

If I add ",hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time" to "-cpu host" the cpu usage goes to 0-5% but still stuck on Windows 10 logo.

This command still works well on Xubuntu 16.04 32-bit (running qemu-system-x86, of course), kernel 4.8.0-58.

Back to Xubuntu 18.10 64-bit, I can boot from xubuntu-18.10-desktop-amd64.iso using this qemu command:

qemu-system-x86_64 \
-name xubuntu-18.10-desktop-amd64 \
-pidfile /tmp/xubuntu-18.10-desktop-amd64.pid \
-m 2047M \
-cpu host \
-smp 1 \
-enable-kvm \
-rtc clock=host,base=localtime \
-machine type=ubuntu \
-k en-us \
-boot d -cdrom /media/Shared/E/ISO/xubuntu-18.10-desktop-amd64.iso \
-usb \
-device piix3-usb-uhci \
-device usb-tablet

This leads me to believe it is a different problem than the original post - maybe related to Windows. The same thing happens if I try anything Windows related (WinXP Install ISO, Win10 Install ISO, WinPE ISO, etc).

I tried virt-manager with an AOMEI Backupper WinPE ISO that I use to backup Windows 10 guest and was able to get that to boot but no mouse and no keyboard. When I Add Hardware > USB Host Device > Logitech MK260 Wireless Mouse/KB Combo, then run, my whole machine freezes and I have to hard reboot. I know next to nothing about virt-manager so I don't know how to proceed with that.

[Skipper (nskipper1-gmail)]

FIXED!!!

As soon as I finished the lengthy post above (#41) I upgraded Xubuntu 18.10 64-bit from kernel 4.18.0-10-generic to 4.18.0-11-generic and I can now boot the Windows 10 guest. Everything works, although the Windows 10 screen does not quite fit in the QEMU window (a bit too long) and none of the items in the QEMU "View" menu changes anything. Perhaps I can google this and find a fix. But it is usable so I'm not complaining. Hopefully it stays usable going forward.

[Andreas Hasenack (ahasenack)]

So, in Cosmic (18.10) it's fixed, but remains in Xenial (16.04) and Bionic (18.04)?

[Skipper (nskipper1-gmail)]

Andreas,

Your statement is too general as the problem seems to depend on the kernel. I will try to clarify based on my experience, which is not exhaustive by any measure:

Qemu is fixed in Cosmic (18.10) 64-bit running kernel 4.18.0-11-generic (but does NOT work in kernel 4.18.0-10-generic). I did not try it in Cosmic (18.10) 32-bit or any other 64-bit kernels.

Qemu works in Xenial (16.04) 32-bit running kernel 4.4.0-119-generic or 4.8.0-58-generic but does NOT work with any other kernel I tried. I did not try it in Xenial (16.04) 64-bit.

Qemu does NOT work in Bionic (18.04) 32-bit with any kernel I tried. I did not try it in Bionic (18.04) 64-bit.

[Juerg Haefliger (juergh)]

/usr/bin/qemu-system-i386 -name ldap -S -machine pc-1.0,accel=kvm,usb=off -cpu host -m 1072 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 2a6c478a-9bd8-40f6-83cd-b2bf681ef5a0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ldap.monitor,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 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/opt/VIRT/LDAP/vda.raw,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:4a:93:0a,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/ldap.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -chardev pty,id=charconsole0 -device virtconsole,chardev=charconsole0,id=console0 -device usb-tablet,id=input0 -vnc 127.0.0.1:59 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7