search for: i_windows_current_control_set

A very miscellaneous set of cleanups to how we handle the Windows registry in virt-v2v, firstboot, and inspection code. This should all be straightforward non-controversial refactoring. Some highlights: - Add a new mllib Registry module containing various utility functions that are currently scattered all around. - Only compute the software/system hive paths once during inspection, and

This patch is just for discussion. There are still a couple of issues that I'm trying to fix. One is that all of the test guests I have, even ones with static IPs, have multiple interfaces, some using DHCP, so the conditions for adding the Powershell script don't kick in. This makes testing very awkward. However a bigger issue is that I think the premise is wrong. In some registries

v1 was here with much discussion: https://www.redhat.com/archives/libguestfs/2018-December/msg00048.html v2: - Fix the case where there are multiple interfaces. Note this does not preserve order correctly (see patch for comment on why that is a hard problem). - Preserve name servers. This patch is still for discussion only. I'd like to see what might be done to get this upstream

...rivers from. XXX *) + + mutable block_driver_priority : string list + (** List of block drivers *) } type block_type = Virtio_blk | Virtio_SCSI | IDE @@ -107,7 +110,11 @@ and get_inspection g root = { g; root; i_arch; i_major_version; i_minor_version; i_osinfo; i_product_variant; i_windows_current_control_set; i_windows_systemroot; - virtio_win = ""; was_set = false } + virtio_win = ""; was_set = false; + block_driver_priority = ["virtio_blk"; "vrtioblk"; "viostor"] } + +let get_block_driver_priority t = t.block_driver_priority +let set_block_...

...want to get drivers from. XXX *) + + mutable block_driver_priority : string list + (** List of block drivers *) } type block_type = Virtio_blk | IDE @@ -107,7 +110,11 @@ and get_inspection g root = { g; root; i_arch; i_major_version; i_minor_version; i_osinfo; i_product_variant; i_windows_current_control_set; i_windows_systemroot; - virtio_win = ""; was_set = false } + virtio_win = ""; was_set = false; + block_driver_priority = ["virtio_blk"; "vrtioblk"; "viostor"] } + +let get_block_driver_priority t = t.block_driver_priority +let set_block_...

Discussion on v1 https://listman.redhat.com/archives/libguestfs/2023-February/030849.html https://listman.redhat.com/archives/libguestfs/2023-March/030917.html v1 -> v2: * Drop the logic where default is switched to "vioscsi". Keep virtio-blk as default. * Adapt the patch suggested by Richard: https://listman.redhat.com/archives/libguestfs/2023-March/030974.html This

Discussion on v2: https://listman.redhat.com/archives/libguestfs/2023-March/030989.html v2 -> v3: * Patch 1/4 ("inject_virtio_win: match only vendor/device/revision"): do not omit PCI Revision ID. Adjust commit message accordingly; * Patch 2/4 ("inject_virtio_win: add Virtio_SCSI to block_type"): add non-empty commit message body. * Patch 4/4

...s-systemroot", JSON.String inspect.i_windows_systemroot; + "windows-software-hive", JSON.String inspect.i_windows_software_hive; + "windows-system-hive", JSON.String inspect.i_windows_system_hive; + "windows-current-control-set", JSON.String inspect.i_windows_current_control_set; + "firmware", JSON.Dict firmware_dict; + ] in + List.push_back doc ("inspect", JSON.Dict inspect_dict); + + !doc diff --git a/v2v/create_json.mli b/v2v/create_json.mli new file mode 100644 index 000000000..6dbb6e48b --- /dev/null +++ b/v2v/create_json.mli @@ -0,0 +1,2...

...s-systemroot", JSON.String inspect.i_windows_systemroot; + "windows-software-hive", JSON.String inspect.i_windows_software_hive; + "windows-system-hive", JSON.String inspect.i_windows_system_hive; + "windows-current-control-set", JSON.String inspect.i_windows_current_control_set; + "firmware", JSON.Dict firmware_dict; + ] in + List.push_back doc ("inspect", JSON.Dict inspect_dict); + + !doc diff --git a/v2v/create_json.mli b/v2v/create_json.mli new file mode 100644 index 000000000..6dbb6e48b --- /dev/null +++ b/v2v/create_json.mli @@ -0,0 +1,2...

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