=head1 NAME

virt-v2v-output-rhv - Using virt-v2v to convert guests to oVirt or RHV

=head1 SYNOPSIS

 virt-v2v [-i* options] -o rhv-upload [-oc ENGINE_URL] -os STORAGE
                        [-op PASSWORD] [-of raw]
                        [-oo rhv-cafile=FILE]
                        [-oo rhv-cluster=CLUSTER]
                        [-oo rhv-direct]
                        [-oo rhv-disk-uuid=UUID ...]
                        [-oo rhv-verifypeer]

 virt-v2v [-i* options] -o rhv -os [esd:/path|/path]

 virt-v2v [-i* options] -o vdsm
                        [-oo vdsm-image-uuid=UUID]
                        [-oo vdsm-vol-uuid=UUID]
                        [-oo vdsm-vm-uuid=UUID]
                        [-oo vdsm-ovf-output=DIR]

=head1 DESCRIPTION

This page documents how to use L<virt-v2v(1)> to convert guests to an
oVirt or RHV management instance.  There are three output modes that
you can select, but only I<-o rhv-upload> should be used normally, the
other two are deprecated:

=over 4

=item B<-o rhv-upload> B<-os> STORAGE

Full description: L</OUTPUT TO RHV>

This is the modern method for uploading to oVirt/RHV via the REST API.
It requires oVirt/RHV E<ge> 4.2.

=item B<-o rhv> B<-os> esd:/path

=item B<-o rhv> B<-os> /path

Full description: L</OUTPUT TO EXPORT STORAGE DOMAIN>

This is the old method for uploading to oVirt/RHV via the
Export Storage Domain (ESD).  The ESD can either be accessed
over NFS (using the I<-os esd:/path> form) or if you have
already NFS-mounted it somewhere specify the path to the mountpoint
as I<-os /path>.

The Export Storage Domain was deprecated in oVirt 4, and so we expect
that this method will stop working at some point in the future.

=item B<-o vdsm>

This is the old method used internally by the RHV-M user interface.
It is never intended to be used directly by end users.

=back

=head1 OUTPUT TO RHV

This new method to upload guests to oVirt or RHV directly via the REST
API requires oVirt/RHV E<ge> 4.2.

You need to specify I<-o rhv-upload> as well as the following extra
parameters:

=over 4

=item I<-oc> C<https://ovirt-engine.example.com/ovirt-engine/api>

The URL of the REST API which is usually the server name with
C</ovirt-engine/api> appended, but might be different if you installed
oVirt Engine on a different path.

You can optionally add a username and port number to the URL.  If the
username is not specified then virt-v2v defaults to using
C<admin@internal> which is the typical superuser account for oVirt
instances.

=item I<-of raw>

Currently you must use I<-of raw> and you cannot use I<-oa preallocated>.

These restrictions will be loosened in a future version.

=item I<-op> F<password-file>

A file containing a password to be used when connecting to the oVirt
engine.  Note the file should contain the whole password, B<without
any trailing newline>, and for security the file should have mode
C<0600> so that others cannot read it.

=item I<-os> C<ovirt-data>

The storage domain.

=item I<-oo rhv-cafile=>F<ca.pem>

The F<ca.pem> file (Certificate Authority), copied from
F</etc/pki/ovirt-engine/ca.pem> on the oVirt engine.

If I<-oo rhv-verifypeer> is enabled then this option can
be used to control which CA is used to verify the client’s
identity.  If this option is not used then the system’s
global trust store is used.

=item I<-oo rhv-cluster=>C<CLUSTERNAME>

Set the RHV Cluster Name.  If not given it uses C<Default>.

=item I<-oo rhv-disk-uuid=>C<UUID>

This option can used to manually specify UUIDs for the disks when
creating the virtual machine.  If not specified, the oVirt engine will
generate random UUIDs for the disks.  Please note that:

=over 4

=item *

you B<must> pass as many I<-oo rhv-disk-uuid=UUID> options as the
amount of disks in the guest

=item *

the specified UUIDs must not conflict with the UUIDs of existing disks

=back

This option is considered advanced, and to be used mostly in
combination with I<--no-copy>.

=item I<-oo rhv-direct>

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.

=item I<-oo rhv-verifypeer>

Verify the oVirt/RHV server’s identity by checking the server‘s
certificate against the Certificate Authority.

=back

=head1 OUTPUT TO EXPORT STORAGE DOMAIN

This section only applies to the I<-o rhv> output mode.  If you use
virt-v2v from the RHV-M user interface, then behind the scenes the
import is managed by VDSM using the I<-o vdsm> output mode (which end
users should not try to use directly).

You have to specify I<-o rhv> and an I<-os> option that points to the
RHV-M Export Storage Domain.  You can either specify the NFS server
and mountpoint, eg. S<C<-os rhv-storage:/rhv/export>>, or you can
mount that first and point to the directory where it is mounted,
eg. S<C<-os /tmp/mnt>>.  Be careful not to point to the Data Storage
Domain by accident as that will not work.

On successful completion virt-v2v will have written the new guest to
the Export Storage Domain, but it will not yet be ready to run.  It
must be imported into RHV using the UI before it can be used.

In RHV E<ge> 2.2 this is done from the Storage tab.  Select the
export domain the guest was written to.  A pane will appear underneath
the storage domain list displaying several tabs, one of which is "VM
Import".  The converted guest will be listed here.  Select the
appropriate guest an click "Import".  See the RHV documentation for
additional details.

If you export several guests, then you can import them all at the same
time through the UI.

=head2 Testing RHV conversions

If you do not have an oVirt or RHV instance to test against, then you
can test conversions by creating a directory structure which looks
enough like a RHV-M Export Storage Domain to trick virt-v2v:

 uuid=`uuidgen`
 mkdir /tmp/rhv
 mkdir /tmp/rhv/$uuid
 mkdir /tmp/rhv/$uuid/images
 mkdir /tmp/rhv/$uuid/master
 mkdir /tmp/rhv/$uuid/master/vms
 touch /tmp/rhv/$uuid/dom_md
 virt-v2v [...] -o rhv -os /tmp/rhv

=head2 Debugging RHV-M import failures

When you export to the RHV-M Export Storage Domain, and then import
that guest through the RHV-M UI, you may encounter an import failure.
Diagnosing these failures is infuriatingly difficult as the UI
generally hides the true reason for the failure.

There are several log files of interest:

=over 4

=item F</var/log/vdsm/import/>

In oVirt E<ge> 4.1.0, VDSM preserves the virt-v2v log file for
30 days in this directory.

This directory is found on the host which performed the conversion.
The host can be selected in the import dialog, or can be found under
the C<Events> tab in oVirt administration.

=item F</var/log/vdsm/vdsm.log>

As above, this file is present on the host which performed the
conversion.  It contains detailed error messages from low-level
operations executed by VDSM, and is useful if the error was not caused
by virt-v2v, but by VDSM.

=item F</var/log/ovirt-engine/engine.log>

This log file is stored on the RHV-M server.  It contains more detail
for any errors caused by the oVirt GUI.

=back

=head1 SEE ALSO

L<virt-v2v(1)>.

=head1 AUTHOR

Richard W.M. Jones

=head1 COPYRIGHT

Copyright (C) 2009-2020 Red Hat Inc.
