similar to: [PATCH virt-v2v] v2v: -o libvirt: Remove cache=none.

Traditionally if you did live migration (KVM to KVM), you had to ensure that cache=none was set on all disks of the guest up front. This was because of quirks in how NFS works (I think the close-to-open consistency and the fact that during live migration both qemus have the file open), and we had to assume the worst case that a guest might be backed by NFS. Because of this when virt-v2v converts

On Fri, Nov 23, 2018 at 12:39:44PM +0100, Martin Kletzander wrote: > There's a standardized libosinfo namespace for libvirt domain metadata. For now > it supports the id of the OS only. However that is still a very helpful feature > that is already supported in gnome-boxes and virt-manager (at least). > > The discussion happened here: > >

There's a standardized libosinfo namespace for libvirt domain metadata. For now it supports the id of the OS only. However that is still a very helpful feature that is already supported in gnome-boxes and virt-manager (at least). The discussion happened here: https://www.redhat.com/archives/libosinfo/2018-September/msg00003.html So let's add the support to local and libvirt outputs.

On Wed, Apr 05, 2017 at 02:43:11PM +0100, Richard W.M. Jones wrote: > When outputting libvirt XML, create virtio-rng, a memory balloon > device, and a pvpanic device, if the guest supports it. > --- > v2v/create_libvirt_xml.ml | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/v2v/create_libvirt_xml.ml b/v2v/create_libvirt_xml.ml > index

When outputting libvirt XML, create virtio-rng, a memory balloon device, and a pvpanic device, if the guest supports it. --- v2v/create_libvirt_xml.ml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/v2v/create_libvirt_xml.ml b/v2v/create_libvirt_xml.ml index fc7196595..58f720ac3 100644 --- a/v2v/create_libvirt_xml.ml +++ b/v2v/create_libvirt_xml.ml @@ -338,6 +338,25 @@

There's a standardized libosinfo namespace for libvirt domain metadata. For now it supports the id of the OS only. However that is still a very helpful feature that is already supported in gnome-boxes and virt-manager (at least). The discussion happened here: https://www.redhat.com/archives/libosinfo/2018-September/msg00003.html So let's add the support to local and libvirt outputs.

Avoids the libvirt error: error: XML error: CPU vendor specified without CPU model --- v2v/create_libvirt_xml.ml | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/v2v/create_libvirt_xml.ml b/v2v/create_libvirt_xml.ml index 582419f00..fbe90eeaa 100644 --- a/v2v/create_libvirt_xml.ml +++ b/v2v/create_libvirt_xml.ml @@ -51,15 +51,17 @@ let create_libvirt_xml

When creating the XML for the new guest, always put the name of the pool containing the disks, even when -os specified a pool UUID: libvirt does not handle pool UUIDs for storage, but only names. --- v2v/output_libvirt.ml | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/v2v/output_libvirt.ml b/v2v/output_libvirt.ml index 5fa338f..e934335 100644 ---

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

QEMU for x86 supports two machine types, "pc" (emulating the ancient Intel i440FX chipset originally used by the Pentium Pro), and "q35" (https://wiki.qemu.org/Features/Q35). Currently virt-v2v does not set any machine type, so libvirt or the target hypervisor will choose some default, probably i440fx. The latest advice from the QEMU and libvirt communities is not to rely on

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

On Tue, Jun 19, 2018 at 11:37:46AM +0100, Richard W.M. Jones wrote: > QEMU for x86 supports two machine types, "pc" (emulating the ancient > Intel i440FX chipset originally used by the Pentium Pro), and "q35" > (https://wiki.qemu.org/Features/Q35). > > Currently virt-v2v does not set any machine type, so libvirt or the > target hypervisor will choose some

All the current output modes use the default, It's just that I have a patch that uses this, so there might be someone in the future who wants to use this and if not, then at least you can tell me if this is wrong or not. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- v2v/types.ml | 15 +++++++++++++++ v2v/types.mli | 8 +++++++- v2v/v2v.ml | 17 +++-------------- 3

Create the correct tags for <video> in the libvirtxml, so all the attributes are in a <model> child of <video> instead of <video> itself. Adapt the XML of test-v2v-i-ova to the different expected XML. --- v2v/output_libvirt.ml | 9 +++++---- v2v/test-v2v-i-ova.xml | 4 +++- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/v2v/output_libvirt.ml

This is just a refactoring and doesn't change the meaning of the code. --- v2v/output_libvirt.ml | 60 +++++++++++++++++++++++++-------------------------- 1 file changed, 29 insertions(+), 31 deletions(-) diff --git a/v2v/output_libvirt.ml b/v2v/output_libvirt.ml index 68af3de..d1cbaa1 100644 --- a/v2v/output_libvirt.ml +++ b/v2v/output_libvirt.ml @@ -222,46 +222,44 @@ let create_libvirt_xml

QEMU for x86 supports two machine types, "pc" (emulating the ancient Intel i440FX chipset originally used by the Pentium Pro), and "q35" (https://wiki.qemu.org/Features/Q35). Currently virt-v2v does not set any machine type, so libvirt or the target hypervisor will choose some default, probably i440fx. Newer versions of libvirt and QEMU will probably switch over to defaulting

The previous code treated floppy disks and CD-ROMs as the same kind of thing, resulting in malformed libvirt XML. You would see the following error when importing a guest into libvirt: error: Failed to define domain from /tmp/v2vlibvirt063486.xml error: internal error: Invalid floppy device name: hdb because we incorrectly generated this bogus libvirt XML fragment: <disk

Support also a "socket" listen type with no explicitly specified socket (which will be generated by libvirt). Updates commit a4adf48915c0e3e7f4e8b7bbdbb5ac622da1ac58. Related to: RHBZ#1378022 --- v2v/create_libvirt_xml.ml | 4 +++- v2v/parse_libvirt_xml.ml | 4 ++-- v2v/types.ml | 5 +++-- v2v/types.mli | 2 +- 4 files changed, 9 insertions(+), 6 deletions(-)

Since libvirt 2.0.0, these two new <listen/> types have been supported: https://libvirt.org/formatdomain.html#elementsGraphics This change just copies that configuration over from the source to the destination if the destination is also libvirt. Since we previously used 'LNone' to mean "no parseable <listen/> element" I also had to change previous uses of

Implement what old virt-v2v did (from lib/Sys/VirtConvert/Connection/LibVirtTarget.pm) Thanks: Tingting Zheng, Matthew Booth --- v2v/output_libvirt.ml | 118 ++++++++++++++++++++++++++++++++++++++++++++++--- v2v/output_libvirt.mli | 2 +- v2v/output_local.ml | 13 +++++- v2v/test-v2v-i-ova.xml | 5 ++- 4 files changed, 128 insertions(+), 10 deletions(-) diff --git