[Libguestfs] external call to v2v (vdsm integration)

Richard W.M. Jones rjones at redhat.com
Mon Sep 15 13:01:13 UTC 2014


On Mon, Sep 15, 2014 at 03:02:05PM +0300, Shahar Havivi wrote:
> On 15.09.14 12:40, Richard W.M. Jones wrote:
> > If you just run virt-v2v with neither of these options, then there is
> > the chance that virt-v2v will still be running -- unknown to you --
> > when VDSM starts up again.  This is probably not what you want.
> We still have a power outage issue,
> maybe a file with sha1 can be a good solution, ie when v2v finish copying the
> disk it can write to a file the sha1 of the disk in which case vdsm later can
> read and verify... it maybe too much vdsm can send SIGTERM if v2v is running
> when vdsm was down.

We could add something like a final status file option, something like:

  virt-v2v --status-file /var/tmp/output

which on success (only?) writes /var/tmp/output containing some
details of the run.  I'm not sure it's possible to have virt-v2v
reliably write a status file on failure, and certainly not if virt-v2v
crashes or the power goes out.  I don't think this helps you because
you still have a situation where virt-v2v might be running, the status
file doesn't exist, but you don't know that.

I still think a small wrapper process + socket is a better solution.
If the wrapper goes away, it's probably because of a power cut, so you
can also be sure that virt-v2v isn't running.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html




More information about the Libguestfs mailing list