Bug 1660809 - Migration failed with "qemu-kvm: Unknown ramblock "vga.vram"" when migrate a vm from RHEL7.6 to RHEL8.0
Summary: Migration failed with "qemu-kvm: Unknown ramblock "vga.vram"" when migrate a...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: qemu-kvm
Version: 8.0
Hardware: ppc64le
OS: Linux
high
high
Target Milestone: rc
: 8.0
Assignee: Laurent Vivier
QA Contact: xianwang
URL:
Whiteboard:
Depends On: 1656508
Blocks: 1600914
TreeView+ depends on / blocked
 
Reported: 2018-12-19 09:49 UTC by xianwang
Modified: 2019-05-22 07:56 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-07 07:21:12 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description xianwang 2018-12-19 09:49:51 UTC
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:

Comment 1 xianwang 2018-12-19 09:55:44 UTC
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.

Comment 2 Laurent Vivier 2018-12-19 12:39:42 UTC
(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.

Comment 5 Laurent Vivier 2018-12-21 13:25:35 UTC
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.

Comment 7 Laurent Vivier 2019-01-04 08:45:19 UTC
Could you re-test with qemu-kvm-3.1.0-3.el8 on destination host(rhel8.0 fasttrain)?

Comment 8 xianwang 2019-01-07 06:54:29 UTC
(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.

Comment 9 xianwang 2019-01-07 07:21:12 UTC
referring to comment 4, I will close this bug as CURRENTRELEASE, if there is something mistakes, you could update it.


Note You need to log in before you can comment on or make changes to this bug.