On 01/10/2014 04:49 PM, Richard W.M. Jones wrote: > virt-convert & virt-image: > > These tools depend on the virt-image format, a noble attempt to make a > non-proprietary version of OVF. I think there is still a need to make > an open version of the horrible proprietary fake-standard of OVF, but > virt-image isn't it. > Agreed on virt-image, and no one ever really used it. Though there are tools out there that have generated virt-image format (despite my suggestion): boxgrinder and appliance-tools at least. No idea if anyone is still using those or if they ever even worked. virt-image has more or less been obsoleted for years in the fact that it has accumulated no new features, except those that facilitate regression testing. But until someone comes up with a better picture of tools that might depend on it, we can't remove it outright. > Having these tools does create confusion for users (particularly > versus when they should run 'qemu-img convert' or virt-v2v) so I think > we should drop them. virt-convert is a different story. Indeed it isn't too useful in its current form, but it would be marginally more work to allow doing conversion to straight libvirt XML, which I've had on my shrinking todo list for virt-manager 1.0 at least. I think there's value in a tool that just does OVF/vmdk/blah -> libvirt XML. There's all sorts of crazy images out there like a minix OVF that virt-v2v will never support. Honestly I wouldn't mind if the tool disappeared, but in some small way it does leave a hole that we should at least consider. > > virt-clone: > > This tool is supposed to clone existing images. But you can just run > dd/cp to clone the disks + 'virt-install --import' to create libvirt > configuration. > Sure, but that's kind of like dismissing virt-install with 'you can just create the XML by hand and virsh define it.' The whole purpose of the tool is to simplify those steps. > To do full cloning you will really need something a lot more advanced > that can see inside the disks, ie. virt-sysprep, or that can sparsify > disks (virt-sysprep), or that can do templating (virt-builder et al). > > virt-clone is troublesome for me. Most people I meet who try to use > it should be using virt-sysprep. > All this is ignoring the fact that there are people out there successfully using virt-clone/virt-manager clone, and that despite its limited nature, it suits their needs. When it breaks, people complain. Is the tool terribly interesting or doing anything particularly difficult? Not at all. But it currently provides value. And really, if an end user just wants to clone a single VM for local test purposes (the common use case I've seen), telling them to use dd and virt-install --import isn't very friendly. virt-sysprep is great, and far more interesting, and doing far more valuable work. But just taking away virt-clone because there's confusion is going to piss off users because there isn't any alternative right now to what it does. - Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
