On Tue, Feb 15, 2022 at 6:49 PM Richard W.M. Jones <[email protected]> wrote:
> This simply replaces the existing -oo rhv-direct option with a new -oo > rhv-proxy option. Note that using this option "bare" (ie. just “-oo > rhv-proxy”) does nothing in the current commit because the default is > still to use the proxy. > > Related: https://bugzilla.redhat.com/show_bug.cgi?id=2033096 > Thanks: Nir Soffer > --- > docs/virt-v2v-output-rhv.pod | 12 +++++------- > docs/virt-v2v.pod | 15 ++++++--------- > output/output_rhv_upload.ml | 8 +++++--- > tests/test-v2v-o-rhv-upload.sh | 1 - > 4 files changed, 16 insertions(+), 20 deletions(-) > > diff --git a/docs/virt-v2v-output-rhv.pod b/docs/virt-v2v-output-rhv.pod > index bd5e80c873..2ce697f4d7 100644 > --- a/docs/virt-v2v-output-rhv.pod > +++ b/docs/virt-v2v-output-rhv.pod > @@ -8,7 +8,7 @@ virt-v2v-output-rhv - Using virt-v2v to convert guests to > oVirt or RHV > [-op PASSWORD] [-of raw] > [-oo rhv-cafile=FILE] > [-oo rhv-cluster=CLUSTER] > - [-oo rhv-direct] > + [-oo rhv-proxy] > [-oo rhv-disk-uuid=UUID ...] > [-oo rhv-verifypeer] > > @@ -129,13 +129,11 @@ the specified UUIDs must not conflict with the UUIDs > of existing disks > > =back > > -=item I<-oo rhv-direct> > +=item I<-oo rhv-proxy> > > -If this option is given then virt-v2v will attempt to directly upload > -the disk to the oVirt node, otherwise it will proxy the upload through > -the oVirt engine. Direct upload requires that you have network access > -to the oVirt nodes. Non-direct upload is slightly slower but should > -work in all situations. > +Proxy the upload through oVirt Engine. This is slower than uploading > +directly to the oVirt node but may be necessary if you do not have > +direct network access to the nodes. > > =item I<-oo rhv-verifypeer> > > diff --git a/docs/virt-v2v.pod b/docs/virt-v2v.pod > index 143c50671c..f50d27a0f0 100644 > --- a/docs/virt-v2v.pod > +++ b/docs/virt-v2v.pod > @@ -86,8 +86,7 @@ interface(s) are connected to the target network called > C<ovirtmgmt>. > virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest \ > -o rhv-upload -oc https://ovirt-engine.example.com/ovirt-engine/api \ > -os ovirt-data -op /tmp/ovirt-admin-password -of raw \ > - -oo rhv-cafile=/tmp/ca.pem -oo rhv-direct \ > - --bridge ovirtmgmt > + -oo rhv-cafile=/tmp/ca.pem --bridge ovirtmgmt > > In this case the host running virt-v2v acts as a B<conversion server>. > > @@ -621,14 +620,12 @@ on the oVirt engine. > For I<-o rhv-upload> (L<virt-v2v-output-rhv(1)>) only, set the RHV Cluster > Name. If not given it uses C<Default>. > > -=item B<-oo rhv-direct> > +=item B<-oo rhv-proxy> > > -For I<-o rhv-upload> (L<virt-v2v-output-rhv(1)>) only, if this option is > given > -then virt-v2v will attempt to directly upload the disk to the oVirt > -node, otherwise it will proxy the upload through the oVirt engine. > -Direct upload requires that you have network access to the oVirt > -nodes. Non-direct upload is slightly slower but should work in all > -situations. > +For I<-o rhv-upload> (L<virt-v2v-output-rhv(1)>) only, proxy the > +upload through oVirt Engine. This is slower than uploading directly > +to the oVirt node but may be necessary if you do not have direct > +network access to the nodes. > > =item B<-oo rhv-verifypeer> > > diff --git a/output/output_rhv_upload.ml b/output/output_rhv_upload.ml > index 7c2434bde4..d3b5b412db 100644 > --- a/output/output_rhv_upload.ml > +++ b/output/output_rhv_upload.ml > @@ -50,9 +50,9 @@ module RHVUpload = struct > let query_output_options () = > printf (f_"Output options (-oo) which can be used with -o rhv-upload: > > - -oo rhv-cafile=CA.PEM Set ‘ca.pem’ certificate bundle > filename. > - -oo rhv-cluster=CLUSTERNAME Set RHV cluster name. > - -oo rhv-direct[=true|false] Use direct transfer mode (default: > false). > + -oo rhv-cafile=CA.PEM Set ‘ca.pem’ certificate bundle filename. > + -oo rhv-cluster=CLUSTERNAME Set RHV cluster name. > + -oo rhv-proxy Connect via oVirt Engine proxy (default: > true). > -oo rhv-verifypeer[=true|false] Verify server identity (default: false). > > You can override the UUIDs of the disks, instead of using autogenerated > UUIDs > @@ -97,6 +97,8 @@ after their uploads (if you do, you must supply one for > each disk): > rhv_cluster := Some v > | "rhv-direct", "" -> rhv_direct := true > | "rhv-direct", v -> rhv_direct := bool_of_string v > + | "rhv-proxy", "" -> rhv_direct := false > + | "rhv-proxy", v -> rhv_direct := not (bool_of_string v) > | "rhv-verifypeer", "" -> rhv_verifypeer := true > | "rhv-verifypeer", v -> rhv_verifypeer := bool_of_string v > | "rhv-disk-uuid", v -> > diff --git a/tests/test-v2v-o-rhv-upload.sh > b/tests/test-v2v-o-rhv-upload.sh > index f6aabda7cc..15d5d02818 100755 > --- a/tests/test-v2v-o-rhv-upload.sh > +++ b/tests/test-v2v-o-rhv-upload.sh > @@ -70,6 +70,5 @@ $VG virt-v2v --debug-gc -v -x \ > -o rhv-upload \ > -oc https://example.com/ovirt-engine/api \ > -oo rhv-cafile=/dev/null \ > - -oo rhv-direct \ > -op /dev/null \ > -os Storage > -- > 2.35.1 > Looks good, much more clear than the original name that nobody understood. Nir
_______________________________________________ Libguestfs mailing list [email protected] https://listman.redhat.com/mailman/listinfo/libguestfs
