The decision on which device type to use for disks, network and video
cards on output used to be taken deep inside the converting functions.
This is not always desirable. In particular, there are scenarios when
this decision is made before the convertion takes place. E.g. in
in-place mode, the decisions are taken and the output VM configuration
is created outside of v2v tool.
This patchset adds support for such scenarios. Specifically,
- the input configuration parsers are taught to extract network and
video device models in addition to storage controllers
- the converting functions are taught to take the requested device types
into consideration
- the main routine in in-place mode takes the relevant data from the
input VM and passes it to the converter
The copying mode may eventually also profit from this patchset by taking
command-line options for controlling device types, but this isn't
included here.
Roman Kagan (4):
v2v: collect source network and video adapter types
v2v: introduce requested guestcaps type
v2v: take requested caps into account when converting
v2v: in-place: request caps based on source config
test-data/phony-guests/guests.xml.in | 8 +++
v2v/convert_linux.ml | 49 +++++++++++----
v2v/convert_windows.ml | 4 +-
v2v/input_disk.ml | 2 +
v2v/input_libvirtxml.ml | 32 ++++++++++
v2v/input_ova.ml | 2 +
v2v/modules_list.ml | 3 +-
v2v/modules_list.mli | 3 +-
v2v/test-v2v-i-ova-formats.expected | 1 +
v2v/test-v2v-i-ova-gz.expected | 1 +
v2v/test-v2v-i-ova-two-disks.expected | 1 +
v2v/test-v2v-print-source.sh | 4 +-
v2v/types.ml | 73 +++++++++++++++++++----
v2v/types.mli | 17 +++++-
v2v/v2v.ml | 58 +++++++++++++++++-
v2v/windows_virtio.ml | 108 ++++++++++++++++++++++++----------
v2v/windows_virtio.mli | 8 ++-
17 files changed, 309 insertions(+), 65 deletions(-)
--
2.5.0