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 best-effort mitigation. It can still happen (e.g. with slow disk drives) that the drivers are not yet installed when the delayed installation starts. On the other hand we cannot delay it too much otherwise we risk that the users logs in and will be doing some work when the MSI installation starts. After MSI installation finishes the VM needs to be rebooted which would be annoying if that would happen under users hands. Although this is not a best fix (that may come later as it is more complex, e.g. introducing waiting mechanism), the delay as it is defined works in most cases. And it dramaticaly improves the situations -- originaly I experienced more than 90% failure rate. Signed-off-by: Tomáš Golembiovský <tgolembi(a)redhat.com&gt; --- common | 2 +- v2v/convert_windows.ml | 12 ++++-------- 2 files changed, 5 insertions(+), 9 deletions(-) diff --git a/common b/common index ea10827b..5371257c 160000 --- a/common +++ b/common @@ -1 +1 @@ -Subproject commit ea10827b4cfb3cfe5f782421c01d2902e5f73f90 +Subproject commit 5371257c3cf27fb09d5f2e31ba378b0e6ccf5df6 diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml index 0fda1d4e..bed5989a 100644 --- a/v2v/convert_windows.ml +++ b/v2v/convert_windows.ml @@ -429,14 +429,10 @@ popd List.iter ( fun msi_path -> let fb_script = "\ -echo Installing qemu-ga from " ^ msi_path ^ " -\"\\" ^ msi_path ^ "\" /norestart /qn /l+*vx \"%~dpn0.log\" -set elvl=!errorlevel! -echo Done installing qemu-ga error_level=!elvl! -if !elvl! == 0 ( - echo Restarting Windows... - shutdown /r /f /c \"rebooted by firstboot script\" -) +echo Removing any previously scheduled qemu-ga installation +schtasks.exe /Delete /TN Firstboot-qemu-ga /F +echo Scheduling delayed installation of qemu-ga from " ^ msi_path ^ " +powershell.exe -command \"$d = (get-date).AddSeconds(120); schtasks.exe /Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/yyyy') /RU SYSTEM /TN Firstboot-qemu-ga /TR \\\"C:\\" ^ msi_path ^ " /forcerestart /qn /l+*vx C:\\" ^ msi_path ^ ".log\\\"\" " in Firstboot.add_firstboot_script g inspect.i_root ("install " ^ msi_path) fb_script;

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 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 best-effort mitigation. It can still happen (e.g. with > > slow disk drives) that the drivers are not yet installed when the > > delayed installation starts. On the other hand we cannot delay it too > > much otherwise we risk that the users logs in and will be doing some > > work when the MSI installation starts. After MSI installation finishes > > the VM needs to be rebooted which would be annoying if that would happen > > under users hands. Although this is not a best fix (that may come later > > as it is more complex, e.g. introducing waiting mechanism), the delay as > > it is defined works in most cases. And it dramaticaly improves the > > situations -- originaly I experienced more than 90% failure rate. > > > > Signed-off-by: Tomáš Golembiovský <tgolembi(a)redhat.com&gt; > > --- > > common | 2 +- > > v2v/convert_windows.ml | 12 ++++-------- > > 2 files changed, 5 insertions(+), 9 deletions(-) > > > > diff --git a/common b/common > > index ea10827b..5371257c 160000 > > --- a/common > > +++ b/common > > @@ -1 +1 @@ > > -Subproject commit ea10827b4cfb3cfe5f782421c01d2902e5f73f90 > > +Subproject commit 5371257c3cf27fb09d5f2e31ba378b0e6ccf5df6 > > diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml > > index 0fda1d4e..bed5989a 100644 > > --- a/v2v/convert_windows.ml > > +++ b/v2v/convert_windows.ml > > @@ -429,14 +429,10 @@ popd > > List.iter ( > > fun msi_path -> > > let fb_script = "\ > > -echo Installing qemu-ga from " ^ msi_path ^ " > > -\"\\" ^ msi_path ^ "\" /norestart /qn /l+*vx \"%~dpn0.log\" > > -set elvl=!errorlevel! > > -echo Done installing qemu-ga error_level=!elvl! > > -if !elvl! == 0 ( > > - echo Restarting Windows... > > - shutdown /r /f /c \"rebooted by firstboot script\" > > -) > > +echo Removing any previously scheduled qemu-ga installation > > +schtasks.exe /Delete /TN Firstboot-qemu-ga /F > > +echo Scheduling delayed installation of qemu-ga from " ^ msi_path ^ " > > +powershell.exe -command \"$d = (get-date).AddSeconds(120); schtasks.exe /Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/yyyy') /RU SYSTEM /TN Firstboot-qemu-ga /TR \\\"C:\\" ^ msi_path ^ " /forcerestart /qn /l+*vx C:\\" ^ msi_path ^ ".log\\\"\" > > " in > > Firstboot.add_firstboot_script g inspect.i_root > > ("install " ^ msi_path) fb_script; > > It could be easier to follow if you use sprintf here, something like: > > let fb_script = sprintf "\ > echo Removing any previously scheduled qemu-ga installation > schtasks.exe /Delete /TN Firstboot-qemu-ga /F > echo Scheduling delayed installation of qemu-ga from %s > powershell.exe -command \"$d = (get-date).AddSeconds(120); schtasks.exe /Create /SC ONCE /ST $d.ToString('HH:mm') /SD $d.ToString('MM/dd/yyyy') /RU SYSTEM /TN Firstboot-qemu-ga /TR \\\"C:\\%s /forcerestart /qn /l+*vx C:\\%s.log\\\"\" > msi_path msi_path msi_path in Ok, I can change that. > > The other possible problem is this seems to install a firstboot script > for every element of the list qemu_ga_files. How long is this list? At the moment it is just one. Until something changes in virtio-win ISO or in our internal logic (like in virtio_iso_path_matches_qemu_ga()) it will always be one. > > Do filenames on this list need some kind of quoting? The filenames > don't, but they seem to contain a path that comes from the virtio-win > ISO. Those are really just file names without path. See https://github.com/libguestfs/virt-v2v/blob/master/v2v/windows_virtio.ml#...