On 05/16/2012 04:17 PM, Michael Pasternak wrote:
On 05/16/2012 04:05 PM, Itamar Heim wrote:
On 05/16/2012 03:49 PM, Michael Pasternak wrote:
On 05/16/2012 03:26 PM, Gilad Chaplik wrote:
Thanks,
Gilad.
----- Original Message -----
From: "Ori Liel"<ol...@redhat.com>
To: "Michael Pasternak"<mpast...@redhat.com>
Cc: "engine-devel"<engine-devel@ovirt.org>, "Itamar Heim"<ih...@redhat.com>, "Doron
Fediuck"<dfedi...@redhat.com>,
"Gilad Chaplik"<gchap...@redhat.com>
Sent: Wednesday, May 16, 2012 2:49:17 PM
Subject: Re: restapi: New params for import VM/Template
On 05/16/2012 01:16 PM, Gilad Chaplik wrote:
Hi All,
I am adding the ability to import a VM or a Template to a
storage-domain,
when this VM or Template already exists in the destination storage
domain.
Until now, Backend failed this. Now I want to enable the user to
specify
that he wishes this VM/Template will be created again by a
different name,
i.e - cloned.
[feature page:
http://www.ovirt.org/wiki/Features/ImportMoreThanOnce]
I plan to achieve this using a new parameter, but I want to reach
an agreement
about this parameter's name. I thought simply to call it "clone".
Another thing that I'll do in the patch-set is add the
currently-missing ability
to specify whether the snapshots of the VM, which is being
imported, will
be collapsed into a single snapshot (we have this ability in GUI).
I am also
deliberating about the name of this parameter. I thought about
"collapse_snapshots" (same as in GUI).
Does anyone think "clone" and "collapse_snapshots" are
inappropriate and has
/clone/ already in-use (used to clone vm from template),
clone here has a different context, clone VM vs. clone disks.
having two clone elements in vm will be confusing.
-1
<vm>
<disks>
<clone>true|false</clone>
...,
you can simply say if imported vm has<name> element, this is
import+clone, otherwise import,
If in the future we will want to enable overriding a VM's params on
import, this will be confusing
(because a user might want to import a VM and change it's name - but
not clone it if it already exists).
+1, cloning a vm and changing the vm's metadata (i.e vm's name) should not be
inter-dependent.
how exactly this is contradict changing metadata on the fly?,
exactly on opposite - it works perfectly well for your use-case:
BE logic:
--------
if (local<storage>) has vm named as on remote<storage> (export.domain)
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)
{
if PARAMS<name> != remote<name> (export.domain)
{
copy + rename
} else {
error
}
} else {
if PARAMS<name> != remote<name> (export.domain)
{
copy + rename
} else {
copy
}
}
as about collapse_snapshots, i don't mind, but this should be done
in the way<clone> is implemented
in<disks> collection
Semantically, a snapshot is a point in time of a VM. It not only
associated any more only with the VM's
disks; it includes the VM's meta-data as well. For this reason, maybe
the parameter collapse_snapshots
should not be in<disks> collection (although, technically, the
collapse will be done on disks)
+1, I think the collapse_snapshots should be in the vm context (snapshots is
under vm).
i meant<snapshots>, see my other email on this.
Other than that, currently, if you want to clone a vm, it must be 'collapsed
snapshots', so
the flow to clone a vm (with your suggestion) will be:
<action>
<vm>
<name>new_vm</..>
<disks>
<collapse_snapshot>true</..>
</..>
</..>
<clone>true</..>
</..>
where collapse_snapshot should be superior to clone, this structure is a bit
confusing.
better suggestions?
Thanks,
Gilad
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
