Red Hat Bugzilla – Bug 1097622
Inconsistent VirtIO direct lun disk attachment behaviour.
Last modified: 2016-05-25 21:47:44 EDT
Description of problem: When a direct LUN is connected to a VM before it is booted. The disk is connected as <disk type='file' device='disk' snapshot='no'> Whereas a disk which is hot-plugged is connected in the following way: <disk type='block' device='lun' snapshot='no'> Version-Release number of selected component (if applicable): rhevm-3.3.2-0.50 How reproducible: 100% Steps to Reproduce: 1. Create a VM with a direct LUN attached 2. Start the VM 3. Check the xml definition (virsh -r <VM_NAME>) 4. Deactivate the disk 5. Activate the disk 6. Check the xml definition Actual results: The outputs are diferent Expected results: The outputs are the same. I assume that the "device=lun" is correct. Additional info: Tested on RHEV 3.4 beta and it behaves in the same way. VirtIO-scsi is not affected only VirtIO
What's the impact (besides using different XMLs)?
(In reply to Allon Mureinik from comment #1) > What's the impact (besides using different XMLs)? The guest system is not able to get the scsi id of the device for instance if the device is set to disk. from libvirt documentation: Using "lun" behaves identically to "disk", except that generic SCSI commands from the guest are accepted and passed through to the physical device.
I was not able to reproduce the problem. In the case of hotplugging the disk, it's true that the device is set to LUN but no scsi information is accessible because it's treated as a VirtIO vdX device. When you use the virtio-scsi driver the guest receives the scsi information correctly. Can you please attach the logs to see if you have something different?
(In reply to Xavi Francisco from comment #3) > I was not able to reproduce the problem. In the case of hotplugging the > disk, it's true that the device is set to LUN but no scsi information is > accessible because it's treated as a VirtIO vdX device. When you use the > virtio-scsi driver the guest receives the scsi information correctly. > > Can you please attach the logs to see if you have something different? Yes, but even VirtIO block is able to pass scsi commands. Here is my example when I use iSCSI target and VirtIO block with LUN. # scsi_id --page=0x83 --device=/dev/vda --whitelist 1IET 00010001 The same command with VirtIO block without LUN does not return anything. I can attach logs is needed. But you should be able to reproduce by this command.
bug reproduced on beta.2,the disk data has changed,but still very unclear and confusing vdsm version vdsm-4.16.0-42.git3bfad86.el6.x86_64 lun inactive: <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source startupPolicy='optional'/> lun active: <disk type='block' device='lun' snapshot='no'> <driver name='qemu' type='raw' cache='none' error_policy='stop' io='native'/> <source dev='/dev/mapper/360060160f4a03000fc65675991dbe311'/>
Why are you testing this with the CD-ROM?
Created attachment 922101 [details] vdsm+engine logs the bug reproduced via "steps to reproduce" logs attached as asked
Hi Ori, The cdrom device is being sent by default upon running a VM (so it shouldn't be related to the lun device). According to the attached logs [1], on hot-plugging a direct LUN disk, the disk tag gets 'device="lun"' - as it should. Now, it should be verified that same happens on run VM; I couldn't find in the attached logs the VM xml output with the active lun disk. Can you please verify that same result is achieved in this case? [1] Thread-54::DEBUG::2014-07-29 13:22:53,427::vm::3841::vm.Vm::(hotunplugDisk) vmId=`bc504a24-7eba-4a78-8ff0-85f16cf4e5f2`::Hotunplug disk xml: <disk device="lun" snapshot="no" type="block"> <address bus="0x00" domain="0x0000" function="0x0" slot="0x07" type="pci"/> <source dev="/dev/mapper/360060160f4a03000fb65675991dbe311"/> <target bus="virtio" dev="vdc"/> <serial></serial> <driver cache="none" error_policy="stop" io="native" name="qemu" type="raw"/> </disk>
verified on rc1 build
Please supply doc text
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0158.html