Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1057606

Summary: vdsm: we can write on a disk sent as read-only after detach/re-attach of the disk
Product: [Retired] oVirt Reporter: Dafna Ron <dron>
Component: vdsmAssignee: Ayal Baron <abaron>
Status: CLOSED NOTABUG QA Contact: Aharon Canan <acanan>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: abaron, acathrow, bazulay, gklein, iheim, mgoldboi, vered, yeylon
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: 3.4.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-13 07:56:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logs none

Description Dafna Ron 2014-01-24 13:02:11 UTC
Created attachment 854958 [details]
logs

Description of problem:

I created a vm with a read only disk. 
detached the disk from the vm -> reattached the disk 
after the disk is reattached the read only no longer appears on the webadmin however, when I run the vm, xml and engine show that it's read-only=true yet we can still write on it. 

Version-Release number of selected component (if applicable):

ovirt-engine-backend-3.4.0-0.5.beta1.el6.noarch

How reproducible:

100%

Steps to Reproduce:
1. create a vm with read only disk 
2. detach the disk from the vm 
3. re-attach the disk (it appears as r/w in webadmin)
4. run the vm (vm is run with read only in ovf)
5. install os on it

Actual results:

we can install OS on the vm although xml and engine shows that it's read only

Expected results:

if a disk is sent with read-only=true we should not be able to write to it. 

Additional info:

2014-01-24 07:46:20,410 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateVDSCommand] (ajp--127.0.0.1-8702-10) [20cfdf1b] org.ovirt.engine.core.vdsbroker.vdsbroker.CreateVDSCommand spiceSslCipherSuite=DEFAULT,memSize=1024,kvmEnable=true,smp=1,vmType=kvm,emulatedMachine=rhel6.5.0,keyboardLayout=en-us,memGuaranteedSize=1024,nice=0,display=qxl,smartcardEnable=false,smpCoresPerSocket=1,spiceSecureChannels=smain,sinputs,scursor,splayback,srecord,sdisplay,susbredir,ssmartcard,timeOffset=0,transparentHugePages=true,vmId=c30df1b5-6e16-4a82-8aca-67b5b1cec473,devices=[{specParams={vram=32768, heads=1}, device=qxl, type=video, deviceId=73b6457a-4ab4-4486-8a99-ff21473c343d}, {shared=false, iface=ide, index=2, specParams={path=}, path=, device=cdrom, type=disk, readonly=true, deviceId=c5783944-043a-4d9d-b8f7-8b4428f38cc3}, {shared=false, index=0, volumeID=1ad92396-ce0a-43ed-8a4e-00afbfb34448, propagateErrors=off, format=raw, type=disk, iface=virtio, bootOrder=2, domainID=be5731ac-ce60-4302-ab04-99573f6799e4, imageID=285c7f5d-9ea4-413b-b756-5a7c3f0947c9, specParams={}, optional=false, device=disk, poolID=6fe33247-68e1-4e46-be2a-ab90ab4384e3, readonly=false, deviceId=285c7f5d-9ea4-413b-b756-5a7c3f0947c9}, {bootOrder=1, nicModel=pv, specParams={}, macAddr=00:1a:4a:73:36:7a, device=bridge, linkActive=true, type=interface, filter=vdsm-no-mac-spoofing, network=ovirtmgmt, deviceId=704613b0-c225-47de-a92a-fdb7adb6cfdb}, {specParams={model=virtio}, device=memballoon, type=balloon, deviceId=25092842-3f89-45d1-9674-931c19f6d97a}, {index=0, model=virtio-scsi, specParams={}, device=scsi, type=controller, deviceId=01baa6b4-7c81-4441-8741-c8d724657f9f}],acpiEnable=true,vmName=vm,cpuType=Opteron_G2,custom={}

           <boot order="1"/>
                </interface>
                <disk device="cdrom" snapshot="no" type="file">
                        <source file="" startupPolicy="optional"/>
                        <target bus="ide" dev="hdc"/>
                        <readonly/>
                        <serial/>
                </disk>
                <disk device="disk" snapshot="no" type="file">

Comment 1 Dafna Ron 2014-01-24 13:07:39 UTC
sorry, vdsm: 
[root@cougar06 ~]# rpm -qa |grep vdsm 
vdsm-4.14.1-2.el6.x86_64
vdsm-python-4.14.1-2.el6.x86_64
vdsm-cli-4.14.1-2.el6.noarch
vdsm-python-zombiereaper-4.14.1-2.el6.noarch
vdsm-xmlrpc-4.14.1-2.el6.noarch

Comment 2 Ayal Baron 2014-01-25 21:30:50 UTC
The read-only=true refers to the cdrom.
The disk is sent with read-only=false (you can see it in the excerpt in comment #1):

{shared=false, index=0, volumeID=1ad92396-ce0a-43ed-8a4e-00afbfb34448, propagateErrors=off, format=raw, type=disk, iface=virtio, bootOrder=2, domainID=be5731ac-ce60-4302-ab04-99573f6799e4, imageID=285c7f5d-9ea4-413b-b756-5a7c3f0947c9, specParams={}, optional=false, device=disk, poolID=6fe33247-68e1-4e46-be2a-ab90ab4384e3, readonly=false, deviceId=285c7f5d-9ea4-413b-b756-5a7c3f0947c9}, {bootOrder=1, nicModel=pv, specParams={}, macAddr=00:1a:4a:73:36:7a, device=bridge, linkActive=true, type=interface, filter=vdsm-no-mac-spoofing, network=ovirtmgmt, deviceId=704613b0-c225-47de-a92a-fdb7adb6cfdb}, {specParams={model=virtio}, device=memballoon, type=balloon, deviceId=25092842-3f89-45d1-9674-931c19f6d97a}, {index=0, model=virtio-scsi, specParams={}, device=scsi, type=controller, deviceId=01baa6b4-7c81-4441-8741-c8d724657f9f}],acpiEnable=true,vmName=vm,cpuType=Opteron_G2,custom={}

Comment 3 Dafna Ron 2014-01-25 23:00:11 UTC
look at the engine log: 
 readonly=true,

There is a debugging issue here...  
the disk after re-attach will not appear to be read-only but unless the user is looking for it they will not know. 

than once the disk is written on, they will look at engine and see readonly=true... 
 
also, if readonly=true in engine and libvirt is running it as writeable I think its a problem 

I suggest looking into to this further before closing but your choice...

Comment 4 Itamar Heim 2014-01-26 08:10:25 UTC
Setting target release to current version for consideration and review. please
do not push non-RFE bugs to an undefined target release to make sure bugs are
reviewed for relevancy, fix, closure, etc.

Comment 5 Vered Volansky 2014-02-13 07:56:27 UTC
Engine log shows readonly is false for disk 1ad92396-ce0a-43ed-8a4e-00afbfb34448. Vdsm log shows the same for this disk (see comment #2).
When attaching a disk to a VM the RO property should be set, with no regard to its previous status. Actually, the way to edit a disk-vm RO relationship is to detach and re-attach it with a different RO status, so this is definately not a bug.

Relvant engine log excert:
{shared=false, index=0, volumeID=1ad92396-ce0a-43ed-8a4e-00afbfb34448, propagateErrors=off, format=raw, type=disk, iface=virtio, bootOrder=2, domainID=be5731ac-ce60-4302-ab04-99573f6799e4, imageID=285c7f5d-9ea4-413b-b756-5a7c3f0947c9, specParams={}, optional=false, device=disk, poolID=6fe33247-68e1-4e46-be2a-ab90ab4384e3, readonly=false, deviceId=285c7f5d-9ea4-413b-b756-5a7c3f0947c9}