Libguestfs - Sep 2014 - external call to v2v (vdsm integration)

Hi,

I have several question regarding error handling when we call v2v from vdsm:

1. do you have return code values table?
2. how can vdsm determine if operations success/fail assuming vdsm crushed or
   the service restarted.
3. what is the best strategy to cancel blocked I/O calls?

Thanks,
  Shahar.

On Mon, Sep 15, 2014 at 02:16:32PM +0300, Shahar Havivi
wrote:
> Hi,
> 
> I have several question regarding error handling when we call v2v from
vdsm:
> 
> 1. do you have return code values table?
The program will either exit with status 0 (success) or non-zero
(failure).  It will print an error messsage to stderr before it exits.

Note that 'virt-v2v -o vdsm' mode assumes that VDSM is going to create
Data Storage Domain directories before it runs, and clean them up on
failure!  I hope this was clear when RHBZ#1140156 was done.
> 2. how can vdsm determine if operations success/fail assuming vdsm crushed
or
>    the service restarted.
One way to deal with this is to have a small wrapper that handles
virt-v2v, and receives commands from vdsm over a socket.  If you
assume that the wrapper is small, mostly bug free and so cannot crash,
then VDSM can reconnect to the wrapper in the event that it crashes or
is restarted.  Socket commands would be similar to: "Is virt-v2v
running?"  "Send me the latest output"  "Send me the exit
code" etc.

A simpler way is to send a signal (eg. SIGTERM) to virt-v2v when vdsm
goes down (assuming that you have somewhere that handles vdsm
crashes).  Virt-v2v should stop the conversion and exit fairly quickly
after receiving a signal (maybe not instantly).  If it doesn't then
that's a virt-v2v bug.

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.
> 3. what is the best strategy to cancel blocked I/O calls?
Not sure what this question means.  Can you give an example of how a
blocked I/O call would affect things?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

On 15.09.14 12:40, Richard W.M. Jones wrote:
> On Mon, Sep 15, 2014 at 02:16:32PM +0300, Shahar Havivi wrote:
> > Hi,
> > 
> > I have several question regarding error handling when we call v2v from
vdsm:
> > 
> > 1. do you have return code values table?
> 
> The program will either exit with status 0 (success) or non-zero
> (failure).  It will print an error messsage to stderr before it exits.
> 
> Note that 'virt-v2v -o vdsm' mode assumes that VDSM is going to
create
> Data Storage Domain directories before it runs, and clean them up on
> failure!  I hope this was clear when RHBZ#1140156 was done.
> 
> > 2. how can vdsm determine if operations success/fail assuming vdsm
crushed or
> >    the service restarted.
> 
> One way to deal with this is to have a small wrapper that handles
> virt-v2v, and receives commands from vdsm over a socket.  If you
> assume that the wrapper is small, mostly bug free and so cannot crash,
> then VDSM can reconnect to the wrapper in the event that it crashes or
> is restarted.  Socket commands would be similar to: "Is virt-v2v
> running?"  "Send me the latest output"  "Send me the
exit code" etc.
> 
> A simpler way is to send a signal (eg. SIGTERM) to virt-v2v when vdsm
> goes down (assuming that you have somewhere that handles vdsm
> crashes).  Virt-v2v should stop the conversion and exit fairly quickly
> after receiving a signal (maybe not instantly).  If it doesn't then
> that's a virt-v2v bug.
> 
> 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.
> 
> > 3. what is the best strategy to cancel blocked I/O calls?
> 
> Not sure what this question means.  Can you give an example of how a
> blocked I/O call would affect things?
ie while it copy the disk, but the SIGTERM is a good
solution.
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v