Bug 907132
| Summary: | [Storage] [Import VM] User can import several VMs and give them same name which must be prohibited. VM's name must be unique. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Leonid Natapov <lnatapov> |
| Component: | ovirt-engine | Assignee: | Arik <ahadas> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Leonid Natapov <lnatapov> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.2.0 | CC: | acathrow, amureini, dyasny, iheim, lpeer, michal.skrivanek, Rhev-m-bugs, sgrinber, yeylon, ykaul, yzaslavs |
| Target Milestone: | --- | ||
| Target Release: | 3.2.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | virt | ||
| Fixed In Version: | sf9 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Actually I see here if I'm not wrong several issues: 1. Allow importing several VMs providing the same name - this is fixed by the patch 2. Allow in the GUI to give the same name to multiple VMs, this should have been blocked, and we should allow only the option to provide a base-name + automated suffix - not solved here 3. The fact that VM name must be unique in the system, this is a big ticket item that we need to solve, especially for multi-tenant use case --> The above has another side effect, if we import VMs having the same names from multiple setup, we force clone to import (or manual modification of the name on the export domain) - even if images UUIDs differ and this is de-facto the different VM. (In reply to comment #4) > Actually I see here if I'm not wrong several issues: > > 1. Allow importing several VMs providing the same name - this is fixed by > the patch > > 2. Allow in the GUI to give the same name to multiple VMs, this should have > been blocked, and we should allow only the option to provide a base-name + > automated suffix - not solved here I agree, but I think this should be fixed in a separate bug. > > 3. The fact that VM name must be unique in the system, this is a big ticket > item that we need to solve, especially for multi-tenant use case > > --> The above has another side effect, if we import VMs having the same > names from multiple setup, we force clone to import (or manual modification > of the name on the export domain) - even if images UUIDs differ and this is > de-facto the different VM. Simon, do you agree with comment #5? moving to virt for addressing UI on import sf9. fixed. 3.2 has been released 3.2 has been released 3.2 has been released |
Description of problem: [Storage] [Import VM] User can import several VMs and give them same name which must be prohibited. VM's name must be unique. How to reproduce: 1.Create several VM's. (2 for example) 2.Export them to export domain. 3.Go to storage-->export domain--->import vms tab. 4.Highlight several VMs and do import. 5.Choose 'clone' option. 6.In the name tab give name "test" for all imported VMs. Import succeeded. Now you have several VMs in the Virtual Machines tab with the same name "test". This causes to bunch of problems. For example you can run only 1 VM because vdsm can not run several VMs with the same name and so on,so on. Backend should check if the exported VMs has the same name and prevent it. vdsm log: -------- Thread-13263::DEBUG::2013-02-03 12:43:59,328::vm::676::vm.Vm::(_startUnderlyingVm) vmId=`dbf2f88c-c409-4d4d-974d-e8694dd33ad3`::_ongoingCreations released Thread-13263::ERROR::2013-02-03 12:43:59,328::vm::700::vm.Vm::(_startUnderlyingVm) vmId=`dbf2f88c-c409-4d4d-974d-e8694dd33ad3`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 662, in _startUnderlyingVm self._run() File "/usr/share/vdsm/libvirtvm.py", line 1518, in _run self._connection.createXML(domxml, flags), File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 104, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2645, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: operation failed: domain 'derez' already exists with uuid e860391e-8551-419d-81d4-de9fb5d2911f Thread-13263::DEBUG::2013-02-03 12:43:59,344::vm::1047::vm.Vm::(setDownStatus) vmId=`dbf2f88c-c409-4d4d-974d-e8694dd33ad3`::Changed state to Down: operation failed: domain 'derez' already exists with uuid e860391e-8551-419d-81d4-de9fb5d2