[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] [PATCH][RFC] Adding Cloning Feature



On Tue, Apr 24, 2007 at 10:57:09PM +0900, Kazuki Mizushima wrote:
> Hi all,

  Hi Kazuki,

> I've been planing to adding cloning feature.

Hum, interesting usage, of course it sounds difficult to really
fully automate it in a completely generic way.

> Then, I tried to make the patch in the following way. 
> 
> 1)Get the XML used virDomainGetXMLDesc
> 2)Delete <uuid>, <mac> node element
>   This intened to automatically generated.
> 3)Changing <name>, <source dev> string node element
> 4)Fork "dd" process
> 5)Define XML used virDomainDefineXML
> 
> This feature is just a first revision, 

  Okay, so let's look first at how it would integrate in virsh ...
So the command take the domain reference and a comma separated list
of device. I assume it expect those device to be already available
(for example if using LVM they were already created) and already
initialized.
  I'm surprized the name for the new clone is not an argument.
I wonder how we could simplify the device creation, and also how
we could preinitialize the disks. It sounds to me a bit more on the
area of Cobbler than libvirt/virsh though.

> because I make this patch within current libvirt API limitation.
> Also Remote Cloining is Limited.
> But if we can libvirtd for feature, it will be enhance remote cloning
> based on this pach
> (as http://libvirt.org/remote.html#Remote_libvirtd_configuration)
> 
> Finally, to have to communicate with the demon remotely as libvirt library, 
> actually I want to put down to new libvirt API (e.g. virDomainClone).
> 
> Could you hear your comments about this ?

  The problem of adding a Clone operation at the libvirt level is that
it would be very hard to make it solid, I mean just modifying an XML
file is not hard, it's the checking of the state, the provisionning and
making sure that no disaster will happen if we try to start the domain
which are the hard part. I'm not sure we can do that in a relatively
generic fashion, it probably depends a lot on the scenario. 
  To get down to something concrete, suppose I have a domain with an
Apache server running a RHEL4 paravirt. The new API may sound like 
it could create a new domain with a similar Apache server, but:
    - how do we provision it ?
    - how do we avoid name clashes, i.e. IP, machine name, ...
      in practice it would mean changing settings in the server
    - are we using resource which may not be shared (or shareable)
 We would need to be very precise about what the API call does, and warn
about what it does not do, before I would start feeling comfortable about
adding it in libvirt,

  but it's definitely something which could have some value, at least in
some scenario !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]