search for: gcaps_machine

...gcaps_block_bus = block_type; @@ -130,6 +149,7 @@ let convert (g : G.guestfs) inspect source output rcaps = gcaps_virtio_rng = kernel.ki_supports_virtio_rng; gcaps_virtio_balloon = kernel.ki_supports_virtio_balloon; gcaps_isa_pvpanic = kernel.ki_supports_isa_pvpanic; + gcaps_machine = machine; gcaps_arch = Utils.kvm_arch inspect.i_arch; gcaps_acpi = acpi; } in diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml index 163319545..97882c377 100644 --- a/v2v/convert_windows.ml +++ b/v2v/convert_windows.ml @@ -212,6 +212,15 @@ let convert (g : G.guestfs)...

...gcaps_block_bus = block_type; @@ -130,6 +136,7 @@ let convert (g : G.guestfs) inspect source output rcaps = gcaps_virtio_rng = kernel.ki_supports_virtio_rng; gcaps_virtio_balloon = kernel.ki_supports_virtio_balloon; gcaps_isa_pvpanic = kernel.ki_supports_isa_pvpanic; + gcaps_machine = machine; gcaps_arch = Utils.kvm_arch inspect.i_arch; gcaps_acpi = acpi; } in diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml index 163319545..1e058136e 100644 --- a/v2v/convert_windows.ml +++ b/v2v/convert_windows.ml @@ -212,6 +212,12 @@ let convert (g : G.guestfs)...

...ck_type; > @@ -130,6 +149,7 @@ let convert (g : G.guestfs) inspect source output rcaps = > gcaps_virtio_rng = kernel.ki_supports_virtio_rng; > gcaps_virtio_balloon = kernel.ki_supports_virtio_balloon; > gcaps_isa_pvpanic = kernel.ki_supports_isa_pvpanic; > + gcaps_machine = machine; > gcaps_arch = Utils.kvm_arch inspect.i_arch; > gcaps_acpi = acpi; > } in > diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml > index 163319545..97882c377 100644 > --- a/v2v/convert_windows.ml > +++ b/v2v/convert_windows.ml > @@ -212,...

Version 1 was here: https://listman.redhat.com/archives/libguestfs/2023-February/thread.html#30694 I made a few changes in v2 but overall decided to keep the now unused gcaps_arch_min_version capability. This doesn't preclude removing it in future if we think it's never going to be useful. I changed patch 1 so that to remove the long comment about how the field is used, anticipating the

...what > machine types are available. One issue is we don't always have access to the target hypervisor. For example in the Glance case we have to write something which will be picked up by Nova much later: > > + "hw_machine_type", > > + (match guestcaps.gcaps_machine with > > + | I440FX -> "pc" > > + | Q35 -> "q35" > > + | Virt -> "virt"); I read the Nova code and it seems very ad-hoc. As far as I can tell these strings are eventually passed down to libvirt. However libvirt capa...

...> > One issue is we don't always have access to the target hypervisor. > > For example in the Glance case we have to write something which will > be picked up by Nova much later: > > > > + "hw_machine_type", > > > + (match guestcaps.gcaps_machine with > > > + | I440FX -> "pc" > > > + | Q35 -> "q35" > > > + | Virt -> "virt"); > > I read the Nova code and it seems very ad-hoc. As far as I can tell > these strings are eventually passed down to...

..._back fw ("uefi", JSON.Dict !uefi) + ); + + !fw in + List.push_back doc ("firmware", JSON.Dict firmware); + + List.push_back doc ("features", + JSON.List (json_list_of_string_list source.s_features)); + + let machine = + match guestcaps.gcaps_machine with + | I440FX -> "pc" + | Q35 -> "q35" + | Virt -> "virt" in + List.push_back doc ("machine", JSON.String machine); + + let disks, removables = + let disks = ref [] + and removables = ref [] in + + let iter_bus bus_name drive_pr...

..._back fw ("uefi", JSON.Dict !uefi) + ); + + !fw in + List.push_back doc ("firmware", JSON.Dict firmware); + + List.push_back doc ("features", + JSON.List (json_list_of_string_list source.s_features)); + + let machine = + match guestcaps.gcaps_machine with + | I440FX -> "pc" + | Q35 -> "q35" + | Virt -> "virt" in + List.push_back doc ("machine", JSON.String machine); + + let disks, removables = + let disks = ref [] + and removables = ref [] in + + let iter_bus bus_name drive_pr...

This patch implements output to OpenStack Cinder volumes using OpenStack APIs. It has only been lightly tested, but appears to work. There are some important things to understand about how this works: (1) You must run virt-v2v in a conversion appliance running on top of OpenStack. And you must supply the name or UUID of this appliance to virt-v2v using the ‘-oo server-id=NAME|UUID’ parameter.

v1 was here: https://www.redhat.com/archives/libguestfs/2018-August/thread.html#00287 v2: - The -oa option now gives an error; apparently Cinder cannot generally control sparse/preallocated behaviour, although certain Cinder backends can. - The -os option maps to Cinder volume type; suggested by Matt Booth. - Add a simple test.

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with