Bug 1186683

Summary: [PowerKVM] LE guest failed to boot up with data-plane data disk if its system disk is also virtio-blk-pci
Product: [Retired] RHEV for Power Reporter: Gu Nini <ngu>
Component: qemu-kvm-rhevAssignee: David Gibson <dgibson>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: bugproxy, fnovak, hannsj_uhl, hhuang, knoel, mdeng, michen, qzhang, thuth, virt-maint, xuhan, ypu
Target Milestone: rc   
Target Release: ---   
Hardware: ppc64le   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-18 06:46:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1308609, 1359843    
Attachments:
Description Flags
Guest stalled with data-plane.png none

Description Gu Nini 2015-01-28 10:03:50 UTC 
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:
Comment 2 David Gibson 2015-01-29 04:24:34 UTC 
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 3 IBM Bug Proxy 2015-02-05 16:50:25 UTC 
------- 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
Comment 4 Gu Nini 2015-02-06 02:41:20 UTC 
Created attachment 988663 [details]
Guest stalled with data-plane.png

(In reply to David Gibson from comment #2)

Attached is the screenshot.
Comment 5 David Gibson 2015-02-06 04:53:43 UTC 
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.
Comment 6 Thomas Huth 2016-05-17 17:06:59 UTC 
Is this bug still an issue with the latest version of RHEV? If not, would it be ok to close it?
Comment 7 Qunfang Zhang 2016-05-18 02:43:33 UTC 
(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.
Comment 8 Qunfang Zhang 2016-05-18 02:49:44 UTC 
(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
Comment 9 Thomas Huth 2016-05-18 06:46:56 UTC 
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.