Red Hat Bugzilla – Bug 831249
resize request should be reject if virtIO-ballon-device isn't ready in guest
Last modified: 2012-06-13 04:16:26 EDT
Description of problem: Last not completing or pending tasks will be to continue to perform when virtIO balloon driver recovered, my opinion is reject all incoming resize request if virtIO-ballon-device isn't ready in guest; Version-Release number of selected component (if applicable): qemu-kvm-0.12.1.2 virtio-win-1.5.2-1.el6.noarch Host kernel version:2.6.32-278.el6.x86_64 guest: en_windows_7_ultimate_x64 How reproducible: CPU: Dual-Core AMD Opteron(tm) Processor 1216 RAM: Steps to Reproduce: 1. boot guest with virtio balloon device command like below: /usr/libexec/qemu-kvm -M rhel6.3.0 -cpu Penryn -smp 2,sockets=2,cores=1,threads=1 -m 4G -enable-kvm -uuid `uuidgen` -boot order=dnc,once=d -drive file=/usr/share/virtio-win/virtio-win-1.5.2.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -spice port=5904,disable-ticketing -k en-us -rtc base=localtime,driftfix=slew -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-tablet,id=input0 -drive file=/root/win7.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,serial=yzWaibVh,cache=none,werror=stop,rerror=stop,aio=native -device ide-drive,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=9a:1b:69:1a:e5:5c,bus=pci.0,addr=0x5,bootindex=3 -monitor stdio -device virtio-balloon-pci,id=balloon1,bus=pci.0,addr=0x7 -qmp tcp:0:4444,server,nowait 2. disable virtIO balloon device in guest 3. reset value of balloon in qemu-kvm monitor window 4. enable virtio balloon device in guest 5. repeat step 3 6. reboot guest during enlarging/evicting memory Actual results: actual ballon values evicting memory when guest booting up Expected results: all request operation rejected if virtIO-ballon-device of guest isn't ready Additional info: sometimes guest crash when repeat reporduce step 3 - step 5; get below info in qemu monitor window: ... (qemu) info balloon balloon: actual=3537 (qemu) balloon 2048 (qemu) virtio_ioport_write: unexpected address 0x13 value 0x1 [root@amd-1216-8-1 ~]# cat /proc/meminfo MemTotal: 8059288 kB MemFree: 2800052 kB [root@amd-1216-8-1 ~]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : Dual-Core AMD Opteron(tm) Processor 1216
it should be made by design ,and at least I don't think this is a virtio-win bug .Linux guest should behaved like this as well . Move to virtio-win conponent .
Created attachment 591351 [details] core dump info win7-guest add qeme package version here and attached window crash info, hope it will useful to fix this defeat. qemu-kvm-0.12.1.2-2.295.el6.x86_64 qemu-kvm-tools-0.12.1.2-2.295.el6.x86_64 Thanks, Xu
This is by design. This has been discussed in the past and rejected. One example is libvirt starting guests in 'stopped' mode, setting the required balloon value, and then running the guest. When the balloon driver in the guest is loaded, it reads the currently-ballooned value and adjusts its behaviour accordingly.