Description of problem: Install a LE guest on virtio-blk-pci disk, then stop and reboot it up with a virtio-blk-pci data-plane data disk; the guest stalled at kernel booting up stage and failed to boot up, while BE guest and guests installed on spapr-vscsi disk could boot up successfully with a data-plane data disk. Besides, the problem has occurred on both RHEL and IBM power system. Version-Release number of selected component (if applicable): [Following are versions the issue occurred on power system:] Host power system kernel: 3.10.42-2018.1.pkvm2_1_1.46.ppc64 Qemu-kvm: qemu-img-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-kvm-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-common-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-system-ppc-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-kvm-tools-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-system-x86-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 qemu-2.0.0-2.1.pkvm2_1_1.20.40.ppc64 Guest system kernel: 3.10.0-223.ae17b.ppc64le How reproducible: 100% Steps to Reproduce: 1.Install a LE guest on virtio-blk-pci system disk 2.After the guest installation finishes, stop it an reboot up it with a virtio-blk-pci data-plane data disk as follows: /usr/bin/qemu-system-ppc64 -name virtioblkqcow-0127-le-1 -machine pseries-2.2,accel=kvm,usb=off -m 32768 -realtime mlock=off -smp 64,sockets=1,cores=16,threads=4 -uuid 95346a10-1828-403a-a610-ac5a52a29421 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/virtioblkqcow-0127-le-1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,clock=vm -no-shutdown -boot strict=on -device usb-ehci,id=usb,bus=pci.0,addr=0x2 -device pci-ohci,id=usb1,bus=pci.0,addr=0x1 -device spapr-vscsi,id=scsi0,reg=0x1000 -drive file=/media/ngu-nfs/virtioblkqcow-0127-le-1,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/media/ngu-nfs/iso/RHEL-LE-7.1-20150115.0-Server-ppc64le-dvd1.iso,if=none,id=drive-scsi0-0-1-0,readonly=on,format=raw,cache=none -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0,bootindex=2 -netdev tap,id=hostnet0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device spapr-vlan,netdev=hostnet0,id=net0,mac=52:54:00:c4:e7:21,reg=0x2000 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x30000000 -device usb-kbd,id=input0 -device usb-mouse,id=input1 -device usb-tablet,id=input2 -vnc 0:24 -device VGA,id=video0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0,max-bytes=1234,period=2000,bus=pci.0,addr=0x5 -msg timestamp=on -drive file=/media/ngu-nfs/test5,if=none,id=drive-virtio-disk1,format=raw,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x10,drive=drive-virtio-disk1,id=virtio-disk1,x-data-plane=on,config-wce=off,bootindex=3 3.Check if the guest could boot up Actual results: The guest stalled at kernel booting up stage and failed to boot up, please refer to the attached screenshot Expected results: The guest could boot up without any issue Additional info:
Hi, I think you forgot to attach the screenshot. I'm guessing this is probably the same upstream bug as either bug 1177094 or bug 1184290. I'll get it mirrored to IBM.
------- Comment From fnovak.com 2015-02-05 15:53 EDT------- reverse mirror of RHBZ 1186683 - [PowerKVM] LE guest failed to boot up with data-plane data disk if its system disk is also virtio-blk-pci
Created attachment 988663 [details] Guest stalled with data-plane.png (In reply to David Gibson from comment #2) Attached is the screenshot.
Uh.. that stall is much later in boot than I expected. That means it's not the same as bug 1184290, but it might be the same as bug 1177094.
Is this bug still an issue with the latest version of RHEV? If not, would it be ok to close it?
(In reply to Thomas Huth from comment #6) > Is this bug still an issue with the latest version of RHEV? If not, would it > be ok to close it? Hi, Min Could you help test it with latest kernel and qemu-kvm-rhev version? Thanks.
(In reply to Thomas Huth from comment #6) > Is this bug still an issue with the latest version of RHEV? If not, would it > be ok to close it? Hi, Thomas Do you need QE to test this bug and also bug 1184948 on the latest RHEV host? Since I heard from David before that nearly all the "RHEV for POWER" bugs had been cloned or fixed in RHEV already. Thanks, Qunfang
Hi Qunfang, that information from David is also my level of information, that's why I asked whether we could close these tickets nowadays. So assuming this was only the same problem as bug 1177094, I think we can close this ticket here directly. If anybody disagrees, feel free to open it again. Concerning bug 1184948, I'm not sure, it seems to have been opened by IBM, so we should wait some more days for input from their side, I think.