search for: s_cpu_topolog

...8,8 +48,7 @@ let create_libvirt_xml ?pool source target_buses guestcaps ]; if source.s_cpu_vendor <> None || source.s_cpu_model <> None || - source.s_cpu_sockets <> None || source.s_cpu_cores <> None || - source.s_cpu_threads <> None then ( + source.s_cpu_topology <> None then ( let cpu = ref [] in (match source.s_cpu_vendor with @@ -62,22 +61,15 @@ let create_libvirt_xml ?pool source target_buses guestcaps | Some model -> List.push_back cpu (e "model" ["fallback", "allow"] [PCData model])...

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

...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 ?pool source target_buses guestcaps source.s_cpu_topology <> None then ( let cpu = ref [] in - (match source.s_cpu_vendor with - | None -> () - | Some vendor -> - List.push_back cpu (e "vendor" [] [PCData vendor]) - ); - (match source.s_cpu_model with - | None -> () - | Some model -> +...

...-> UEFI + | None | Some _ -> UnknownFirmware in + (* Check for hostdev devices. (RHBZ#1472719) *) let () = let obj = Xml.xpath_eval_expression xpathctx "/domain/devices/hostdev" in @@ -502,7 +509,7 @@ let parse_libvirt_xml ?conn xml = s_cpu_model = cpu_model; s_cpu_topology = cpu_topology; s_features = features; - s_firmware = UnknownFirmware; (* XXX until RHBZ#1217444 is fixed *) + s_firmware = firmware; s_display = display; s_video = video; s_sound = sound; -- 2.20.1

...t;-cpu" (Option.default "host" source.s_cpu_model); (Ah yes, we have our own Option module from common/mlstdutils/std_utils.ml*, not the "standard" one <https://v2.ocaml.org/api/Option.html>.) > > if source.s_vcpu > 1 then ( > (match source.s_cpu_topology with Reviewed-by: Laszlo Ersek <lersek at redhat.com>

..."vcpu", JSON.Int (Int64.of_int source.s_vcpu); + ] in + + (match source.s_genid with + | None -> () + | Some genid -> List.push_back doc ("genid", JSON.String genid) + ); + + if source.s_cpu_vendor <> None || source.s_cpu_model <> None || + source.s_cpu_topology <> None then ( + let cpu = ref [] in + + push_optional_string cpu "vendor" source.s_cpu_vendor; + push_optional_string cpu "model" source.s_cpu_model; + (match source.s_cpu_topology with + | None -> () + | Some { s_cpu_sockets; s_cpu_cores; s_cpu_th...

..."vcpu", JSON.Int (Int64.of_int source.s_vcpu); + ] in + + (match source.s_genid with + | None -> () + | Some genid -> List.push_back doc ("genid", JSON.String genid) + ); + + if source.s_cpu_vendor <> None || source.s_cpu_model <> None || + source.s_cpu_topology <> None then ( + let cpu = ref [] in + + push_optional_string cpu "vendor" source.s_cpu_vendor; + push_optional_string cpu "model" source.s_cpu_model; + (match source.s_cpu_topology with + | None -> () + | Some { s_cpu_sockets; s_cpu_cores; s_cpu_th...

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