similar to: Re: [PATCH 1/2] v2v:windows: factor out getting CurrentControlSet

On Thu, Sep 01, 2016 at 11:50:18AM +0300, Roman Kagan wrote: > It will be used in new code in a followup patch. > > Signed-off-by: Roman Kagan <rkagan at virtuozzo.com> > --- > v1 -> v2: > - revert debug -> printf regression > > v2v/convert_windows.ml | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git

Wait for driver installations fired by the PnP manager to complete before running firstboot scripts. The first patch is a minor refactoring to pave the way for the second patch. The latter contains the bulk of the changes as well as the description of the idea. Roman Kagan (2): v2v:windows: factor out getting CurrentControlSet v2v:windows: prevent conflicts with PnP on firstboot --- v1

Parallels proprietary hypervisor uses RDPMC as the hypercall instruction. As this instruction is supported since early P6 family, the drivers didn't even bother to check for the presence of the corresponding feature in CPUID. In QEMU/KVM, however, this instruction triggers #GP unless the VM is run with PMU (performance monitoring unit) enabled, which is often not the case (due to its impact

On Wed, Aug 17, 2016 at 08:59:44PM +0300, Roman Kagan wrote: > When put on new virtual hardware Windows will start driver installation > for newly discovered devices. > > The problem is that it happens asynchronously and concurrently with > other activities, in particular, the firstboot scripts. This may result > in conflicts (because a firstboot script may want to install or

SUSE VMDP comes with a replacement for rhsrvany.exe named pvvxsvc.exe. Check for either one of them instead of only rhsrvany. --- builder/virt-builder.pod | 13 +++- customize/firstboot.ml | 169 +++++++++++++++++++++++-------------------- customize/virt-customize.pod | 6 ++ sysprep/virt-sysprep.pod | 6 ++ v2v/virt-v2v.pod | 6 ++ 5 files changed, 117

[Partly using the mailing list as a backup again ...] This commit changes virt-v2v to make registry changes to all ControlSets, not just the CurrentControlSet. Not sure what difference if any this would make. Rich.

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

On Thu, Sep 01, 2016 at 11:50:19AM +0300, Roman Kagan wrote: > When put on new virtual hardware Windows will start driver installation > for newly discovered devices. > > The problem is that it happens asynchronously and concurrently with > other activities, in particular, the firstboot scripts. This may result > in conflicts (because a firstboot script may want to install or

If a Windows boot fails and the user boots the last known good configuration, ControlSet001 will be marked as failed and no longer used. However, virt-v2v would only install viostor to ControlSet001, meaning it will fail to boot this guest after conversion. This patch looks up the current controlset and always installs registry keys to the correct one. Fixes RHBZ#644254 ---

Don't remove the Processor and Intelppm nodes since that just breaks the device driver. The only remaining node being removed by the original code was "rhelscsi" (the xenpv-win driver). I changed this so that instead of deleting the whole node, it simply disables that driver. If you look at RHBZ#737600, it's not even clear that deleting nodes was the right fix for anything. I

This adds most of the hivex APIs directly to the libguestfs API, so that you can read and write Windows Registry hive files from libguestfs without needing to download and upload hive files from the guest. This is analogous to how Augeas APIs are exposed already (guestfs_aug_*) Also, inspection is now done using the new APIs, which fixes the following bug:

Hi there, SUSE ships Virtual Machine Driver Pack for the virtio windows drivers. Get v2v and customize to discover them and use them if available. Cédric Bosdonnat (7): v2v: check next free oem%d.inf in /Windows/Inf v2v: extract controller offset discovery as a function customize: add support for pvvxsvc v2v: extract reusable parts of viostor regedits v2v: adapt the subkey in Enum

If present, Parallels Tools may stand in the way of proper running the windows guests in non-Parallels hypervisors, so we're better off uninstalling them on the first boot into the new environment. With this patch, the uninstall records for Parallels Tools are looked up in the registry and, if found, corresponding firstboot actions are registered, taking special care that those actions are

Add a common debug function for printing debugging messages. It only emits the debug message when the verbose (-v) flag is used on the command line. It sends the output to stderr, which is flushed immediately after the message is printed (to help with debugging unexpected crashes). There are good arguments for sending the debug to either stdout or stderr, and almost all existing debug messages

Add a Common_utils.debug function for printing messages only when in verbose mode. Rich.

This allows users to see stop errors, so we can get an accurate report when things go wrong. --- v2v/convert_windows.ml | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml index e37c6b8..c8db860 100644 --- a/v2v/convert_windows.ml +++ b/v2v/convert_windows.ml @@ -191,6 +191,7 @@ echo uninstalling Xen PV driver if verbose then

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

The way we patch the Windows registry in order to allow it to boot off a virtio-blk drive was initially conceived by comparing the state with virtio-blk driver properly installed, to that without. However, we don't want to replicate the Windows PnP system; rather we need to apply just enough edits to make the system boot, and then let the Windows PnP manager figure out the rest. This series

Now that all the stuff related to Windows virtio drivers has been moved into a dedicated module, it makes sense to move the definition of virtio_win there, too, and stop passing it around as a parameter. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/convert_windows.ml | 9 +-------- v2v/windows_virtio.ml | 13 ++++++++++--- v2v/windows_virtio.mli | 2 +- 3 files changed, 12