search for: s_features

...; s_orig_name = name; s_memory = 2048L *^ 1024L *^ 1024L; (* 2048 MB *) s_vcpu = 1; (* 1 vCPU is a safe default *) + s_cpu_vendor = None; + s_cpu_model = None; + s_cpu_sockets = None; + s_cpu_cores = None; + s_cpu_threads = None; s_features = [ "acpi"; "apic"; "pae" ]; s_firmware = UnknownFirmware; (* causes virt-v2v to autodetect *) s_display = diff --git a/v2v/input_ova.ml b/v2v/input_ova.ml index e80ec82..b82862f 100644 --- a/v2v/input_ova.ml +++ b/v2v/input_ova.ml @@ -222,7 +222,8...

..._libvirt_xml ?conn xml = let add_nic vnet = let nic = { s_mac = mac; + s_nic_model = model; s_vnet = vnet; s_vnet_orig = vnet; s_vnet_type = vnet_type @@ -366,6 +397,7 @@ let parse_libvirt_xml ?conn xml = s_features = features; s_firmware = UnknownFirmware; (* XXX until RHBZ#1217444 is fixed *) s_display = display; + s_video = video; s_sound = sound; s_disks = []; s_removables = removables; diff --git a/v2v/input_ova.ml b/v2v/input_ova.ml index c8c6b94..db0588d 100644 --- a/v2v/inpu...

..._libvirt_xml ?conn xml = let add_nic vnet = let nic = { s_mac = mac; + s_nic_model = model; s_vnet = vnet; s_vnet_orig = vnet; s_vnet_type = vnet_type @@ -366,6 +392,7 @@ let parse_libvirt_xml ?conn xml = s_features = features; s_firmware = UnknownFirmware; (* XXX until RHBZ#1217444 is fixed *) s_display = display; + s_video = video; s_sound = sound; s_disks = []; s_removables = removables; diff --git a/v2v/input_ova.ml b/v2v/input_ova.ml index c8c6b94..db0588d 100644 --- a/v2v/inpu...

..._libvirt_xml ?conn xml = let add_nic vnet = let nic = { s_mac = mac; + s_nic_model = model; s_vnet = vnet; s_vnet_orig = vnet; s_vnet_type = vnet_type @@ -366,6 +392,7 @@ let parse_libvirt_xml ?conn xml = s_features = features; s_firmware = UnknownFirmware; (* XXX until RHBZ#1217444 is fixed *) s_display = display; + s_video = video; s_sound = sound; s_disks = []; s_removables = removables; diff --git a/v2v/input_ova.ml b/v2v/input_ova.ml index c8c6b94..db0588d 100644 --- a/v2v/inpu...

...7 @@ class input_disk input_format disk = object s_vcpu = 1; (* 1 vCPU is a safe default *) s_cpu_vendor = None; s_cpu_model = None; - s_cpu_sockets = None; - s_cpu_cores = None; - s_cpu_threads = None; + s_cpu_topology = None; s_features = [ "acpi"; "apic"; "pae" ]; s_firmware = UnknownFirmware; (* causes virt-v2v to autodetect *) s_display = diff --git a/v2v/input_ova.ml b/v2v/input_ova.ml index 4f2480589..a909b92ed 100644 --- a/v2v/input_ova.ml +++ b/v2v/input_ova.ml @@ -245,7 +24...

...; 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

...- e.e_attrs @ [attr] -let create_libvirt_xml ?pool source targets guestcaps = +let create_libvirt_xml ?pool source targets guestcaps target_features = let memory_k = source.s_memory /^ 1024L in + (* We have the machine features of the guest when it was on the + * source hypervisor (source.s_features). We have the acpi flag + * which tells us whether acpi is required by this guest + * (guestcaps.gcaps_acpi). And we have the set of hypervisor + * features supported by the target (target_features). Combine all + * this into a final list of features. + *) + let features = string_set_...

This is tangentially related to: https://bugzilla.redhat.com/show_bug.cgi?id=1372668 The problem in that bug is that we didn't pass the source CPU model (Sandybridge in that case) through to the target RHV hypervisor. So when the Windows guest booted on the target it gives an error about CPU hardware being disconnected (although it otherwise boots and works fine). This patch series

v1 -> v2: - Support for passing topology through -o glance. - Support for passing topology through -o rhv. - Use bool for acpi/apic/pae struct fields in virt-p2v. - Write the xpath expression in error messages instead of file/line. - Fix more memory leaks in virt-p2v cpuid.c. - Passes make check & check-valgrind. There may be some other minor changes. I believe that everything

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

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

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

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

Shahar: This is the same patch as you posted, but I have rebased it on top of current HEAD. You'll have to do save the next email to a file, and do: git reset --hard HEAD^ git pull git am /path/to/saved_email There are no changes in this patch, except what is needed to make it compile. Will follow-up with comments. Rich.

On Thu, Aug 21, 2014 at 01:50:18PM +0100, Richard W.M. Jones wrote: > + (* extract ova (tar) file *) > + let cmd = sprintf ("tar -xf %s -C %s") (ova) (dir) in Lots of extra parentheses here :-) The same command can be written more naturally without any of them: let cmd = sprintf "tar -xf %s -C %s" ova dir in However I think what you might have meant is to call

...ot; uefi_firmware.Uefi.code_debug; + + List.push_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 rem...

...ot; uefi_firmware.Uefi.code_debug; + + List.push_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 rem...

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

https://bugzilla.redhat.com/show_bug.cgi?id=1441197