Created attachment 927812 [details] vdsm.log Description of problem: Tried to run a prepareImage via vdsClient, only I've given it a wrong SPUUID value. The command succeeded and the volumes in the image were prepared. Version-Release number of selected component (if applicable): vdsm-4.16.1-6.gita4a4614.el6.x86_64 vdsm-cli-4.16.1-6.gita4a4614.el6.noarch How reproducible: Always Steps to Reproduce: on block storage: 1) Create a VM with disk 2) From vdsClient run the PrepareImage command with an incorrect spUUID Actual results: The host is connected to this pool: [root@nott-vds2 ~]# vdsClient -s 0 getConnectedStoragePoolsList 1500df81-6ddb-409f-9cb8-1704df334b2f Volume 3f1462e3-1a73-4ad9-b5a1-0a3a18c1c478 is inactive: 3f1462e3-1a73-4ad9-b5a1-0a3a18c1c478 8000251e-7bba-4d4a-b8e6-42a40ed2e517 -wi------- 7.00g After that, I executed the prepareImage command with a wrong SPUUID value: [root@nott-vds2 ~]# vdsClient -s 0 prepareImage balblabla 8000251e-7bba-4d4a-b8e6-42a40ed2e517 1c375ec6-1362-4202-9960-c3f6080ef648 Now the LV is active: 3f1462e3-1a73-4ad9-b5a1-0a3a18c1c478 8000251e-7bba-4d4a-b8e6-42a40ed2e517 -wi-a----- 7.00g The same case for teardownImage Expected results: If the SPUUID value is mandatory for prepareImage and teardownImage, a wrong value should cause the command execution to fail Additional info: vdsm.log
Even though the fix is trivial I am not 100% sure that flows in vm.py are not relying on this bug (scary). There could be unusual recovery flows that may accidentally call prepareImage even when we're not connected to the pool. Either we do an extended QA cycle that verifies all the VM negative flows or we should postpone this to 3.6 (or 3.5.1 if you think it's worth). I don't think it's worth taking the risk right now. Anyway I'll push the patch to gerrit shortly.
Storage pool UUID validation is being done correctly. Tried to execute prepareImage with a wrong UUID and the operation wasn't allowed: Unknown pool id, pool not connected: ('-e62b-4bc0-a883-100439c183db',) Verified using ovirt 3.6.0-1
Putting this back to assigned, the bug is fixed for prepareImage but not for teardownImage: [root@storage-ge2-vdsm3 ~]# vdsClient -s 0 teardownImage incorrectspuuid d72a75fd-306b-48c7-8f33-767549a2e80b de700f46-d00f-4c23-8e9f-5aebe2410d1b d81e75c7-6f1a-46e3-98eb-93db12cad0f3 OK versions: vdsm-4.17.0-1239.git6575e3f.el7.noarch vdsm-cli-4.17.0-1239.git6575e3f.el7.noarch ovirt 3.6.0-5
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high
vdsClient is not supported and not something we're going to put effort into. closing.