Bug 912263 - [RFE] VM/Template names uniqueness at DC or tenant level
Summary: [RFE] VM/Template names uniqueness at DC or tenant level
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.2.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Ori Liel
QA Contact: sefi litmanovich
URL:
Whiteboard:
Depends On: 1130090
Blocks: 1301236
TreeView+ depends on / blocked
 
Reported: 2013-02-18 08:59 UTC by Jiri Belka
Modified: 2019-10-10 09:06 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Virtual machine and template names only need to be unique within a data center, the names can be re-used in different data centers in the environment.
Clone Of:
Environment:
Last Closed: 2016-03-09 20:29:33 UTC
oVirt Team: Virt
sherold: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 41263 master MERGED engine: support non-unique vm and template names across DCs (#912263) Never
oVirt gerrit 52574 master MERGED frontend: Fix name uniqueness chack in ImportVmModel 2016-01-25 15:37:10 UTC
oVirt gerrit 52706 ovirt-engine-3.6 MERGED frontend: Fix name uniqueness chack in ImportVmModel 2016-01-26 16:10:12 UTC

Description Jiri Belka 2013-02-18 08:59:28 UTC
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.

Comment 1 Itamar Heim 2013-02-19 16:50:22 UTC
VM uniqueness we may want per "tenant", rather than per DC.

Comment 7 Barak 2015-05-05 19:40:05 UTC
Juan,

How will such a change influence the API ?

Comment 8 Juan Hernández 2015-05-06 08:49:16 UTC
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.

Comment 9 Michal Skrivanek 2015-05-13 11:26:29 UTC
(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

Comment 10 Ori Liel 2015-05-26 10:57:56 UTC
Patch posted: 

  https://gerrit.ovirt.org/#/c/41263/

Comment 13 Max Kovgan 2015-06-28 14:13:20 UTC
ovirt-3.6.0-3 release

Comment 14 sefi litmanovich 2015-12-28 14:05:01 UTC
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.

Comment 15 sefi litmanovich 2016-01-11 13:44:27 UTC
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.

Comment 16 sefi litmanovich 2016-01-11 14:26:18 UTC
Please see comments#14-15

Comment 17 Michal Skrivanek 2016-01-20 08:08:40 UTC
please investigate and open a followup bug if needed

Comment 18 Martin Betak 2016-01-21 16:00:17 UTC
Yes, I can confirm this is 100% reproducible, fix posted u/s.

Comment 19 Julie 2016-01-22 06:21:47 UTC
Hi Michal,
   Do you mean that vm and template names doesn't have to be unique across data centers?

Cheers,
Julie

Comment 20 Michal Skrivanek 2016-01-22 07:00:20 UTC
(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.

Comment 21 sefi litmanovich 2016-01-28 08:33:58 UTC
Verified with rhevm-3.6.3-0.1.el6.noarch according to steps in comment #14.

Comment 23 errata-xmlrpc 2016-03-09 20:29:33 UTC
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


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