similar to: [PATCH FOR DISCUSSION ONLY] v2v: Add -o kubevirt output mode.

Fixes some of the more egregious problems with v1, and also applies properly to the head of git without needing any other patches. Rich.

On Thursday, 22 March 2018 16:24:23 CET Richard W.M. Jones wrote: > + (* Input transport affects whether some input options should or > + * should not be used. > + *) > + let input_transport = > + let is_query = input_options = ["?", ""] in > + let no_options () = > + if is_query then ( > + printf (f_"No -io (input options)

This change (mostly) has no effect, except I changed the content of two error messages to make them consistent with the others. --- v2v/cmdline.ml | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/v2v/cmdline.ml b/v2v/cmdline.ml index a72aa49..c294e57 100644 --- a/v2v/cmdline.ml +++ b/v2v/cmdline.ml @@ -334,6 +334,11 @@ read the man page

Currently we have a bunch of ad hoc options like --vddk* and --vdsm* (and proposed to add --rhv*) to handle extra parameters for input and output modes/transports. This complicates the command line parsing and also the clarity of the command line (becauseit's not very obvious which options apply to which side of the conversion). Replace these with a general mechanism for handling input and

I still have not found time to fully review the series, but I found out that this patch breaks VDDK. See below. On Thu, 22 Mar 2018 15:24:23 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: > Currently we have a bunch of ad hoc options like --vddk* and --vdsm* > (and proposed to add --rhv*) to handle extra parameters for input and > output modes/transports. This

Add a new output mode to virt-v2v: similar to -o local, the written metadata is a JSON file with the majority of the data that virt-v2v knowns about (or collects) during the conversion. This is meant to be used only when no existing output mode is usable, and a guest needs to be converted to run on KVM anyway. The user of this mode is supposed to use all the data in the JSON, as they contain

Add a new output mode to virt-v2v: similar to -o local, the written metadata is a JSON file with the majority of the data that virt-v2v knowns about (or collects) during the conversion. This is meant to be used only when no existing output mode is usable, and a guest needs to be converted to run on KVM anyway. The user of this mode is supposed to use all the data in the JSON, as they contain

Use Getopt.Symbol for options with a fixed list of choices, so there is no need to check them on our own. --- v2v/cmdline.ml | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/v2v/cmdline.ml b/v2v/cmdline.ml index 2d0a10a..96e0509 100644 --- a/v2v/cmdline.ml +++ b/v2v/cmdline.ml @@ -83,8 +83,7 @@ let parse_cmdline () = | "libvirt" -> input_mode

When converting and throwing away the output (-o null), the input format should not really matter. However it does currently matter for a couple of reasons: (1) If the input is not raw or qcow2, then you'll get the error below because virt-v2v wants to write the same output format as input format but only allows raw or qcow2 as output formats: virt-v2v: error: output format should be

Richard, Great progress. I really like it!!! Here is what I noticed: I see that in the yaml file we provide short-id as: os: osinfo: 'rhel7.2' whereas kubevirt expects it in metadata: metadata: labels: kubevirt.io/os: win10 For windows vms we need to create perset like this one [1]. We can add separator --- between the objects. Thanks, Piotr [1]

On Thu, Mar 29, 2018 at 05:26:13PM +0200, Piotr Kliczewski wrote: > Richard, > > Great progress. I really like it!!! > > Here is what I noticed: > > I see that in the yaml file we provide short-id as: > > os: > osinfo: 'rhel7.2' > > whereas kubevirt expects it in metadata: > > metadata: > labels: > kubevirt.io/os: win10 >

PROBLEMS: - Spools to a temporary disk - Need to specify direct/indirect upload via flag - Location of ca.pem - Target cluster - Delete disks on failure, or rename disks on success? - Handling of sparseness in raw format disks This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more

hi, i''m trying move from file: based disk to tap:aio but things don''t work i have centos4 dom0 with centos4 domU xen 3.0.4-testing changeset: 13138:d401cb96d8a0 self compiled [root@xen linux-2.6.16.38-xen]# grep XEN_BLKDEV_TAP .config CONFIG_XEN_BLKDEV_TAP=m config disk = [ ''file:/var/lib/xen/test.img,hda1,w'',

PROBLEMS: - Spools to a temporary disk - Target cluster - Delete disks on failure, or rename disks on success? - Handling of sparseness in raw format disks - Manual page This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more efficient than -o rhv because it does not need to go via the

PROBLEMS: - -of qcow2 does not work, with multiple problems * needs to set NBD size to something larger than virtual size - Cannot choose the datacenter. - Not tested against imageio which supports zero/trim/flush. This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more efficient

please look at http://www.voip-info.org/wiki/view/Asterisk+SRTP and try compile&run clients with srtp (linksys,gxp-2000, minisip, twikle, ...) --------------------------------------- Marek Cervenka Centrum Vypocetni Techniky CVT - http://cvt.fpf.slu.cz FPF SLU OPAVA - http://www.fpf.slu.cz LCNA - http://lcna.slu.cz =======================================

In this mode, converting of the VM configuration, setting up the rollback path for error cases, transforming the VM storage and so on is taken care of by a third-party toolset, and virt-v2v is only supposed to tune up the guest OS directly inside the source VM, to enable it to boot and run under the input hypervisor. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- changes from v1: -

This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more efficient than -o rhv because it does not need to go via the Export Storage Domain, and is possible for humans to use unlike -o vdsm. The implementation uses the Python SDK (‘ovirtsdk4’ module). An nbdkit Python 3 plugin translates

This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more efficient than -o rhv because it does not need to go via the Export Storage Domain, and is possible for humans to use unlike -o vdsm. The implementation uses the Python SDK (‘ovirtsdk4’ module). An nbdkit Python 3 plugin translates

The previous patches seem OK. On a quick glance this one also seems a good start. On Thu, 22 Feb 2018 13:57:25 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: > PROBLEMS: > - Spools to a temporary disk > - Need to specify direct/indirect upload via flag > - Location of ca.pem We surely need a new argument for that. When running on VDSM host the certificate