Hide Forgot
Description of problem: Mirate a vm from rhel7 to rhel8, guest with device "-vga std", migration failed with error message "(qemu) qemu-kvm: Unknown ramblock "vga.vram", cannot accept migration", and this issue is only on fast train(qemu-3.1), it does not exist on slow train(qemu-2.12). Version-Release number of selected component (if applicable): Host A(rhel7.6): 3.10.0-886.el7.x86_64 qemu-kvm-rhev-2.12.0-18.el7_6.3.x86_64 Host B(rhel8.0): 4.18.0-51.el8.x86_64 qemu-kvm-3.1.0-0.module+el8+2266+616cf026.next.candidate.x86_64 How reproducible: 100% Steps to Reproduce: 1.Boot a guest with vga device on source host(rhel7.6) /usr/libexec/qemu-kvm -M pc-i440fx-rhel7.6.0 -nodefaults -monitor stdio -vga std 2.Boot a guest on destination host(rhel8.0) /usr/libexec/qemu-kvm -M pc-i440fx-rhel7.6.0 -nodefaults -monitor stdio -vga std -incoming tcp:0:5801 3.On source host, do migration (qemu) migrate -d tcp:10.73.72.82:5801 Actual results: Migration failed, vm is running on source host. Source: (qemu) info migrate Migration status: failed (qemu) info status VM status: running Destination: (qemu) qemu-kvm: Unknown ramblock "vga.vram", cannot accept migration qemu-kvm: error while loading state for instance 0x0 of device 'ram' qemu-kvm: load of migration failed: Invalid argument Expected results: migration complete and vm works well. Additional info:
This issue exists both on x86_64 and ppc. It is only on fast train(qemu-3.1), slow train(qemu-2.12) does not exist this issue.
(In reply to xianwang from comment #1) > This issue exists both on x86_64 and ppc. > It is only on fast train(qemu-3.1), slow train(qemu-2.12) does not exist > this issue. I think this is because rhel-8.0 machine type is missing. For x86_64, we already have BZ1655820 for that. I take this one for ppc64le.
This fails because the machine type is missing. Machine type is addressed by BZ 1656508. Patch has been sent downstream, wainting ACks. I don't close this BZ as a duplicate to allow to check the new machine type fixes the problem.
Could you re-test with qemu-kvm-3.1.0-3.el8 on destination host(rhel8.0 fasttrain)?
(In reply to Laurent Vivier from comment #7) > Could you re-test with qemu-kvm-3.1.0-3.el8 on destination host(rhel8.0 > fasttrain)? I have tried with qemu-kvm-3.1.0-3.el8 on destination host, the result is PASS. host A(rhel7.6) 4.14.0-115.5.1.el7a.ppc64le qemu-kvm-rhev-2.12.0-18.el7_6.3.ppc64le SLOF-20171214-2.gitfa98132.el7.noarch host B(rhel8.0) 4.18.0-57.el8.ppc64le qemu-kvm-3.1.0-3.module+el8+2614+d714d2bb.ppc64le SLOF-20171214-5.gitfa98132.module+el8+2618+c5e2b86b.noarch with general qemu cli: /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm1' \ -sandbox off \ -nodefaults \ -machine pseries-rhel7.6.0,max-cpu-compat=power8 \ -uuid 8aeab7e2-f341-4f8c-80e8-59e2968d85c2 \ -device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=0x3 \ -object iothread,id=iothread0 \ -device spapr-vscsi,id=scsi2 \ -device nec-usb-xhci,id=usb1,bus=pci.0,addr=0x5 \ -device pci-bridge,chassis_nr=1,id=bridge1,bus=pci.0,addr=0x6 \ -device virtio-scsi-pci,id=scsi1,bus=bridge1,addr=0x7 \ -blockdev driver=file,cache.direct=on,cache.no-flush=off,filename=/home/xianwang/rhel76-ppc64le-virtio-scsi.qcow2,node-name=drive_scsi1 \ -blockdev driver=qcow2,node-name=drive_scsi11,file=drive_scsi1 \ -device scsi-hd,drive=drive_scsi11,id=scse-disk1,bus=scsi1.0,channel=0,scsi-id=0,lun=0,bootindex=0 \ -device virtio-scsi-pci,id=scsi_add,bus=pci.0,addr=0x9 \ -device virtio-net-pci,mac=9a:7b:7c:7d:7e:72,id=id9HRc5V,vectors=4,netdev=idjlQN53,bus=pci.0,addr=0xa \ -netdev tap,id=idjlQN53,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \ -m 2048,slots=4,maxmem=32G \ -smp 4 \ -vga std \ -vnc :1 \ -chardev socket,id=console0,path=/tmp/console0,server,nowait \ -device spapr-vty,chardev=console0 \ -cpu host \ -device usb-kbd \ -incoming tcp:0:5801 \ -device usb-mouse \ -qmp tcp:0:8881,server,nowait \ -msg timestamp=on \ -rtc base=localtime,clock=vm,driftfix=slew \ -monitor stdio \ -boot order=cdn,once=n,menu=on,strict=off \ -enable-kvm \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0xc \ -watchdog i6300esb \ -watchdog-action debug \ -name debug-threads=on \ migration both succeed for rhel7<->rhel8 So, I think this bug is fixed.
referring to comment 4, I will close this bug as CURRENTRELEASE, if there is something mistakes, you could update it.