similar to: [PATCH 0/8] Miscellaneous cleanups to Windows registry code.

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

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

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

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

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

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

It seems newer versions of VMware Tools for Windows can be uninstalled also when the guest does not run on VMware anymore. Hence, attempt to uninstall them during a conversion, reusing the same code already used to uninstall Parallel Tools. This was tested with the following Windows guests: - Windows 2008r2 - Windows 2012r2 - Windows 2016 - Windows 7 - Windows 8 - Windows 10 Pino Toscano (2):

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

On Tue, Apr 05, 2016 at 01:47:27PM +0200, Cédric Bosdonnat wrote: > + let oem_inf = set_free_oem_inf g root scsi_adapter_guid "viostor.inf" driverdir in Seems better if it was called *get_next*_free_oem_inf? > > (* There should be a key > * HKLM\SYSTEM\ControlSet001\Control\Class\<scsi_adapter_guid> > @@ -398,6 +378,28 @@ and

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

Map the HIVEX_OPEN_UNSAFE flag into the libguestfs API and use it in various places. Rich.

From: "Richard W.M. Jones" <rjones at redhat.com> When injecting virtio-win drivers, allow the list of block drivers that we search to be modified. This functionality will be used when we introduce an option for changing the default block driver in virt-v2v. Originally-by: Richard W.M. Jones <rjones at redhat.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at

When injecting virtio-win drivers, allow the list of block drivers that we search to be modified. --- mlcustomize/inject_virtio_win.ml | 12 +++++++++--- mlcustomize/inject_virtio_win.mli | 10 ++++++++++ 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/mlcustomize/inject_virtio_win.ml b/mlcustomize/inject_virtio_win.ml index 4e977b3..2a7c742 100644 ---

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

On Wed, Aug 17, 2016 at 08:59:43PM +0300, Roman Kagan wrote: > It will be used in new code in a followup patch. > > Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> > --- > v2v/convert_windows.ml | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml > index 55bb3ef..751a6ab

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

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

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook <keescook at chromium.org> --- drivers/gpu/drm/nouveau/nouveau_ttm.c | 28 ++++++++++++++-------------- 1 file changed,