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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/