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 _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
