Re: [Libguestfs] [PATCH 2/2] Add export to RHEV
On 01/04/10 14:37, Richard W.M. Jones wrote:
On Tue, Mar 30, 2010 at 05:14:46PM +0100, Matthew Booth wrote:
> Allow guests to be written to a RHEV NFS export storage domain.
>
> Add 'rhev' output method and -osd command-line option.
> Example command line:
>
> virt-v2v -f virt-v2v.conf -ic 'esx://yellow.rhev.marston/' \
> -o rhev -osd blue:/export/export RHEL3-32
>
> This will connect to an ESX server and write the guest 'RHEL3-32' to
> blue:/export/export, which is a pre-initialised RHEV export storage domain.
> + open($uuidgen, '<', '/proc/sys/kernel/random/uuid')
> + or die("Unable to open /proc/sys/kernel/random/uuid: $!");
This really exists? I'd be inclined to use the uuidgen command. It
probably does the same thing, but I bet it's much more portable.
I was looking to reduce dependencies, and I was too lazy to check the
availability of uuidgen. However, I see it's a part of util-linux-ng and
e2fsprogs in RHEL 5, so I guess it's pretty available :) I'll switch it.
> +package Sys::VirtV2V::Target::RHEV::NFSHelper;
What's the purpose of this module? It forks and changes EUID/EGID,
then runs a command, then execs /bin/true. I couldn't understand why
it doesn't just run the command directly, with a wrapper around that
to change EUID/EGID, ie. what is the reason for forking?
The primary purpose of NFSHelper is to be the writer half when reading
from source storage and writing to RHEV. In this case, the source
storage may require root privileges to read, so a fork is necessary.
Everywhere else I use it the fork is unnecessary. However, it's not
worth extending it to make the fork optional.
Anyhow, the OVF may be hideous, but the general outline of this
patch
is fine, so ACK.
Thanks.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490