Hide Forgot
Description of problem: Split from BZ890506. * DC vm names - a client could want to have complete "copy" of his "production" DC in different DC - same VM names... The reason why could be: migration/test, datacenter (location) switch, disaster recovery testing. A client could work on a migration, while "old" VM still running support team works on exact copy (same mac, ip address) in different DC, when migration is done, old VM is stopped, and routing/fw rules (VRF) are switch to point to "new" VM. Another scenario can be disaster recovery, production VM is running, exact copy is being installed/restored in different DC, then same switch on router/fw to give client ability to test DR server to testing/confirmation.
VM uniqueness we may want per "tenant", rather than per DC.
Juan, How will such a change influence the API ?
The RESTAPI server uses names in many places to resolve references to objects. For example, when a VM is created the name of the cluster and the name of the template are potentially used to lookup the corresponding objects: POST /vms <vm> <cluster> <name>mycluster</name> </cluster> <template> <name>Blank</name> </template> ... </vm> If any of these names is changed so it is no longer unique then the code that performs this look up will need to be changed accordingly. For example, in the example above new rules will be needed to select the right "Blank" template, otherwise the result of a request like this will be unpredictable. Ideally these new rules should be part of the backend, so the RESTAPI should pass to the backend the object name, and the backend should then apply whatever rules are needed to resolve the reference. The SDKs assume that the result of queries like "name=whatever" return at most one result, so user scripts that use the get by name method will start to behave in an unpredictable way. For example, with the Python SDK: myvm = api.vms.get(name="myvm") If there are two VMs named "myvm" the result of this method will be unpredictable. Same for the Java SDK. The CLI uses the Python SDK, so commands that use the "--name" option will start to behave in an unpredictable way as well. For example: # show vm --name myvm This used to return the VM with that name, but if there are more than one the result will be unpredictable.
(In reply to Juan Hernández from comment #8) > This used to return the VM with that name, but if there are more than one > the result will be unpredictable. it seems to me as a reasonable behavior to fail in that case with an error indicated the result is ambiguous and client needs to narrow down the results by specifying DC
Patch posted: https://gerrit.ovirt.org/#/c/41263/
ovirt-3.6.0-3 release
Tested on rhevm-3.6.2-0.1.el6.noarch. I have 2 * DC -> Cluster -> Host -> SD -> Export_Domain. 1. Create vm 'test' in DC1, create vm 'test' in DC2 - works. 2. Create vm 'test' in DC1, Create vm 'else' in DC2, update vm 'else' change name to 'test' - works. 3. Create vm 'test' in DC1, export vm to export_domain1, delete vm. Create vm 'test' in DC2, attempt to import vm 'test' in DC1 from export_domain1 - Didn't work, in import VM menu there's an exclamation mark under name with a message suggesting name already exists in env and vm's name should be changed. When changed, import succeeds. 4. Create template 'test' in DC1, create template 'test' in DC2 - works. 5. Create template 'test' in DC1, Create template 'else' in DC2, update template 'else' change name to 'test' - works. 6. Create template 'test' in DC1 from a working rhel6.7 os (or any) , create template 'test' in DC2 from a working rhel7.1 os (or any os different than the one in DC1). Create a vm from template 'test' in DC1, create a vm from template 'test' in DC2. Run vms. Verify each vm has started with the corresponding os - works. Summary ======= 1. one failure (test case 3). 2. Why is this change not implemented for vm pools as well, should be just the same I think. Please provide information before I verify.
Hi, Is there any new info regarding my summary? to be clear: 1. on Import vm, I cannot import a vm to DC-2 with same name as an existing vm in DC-1, so in this scenario the requirement for this RFE is not met. 2. I think that if we allow the reuse of Vm's and template's names in different DCs then we should allow the same with VM Pools - so that we can have 2 different DCs with the same VmPool (which translates to the same name vms as well which we allow). Please let me know if something is unclear.
Please see comments#14-15
please investigate and open a followup bug if needed
Yes, I can confirm this is 100% reproducible, fix posted u/s.
Hi Michal, Do you mean that vm and template names doesn't have to be unique across data centers? Cheers, Julie
(In reply to Julie from comment #19) > Hi Michal, > Do you mean that vm and template names doesn't have to be unique across > data centers? > > Cheers, > Julie yes, that's correct. For best result one should use the left-hand tree to filter the appropriate DC, otherwise there will be multiple entries with the same VM/Template in global view. This is not a must as there is a DC column for each entry so you can differentiate anyway.
Verified with rhevm-3.6.3-0.1.el6.noarch according to steps in comment #14.
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/RHEA-2016-0376.html