Description of problem: When I run VMs through virt-manager/libvirt my host system experiences disruptive disk I/O that is not related to guest disk I/O. I'm measuring this I/O after issuing a "shutdown -H now" on the guest OS to unmount all drives, deactivate swap, and halt the kernel while leaving the VM "on". What I get is around 180 kB/s of writes tied to the qemu-kvm process (i.e. it stops if I kill or suspend the process), even though the guest VM is clearly doing nothing. While the total amount of writes isn't all that high, it is having an unusually-high impact on my host system's performance and I can't run more than two VMs without being significantly impaired. If I add a network interface to the VM the disk I/O on the host will go up to around 400 kB/s of writes with a very significant impact to my host. The command-line issued by virt-manager is: /usr/bin/qemu-system-x86_64 --enable-kvm -S -M pc-1.0 -cpu core2duo,+lahf_lm,+rdtscp,+avx,+osxsave,+xsave,+aes,+tsc-deadline,+popcnt,+x2apic,+sse4.2,+sse4.1,+pdcm,+xtpr,+cx16,+tm2,+est,+smx,+vmx,+ds_cpl,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name test -uuid 6b692af0-6e77-6a38-366a-e135a50e4719 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/test.img,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 I can run an almost identical command by hand (the only change is removing "-S" so I don't have to issue a start command to the VM) and I don't get any unexpected disk I/O. This leads me to believe that the disk I/O is somehow caused by libvirt. system information: CPU model: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, four cores RAM: 16GB Disk: SATA, 750GB qemu-kvm version: qemu-kvm 1.0.1 libvirt version: 0.9.11.3 host kernel version/arch: Gentoo kernel 3.3.8-gentoo, x86_64 guest: Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64) /var/log/libvirt/qemu/test.log: 2012-07-20 14:25:11.631+0000: starting up LC_ALL=C PATH=/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3 HOME=/root USER=root QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-1.0 -cpu core2duo,+lahf_lm,+rdtscp,+avx,+osxsave,+xsave,+aes,+tsc-deadline,+popcnt,+x2apic,+sse4.2,+sse4.1,+pdcm,+xtpr,+cx16,+tm2,+est,+smx,+vmx,+ds_cpl,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name test -uuid 6b692af0-6e77-6a38-366a-e135a50e4719 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/test.img,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 Domain id=21 is tainted: high-privileges char device redirected to /dev/pts/6 CPU feature tsc-deadline not found qemu: terminating on signal 15 from pid 11853 2012-07-20 14:27:29.199+0000: shutting down
Created attachment 599405 [details] domain XML
I'm sorry this never received a response. Given the age of this bug and the massive changes in libvirt and qemu since then (and the lack of similar reports to yours) I'm going to assume this is fixed. Closing as DEFERRED, but still sees this behavior with a more modern libvirt, please file a new bug and we can go from there