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