Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1168252 - Multiple disks with same Alias (name)
Summary: Multiple disks with same Alias (name)
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.5.0
Assignee: Tal Nisan
QA Contact: Gal Amado
Whiteboard: storage
Depends On:
Blocks: rhev35rcblocker rhev35gablocker
TreeView+ depends on / blocked
Reported: 2014-11-26 14:04 UTC by Israel Pinto
Modified: 2016-02-10 16:41 UTC (History)
17 users (show)

Fixed In Version: org.ovirt.engine-root-3.5.0-23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-11-27 11:19:23 UTC
oVirt Team: Storage
Target Upstream Version:

Attachments (Terms of Use)
Disks in VM with the same name (deleted)
2014-11-26 14:05 UTC, Israel Pinto
no flags Details
java code (deleted)
2014-11-26 14:06 UTC, Israel Pinto
no flags Details
test logs (deleted)
2014-11-27 12:19 UTC, Gal Amado
no flags Details

System ID Priority Status Summary Last Updated
oVirt gerrit 35672 master MERGED core: Moved disk alias genenration in AddDiskCommand to execution Never
oVirt gerrit 35698 ovirt-engine-3.5 MERGED core: Moved disk alias genenration in AddDiskCommand to execution Never

Description Israel Pinto 2014-11-26 14:04:27 UTC
Description of problem:
Checking Java SDK with automtion test. The test failed since it try to remove disks from VM and gets number of disks with the same alias(name).

In order to reperduce this problem i worte Java code that add disk to exsit VM,
and also in this case the disks created with the same alias(name).

Test results from Jenkins:
11:50:03 ================================================================================
11:50:03 2014-11-26 11:50:03,229 - MainThread - plmanagement.unittest_loader - INFO - TEST GROUP tearDown: VmDiskJAVA
11:50:03 2014-11-26 11:50:03,230 - MainThread - rhevmtests.virt.reg_vms.reg_vms_test - INFO - Remove all disks from vm disk_vm
11:50:03 2014-11-26 11:50:03,475 - MainThread - art.rhevm_api.tests_lib.high_level.disks - INFO - Wait until disks state is OK
11:50:03 2014-11-26 11:50:03,606 - MainThread - plmanagement.unittest_loader - ERROR - Teardown failed: VmDiskJAVA, the reason: More than one Entities found for disk_vm_Disk1                                  on url ''.
11:50:03 2014-11-26 11:50:03,606 - MainThread - plmanagement.unittest_loader - INFO - 
11:50:03 ================================================================================

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

How reproducible:
Attched java code.

Actual results:
Different disks with the same name.
Attached screenshot

Expected results:
Different disks with different names.

Additional info:
1. This case works before in automation, now see it from this build.
2. The reproduce java code don't wait till disk created it continue to next creation.

Comment 1 Israel Pinto 2014-11-26 14:05:22 UTC
Created attachment 961673 [details]
Disks in VM with the same name

Comment 2 Israel Pinto 2014-11-26 14:06:52 UTC
Created attachment 961676 [details]
java code

Comment 3 Juan Hernández 2014-11-26 14:26:47 UTC
It is completely OK to have different disks with the same alias, the backend doesn't impose any restriction in these regards. Neither do the SDKs. So I think this should be closed as NOTABUG. Am I missing something?

Comment 4 Israel Pinto 2014-11-26 15:16:09 UTC
it automation blocker and did not happens is REST API.

Comment 5 Israel Pinto 2014-11-26 15:23:14 UTC
also the RFE that ask for the same alias denied

Comment 6 Juan Hernández 2014-11-26 15:30:28 UTC
Disks with the same aliases can be created using directly the RESTAPI, for example:

#!/bin/sh -ex


for i in {1..5}
  echo "${i}"
  curl \
  --insecure \
  --request POST \
  --user "${user}:${password}" \
  --header "Content-Type: application/xml" \
  --header "Accept: application/xml" \
  --data '
  ' \

