similar to: [PATCH v2] windows: delay installation of qemu-ga MSI

On Tue, Mar 03, 2020 at 03:45:49PM +0100, Tomáš Golembiovský wrote: > Instead of running firstboot script during early boot schedule a task > delayed for 2 minutes. > > During the first boot, after virt-v2v conversion, Windows installs the > drivers injected by virt-v2v. When this installation is finished > Windows enforces some kind of internal reboot. This unfortunately >

On Thu, Mar 05, 2020 at 08:49:04AM +0000, Richard W.M. Jones wrote: > On Tue, Mar 03, 2020 at 03:45:49PM +0100, Tomáš Golembiovský wrote: > > Instead of running firstboot script during early boot schedule a task > > delayed for 2 minutes. > > > > During the first boot, after virt-v2v conversion, Windows installs the > > drivers injected by virt-v2v. When this

Instead of running firstboot script during early boot schedule a task delayed for 2 minutes. During the first boot, after virt-v2v conversion, Windows installs the drivers injected by virt-v2v. When this installation is finished Windows enforces some kind of internal reboot. This unfortunately terminates any running firstboot scripts thus killing the installation of qemu-ga MSI. This is just a

Instead of running firstboot script during early boot schedule a task delayed for 2 minutes. During the first boot, after virt-v2v conversion, Windows installs the drivers injected by virt-v2v. When this installation is finished Windows enforces some kind of internal reboot. This unfortunately terminates any running firstboot scripts thus killing the installation of qemu-ga MSI. This is just a

On Thu, Mar 05, 2020 at 03:37:13PM +0100, Tomáš Golembiovský wrote: > Instead of running firstboot script during early boot schedule a task > delayed for 2 minutes. > > During the first boot, after virt-v2v conversion, Windows installs the > drivers injected by virt-v2v. When this installation is finished > Windows enforces some kind of internal reboot. This unfortunately >

Instead of running firstboot script during early boot schedule a task delayed for 1-2 minute. During the first boot, after virt-v2v conversion, Windows installs the drivers injected by virit-v2v. When this installation is finished Windows enforces some kind of internal reboot. This unfortunately terminates any running firstboot scritps thus killing the installation of qemu-ga MSI. Signed-off-by:

On Mon, Mar 02, 2020 at 11:35:29AM +0000, Daniel P. Berrangé wrote: > On Mon, Mar 02, 2020 at 12:26:00PM +0100, Tomáš Golembiovský wrote: > > Instead of running firstboot script during early boot schedule a task > > delayed for 1-2 minute. > > IIUC, you picked 119 seconds, so effectively 2 minutes. IOW, s/1-2/2/ > Well, the time is rounded down to minutes. It cannot be

On Mon, Mar 02, 2020 at 12:26:00PM +0100, Tomáš Golembiovský wrote: > Instead of running firstboot script during early boot schedule a task > delayed for 1-2 minute. IIUC, you picked 119 seconds, so effectively 2 minutes. IOW, s/1-2/2/ > During the first boot, after virt-v2v conversion, Windows installs the > drivers injected by virit-v2v. When this installation is finished

- match log file with script name - restart manually only after successfull install, this also helps debugging because we can log the installer return code Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- v2v/convert_windows.ml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml index 5b7a5bfe..0fda1d4e

> > diff --git a/common b/common > > index ea10827b..5371257c 160000 > > --- a/common > > +++ b/common > > @@ -1 +1 @@ > > -Subproject commit ea10827b4cfb3cfe5f782421c01d2902e5f73f90 > > +Subproject commit 5371257c3cf27fb09d5f2e31ba378b0e6ccf5df6 > > I think(?) this hunk was not intended? > Yes, that's a mistake. Sorry for that. Tomas

Use firstboot script to install MSI with QEMU-GA from virtio-win ISO or oVirt/RHV guest tools ISO. Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- v2v/convert_windows.ml | 19 +++++++++++++++++++ v2v/windows_virtio.ml | 27 +++++++++++++++++++++++++++ v2v/windows_virtio.mli | 4 ++++ 3 files changed, 50 insertions(+) diff --git a/v2v/convert_windows.ml

This is a replacement for previously posted patch "Delay firstboot scripts to some later time": https://www.redhat.com/archives/libguestfs/2019-November/msg00134.html Instead of delaying all the firstboot scripts we just delay the QEMU-GA installation that we know is problematic. I will possibly send a similar patch for RHEV-APT installation later. Tom?? Golembiovsk? (1): windows:

This, together with the changes to common repo are fixes to the installation qemu-ga MSI. There is still an issue that I did not figure yet how to fix. On Windows 10 it fails to register the QEMU-GA service. Tomáš Golembiovský (2): windows: fix detection of qemu-ga installer on RHV windows: small tweaks of qemu-ga firstboot script v2v/convert_windows.ml | 8 +++++++- v2v/windows_virtio.ml

This, together with the changes to common repo are fixes to the installation qemu-ga MSI. There is still an issue that I did not figure yet how to fix. On Windows 10 it fails to register the QEMU-GA service. Tomáš Golembiovský (2): windows: fix detection of qemu-ga installer on RHV windows: small tweaks of qemu-ga firstboot script v2v/convert_windows.ml | 8 +++++++- v2v/windows_virtio.ml

Instead of doing all firstboot actions in a single script, take the advantage of the firstboot infrastructure and store and run unrelated actions as individual steps. This facilitates troubleshooting and fault recovery; besides it makes adding more actions easier. Signed-off-by: Roman Kagan <rkagan@parallels.com> --- v2v/convert_windows.ml | 31 ++++++++++++++++--------------- 1 file

To add this support, two things are needed: * make the existing code searches for either the viostor or the SUSE VMDP (Virtual Machine Driver Pack) files. * add a firstboot script setting up VMDP. Note that 2 firstboot scripts are intentionally added for the VMDP setup. This is due to windows potentially rebooting after loading the virtio block driver. It may happen that this reboot

It looks like VMware Tools support their unattended uninstallation even after the guest is not running anymore on VMware. --- v2v/convert_windows.ml | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml index 8740afd1c..2d2b6adfe 100644 --- a/v2v/convert_windows.ml +++ b/v2v/convert_windows.ml @@ -192,6

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

During conversion we copy the necessary drivers to the directory "%systemroot%\Drivers\Virtio", adding it to the DevicePath registry value. As documented in [1], this should be enough for Windows to find device drivers and successfully install them. However, it doesn't always happen. Commit 73e009c04 ("v2v: windows: Document use of pnputil to install drivers.") describes

During conversion we copy the necessary drivers to the directory "%systemroot%\Drivers\Virtio", adding it to the DevicePath registry value. As documented in [1], this should be enough for Windows to find device drivers and successfully install them. However, it doesn't always happen. Commit 73e009c04 ("v2v: windows: Document use of pnputil to install drivers.") describes