On Wed, Apr 25, 2007 at 04:32:06PM +0900, Kazuki Mizushima wrote:
HI Daniel,
Hi Kazuki,
> I'm surprized the name for the new clone is not an
argument.
There is the clone which I think about for the purpose of reprinting
an as possible state as is. So this first revision is primmitive.
Also It is thought that information that must not overlap as a virtual
machine should change automatically. But I am thinking this enhaunce it
below.
1)--name new clone vm name
2)--mac new clone mac address
3)--format destination devies initialized befor cloning
4)--wait wait cloning porcess
I want to dettach the cloning process and to show the
state with the "cloning" by virsh.
Look this is all arguments already presents in some form at the
virt-manager level. There is just too many similarities to ignore it.
>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,
I see. So I put down to virsh used libvirt library instead of libvirt.
# but I also unterstand that put ing down to virsh cannot remote support
Remote support will need plugging at the API level. I think prototyping
within virt-manager will get you to more feedback and features faster.
Then in turn this will make the analysis required to check feasibility and
do the API design faster too. IMHO you will get where you want faster
if you do the first tool step in virt-manager, really.
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/