[virt-tools-list] Can we obsolete virt-convert, virt-clone, virt-image?

[Cole Robinson]

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