Actually what that RFE requested was to prohibit same alias for two disks, and that is what was rejected, thus the behavior of the RESTAPI and the Java SDK is correct in these regards. Automation tests should not fail on this. Please close as NOTABUG or as a duplicate of the rejected RFE.

Comment 7 Raz Tamir 2014-11-27 09:13:05 UTC
Sorry for the change

Comment 8 Raz Tamir 2014-11-27 09:13:56 UTC
It also affect REST and SDK apis

Comment 9 Israel Pinto 2014-11-27 09:23:02 UTC
The problem is not only in JAVA API.
We run vt12 test without java and get the same problem.
Case VMdisk in CLI automation test:

Comment 10 Gal Amado 2014-11-27 09:40:26 UTC
It happens in 3.5-storage_backup_api_sanity as well - on REST .
It is true that we support having disks with the same alias.

The problem is that when we addDisk without alias the engine suggest a name and make sure it is unique by adding an incremental counter at the end (Disk1,Disk2,...).

That was the behavior till VT10.
Since VT11, the name suggested by the engine is the same (the counter is not incremented).

In engine log, you can see :
"Disk alias retrieved from the client is null or empty, the suggested default disk alias to be used is XXXX"

We shouldn't have the same suggested alias for 2 disks in the same vm.

Comment 12 Allon Mureinik 2014-11-27 11:19:23 UTC
Disk aliases are not unique by definition. Any automation that assumes they are is simply wrong.

Gal - with regard to the **suggested** aliases (comment 10), this is indeed a bug, but a much less severe one.
Please open a specific bug on this, with steps to reproduce and the relevant logs.

Comment 13 Gil Klein 2014-11-27 12:07:42 UTC
Allon, if comment #10 is true, this smells like a new regression that was introduced in VT11.

Could you help find out why was this behavior changed between VT10 and VT11?

Comment 14 Gal Amado 2014-11-27 12:10:12 UTC
engine.log is at :

In there, the same name "backup_api_vm_0_nfs_Disk1" is suggested twice for disks on the same VM, search for:
"Disk alias retrieved from the client is null or empty, the suggested default disk alias to be used is backup_api_vm_0_nfs_Disk1"

I have a developer job to reproduce :

For VT10, it works fine.

At the moment, our Automation relay on this feature, it fails our regression.

Comment 15 Gal Amado 2014-11-27 12:19:57 UTC
Created attachment 961999 [details]
test logs

Comment 16 Tal Nisan 2014-11-27 13:29:59 UTC
Are you trying to create the disks sequentially or all at the same time?
If one disk was not created yet it makes perfect sense that the next suggested alias will be the one suggested to the other disk.
The change that introduced what you are experiencing now just took the disk alias suggestion to an earlier phase in the command life cycle.
If I understand correctly, the fact that you got different aliases was merely because of timing and in any case you should rely on disk aliases for your automation whatsoever

Comment 17 Gal Amado 2014-11-27 16:58:33 UTC
Tal ,
This is not the case (#16).
It was done sequentially.
Please take a look at the engine.log I've attached.
in there you can clearly see that it suggested , than created the disk , and some 6 sec after that it suggested the same name again . 

Keep in mind that it is something that worked fine and broke.

Comment 18 Tal Nisan 2014-11-27 20:36:15 UTC
A fix to the specific problem has been posted but in any case and regardless to that - a disk alias is not a primary key, using it as a unique identifier in tests is definitely not that way to go, I'd consider moving the tests to use UUIDs in the future, nothing guarantees you the uniqueness of a disk alias and nothing guarantees you the order of suggestions of a new alias

Comment 19 Gal Amado 2014-12-07 11:32:40 UTC
verified by automation on : Red Hat Enterprise Virtualization Manager Version: 3.5.0-0.23.beta.el6ev

Passed both nfs and iscsi jobs :

Comment 20 Allon Mureinik 2015-02-16 19:13:56 UTC
RHEV-M 3.5.0 has been released, closing this bug.

Comment 21 Allon Mureinik 2015-02-16 19:13:59 UTC
RHEV-M 3.5.0 has been released, closing this bug.

Note You need to log in before you can comment on or make changes to this bug.