On 05/16/2012 05:05 PM, Itamar Heim wrote:
On 05/16/2012 05:08 PM, Michael Pasternak wrote:
On 05/16/2012 04:38 PM, Itamar Heim wrote:
please note "vm exists" is based on vm uuid, not on vm name
i think it based on name, Omer?
two different things: 1. vm name is unique. 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about).
i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics)
why import not changing ids by definition? this way only collision that might happen is a vm.name ..., i.e 'cannot import vm.x cause vm with same name already exist' ...
1. because we didn't have this behavior till now. 2. because for templates you may want to preserve the uuid to move over VMs/chains using it. 3. because import keeping uuid's allows to handle snapshot chains and re-use of template which does not require changing the actual images, still pointing to the low level actual file/chains (can also be fixed by separating internal uuid's and disks/snapshots uuids, but much more work)
ok, then implicit re-id can happen when importing already existent entity and only complaint will be entity name (which has to stay unique and user-defined). this way you does not force user to supply /X=true/ arg as it's obvious in this scenario. -- Michael Pasternak RedHat, ENG-Virtualization R&D