This allows specific NICs (identified by their source MAC address) to
be mapped to networks or bridges on the target. You can use the --mac
parameter to select this mapping, eg:
$ virt-v2v ... \
--mac 52:54:00:d0:cf:0e:network:mgmt \
--mac 52:54:00:d0:cf:0f:network:clientdata
The old --network and --bridge mappings can also be used but --mac
takes precedence.
Note this does not adjust MAC addresses inside the guest which is a
hard problem to solve. For this to work you must still carry over the
MAC addresses from the source to target hypervisor as that is how most
guests identify and associate functions with specific network
interfaces.
Due to a conflict with the IDs of the OVF standard, and the existing
implementation in ovirt-engine, the ID of QXL devices changed to a
different value.
As a consequence, change the ResourceType of QXL devices, but only in
OVirt flavour to avoid breaking vdsm mode.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1598715#c5
virt-v2v moves guests, it doesn't clone them. Therefore we should try
to preserve the VM Generation ID (genid) as much as possible.
This has the ability to read the genid from VMware VMX files and
libvirt XML (but note RHBZ#1598348). It can also write the genid to
libvirt (‘-o libvirt’, ‘-o local’) and QEMU (‘-o qemu’).
We are missing support currently for all OVF-based formats (hence
‘-i ova’, and all oVirt/RHV output modes). It's unclear where we
would store the genid in this format. oVirt does not yet support
genid (see RHBZ#1118825).
Instead of storing the original network name (s_vnet_orig) in the
source NIC struct and then trying to guess what happened much later
when we're writing target metadata, get our newly created Networks
abstract data type to store the precise mapping explanation.
For direct upload, a suitable host must be in status 'Up'
and belong to the same datacenter as the created disk.
Added these criteria to the host search query.
Currently unused, this method will allow output methods to prepare the
target hypervisor to receive a guest before the actual copy/upload
begins.
For rhv-upload this is useful since RHV would prefer to have the
metadata for the guest before receiving disk data. The only metadata
unavailable here is target_stats.target_actual_size, but in the RHV API
case this is never available as we stream the data directly into RHV
rather than writing it to a local file.
This change avoids us threading the targets structure awkwardly
through several functions, and also makes it clear from the code that
the targets struct does not change after its creation in init_targets
(but the stats change).
Just code refactoring.
The optimization to start the transfer on the local host makes sense
only when using the rhv-direct=true option. When using a proxy, let the
engine choose a host.
When optimizing the connection using unix socket, we handle these cases:
- The local host is not an oVirt host (no /etc/vdsm/vdsm.id).
- The local host is an oVirt host, but is not registered with engine.
- Creating UnixHTTPConnection() fails. Unlikely and probably a bug in
the plugin, but we can recover by using the https connection.
The current code handle these cases silently, making it harder to
understand why the unix socket optimization did no happen. Add debug
message to make this clear.
Also comment in the error handler why we take this path instead of
failing the operation.
Old imageio proxy was using Authorization header for GET and PUT
requests. Remove unneeded authorization when sending OPTIONS request.
Remove unneeded duplicated comments about authorization for old
imageio, and replace them with a comment when we set needs_auth.
Add the podcheck.pl test, to make sure the documentation is in sync with
the available options.
Also fix the formats of options in the current POD, so it matches what
used already in other documentations, and what podcheck.pl expects.
In the case where virt-v2v runs on the same server as the imageio
daemon that we are talking to, it may be possible to optimize access
using a Unix domain socket.
This is only an optimization. If it fails or if we're not running on
the same server it will fall back to the usual HTTPS over TCP
connection.
Thanks: Nir Soffer, Daniel Erez.
Previously we lazily requested the server options in the can_*
callbacks. The can_* callbacks are always called by nbdkit straight
after open, so this just adds complexity for no benefit. This change
simply makes the code always fetch the server options during the open
callback.
This is — functionally at least — mostly just refactoring. However I
also added a useful debug message so we can see what features the
imageio server is offering.
"http" and "transfer" variables were missing in emulate_zero, so the
code would fail with NameError. This can happen only when communicating
with old imageio versions not supporting the "zero" feature.
Testing with qemu-img 2.12 show that we never send emulated zero request
because of the highestwrite mechanism, but it can break with older
qemu-img-rhev used on RHEL.
Python manual warns[1]:
Note that you must have read the whole response before you can send
a new request to the server.
The reason for this warning is exposed only when the server is using
keep alive connections. When the response is not read, sending a new
request will fail with:
httplib.ResponseNotReady
Even if Content-Length was 0 or the request has no content. The failure
looks like this when using --verbose:
nbdkit: python[1]: debug: zero count=33554432 offset=0 may_trim=1 fua=0
nbdkit: python[1]: debug: zero count=33554432 offset=33554432 may_trim=1 fua=0
nbdkit: python[1]: error: /home/nsoffer/src/libguestfs/tmp/rhvupload.Au2B5I/rhv-upload-plugin.py: zero: error: Request-sent
nbdkit: python[1]: debug: sending error reply: Input/output error
qemu-img: error writing zeroes at offset 0: Input/output error
Change all requests to read the whole response.
Tested with imageio patch supporting keep alive connections:
https://gerrit.ovirt.org/#/c/92296/
[1] https://docs.python.org/3.8/library/http.client.html#http.client.HTTPConnection.getresponse
The new ‘-o rhv-upload’ output mode contains a '-' character in the
name, but the regular expression which matched the output of the
virt-v2v command did not recognize '-' as a valid character. It ended
up mapping this to just "rhv" meaning two "rhv" entries would appear
in the list of output drivers.
Thanks: Ming Xie.
Virt-v2v transfers to newer versions of ovirt-engine can fail with:
ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "failed to parse a given ovf configuration ovf error: [empty name]: cannot read '//*/disksection' with value: null". HTTP response code is 400.
This was caused by a change made to oVirt:
https://gerrit.ovirt.org/#/c/91902/
so that it now requires the <Disk ovf:capacity> attribute.
Thanks: Arik Hadas
When sending request with small or no payload, it is simpler and
possibly more efficient to use the high level HTTPSConnection.request(),
instead of the lower level APIs.
The only reason to use the lower level APIs is to avoid copying the
payload, or on python 2, to use a bigger buffer size when streaming a
file-like object.
The 'localmountpoint' variable in the handle is available only when
building with FUSE support, so guard it in a proper #ifdef block.
Fixes commit 296370fb86.
Thanks to: Corentin Labbe (both reporting, and testing)
