Libguestfs - Mar 2020 - Re: [PATCH 1/1] windows: delay installation of qemu-ga MSI

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
s/virit/virt/
> Windows enforces some kind of internal reboot. This unfortunately
> terminates any running firstboot scritps thus killing the installation
s/scritpts/scripts/
> of qemu-ga MSI.
IIUC, the expectation is that the Windows installation of the
drivers will be completed *before* this 2 minute delay occurs.
Windows will then reboot, and the delayed GA job will be run
after this reboot ?

The key question is how confident are we that the 2 minute
delay is sufficient ?  Is there chance of still hitting the
problem if doing v2v on slow (ie HDD, not SSD) storage
for example ?
> 
> Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
> ---
>  v2v/convert_windows.ml | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
> index 0fda1d4e..0a146006 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(119);
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;
> -- 
> 2.25.0
> 
> 
> _______________________________________________
> Libguestfs mailing list
> Libguestfs@redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs
Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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 scheduled with
precision in seconds. So when scheduling in 00:00:00 it will be set to
00:01:00. But now that I look at it it should be 120 and not 119. That
way it will always be 2 minutes. I am not sure what math error did I do
when I wrote it originaly.

> > During the first boot, after virt-v2v conversion, Windows installs the
> > drivers injected by virit-v2v. When this installation is finished
> 
> s/virit/virt/
> 
> > Windows enforces some kind of internal reboot. This unfortunately
> > terminates any running firstboot scritps thus killing the installation
> 
> s/scritpts/scripts/
> 
Thanks for spotting the typos.
> > of qemu-ga MSI.
> 
> IIUC, the expectation is that the Windows installation of the
> drivers will be completed *before* this 2 minute delay occurs.
> Windows will then reboot, and the delayed GA job will be run
> after this reboot ?
Correct.
> 
> The key question is how confident are we that the 2 minute
> delay is sufficient ?  Is there chance of still hitting the
> problem if doing v2v on slow (ie HDD, not SSD) storage
> for example ?
This is a best effort. What you're describing can happen and the user
will be screwed. But bear in mind that as it is now it is virtualy never
working. You cannot set the delay too long either. If the user starts
doing something once the VM boots you don't want to restart the VM (once
MSI is installed) under the user's hands.

I am currently investigating how could we use PowerShell features to
introduce some waiting mechanism (e.g. for the serial device) to handle
this better. But that will take some time.

    Tomas
> 
> > 
> > Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
> > ---
> >  v2v/convert_windows.ml | 12 ++++--------
> >  1 file changed, 4 insertions(+), 8 deletions(-)
> > 
> > diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
> > index 0fda1d4e..0a146006 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(119);
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;
> > -- 
> > 2.25.0
> > 
> > 
> > _______________________________________________
> > Libguestfs mailing list
> > Libguestfs@redhat.com
> > https://www.redhat.com/mailman/listinfo/libguestfs
> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange
:|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com
:|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange
:|
> 
-- 
Tomáš Golembiovský <tgolembi@redhat.com>

On Tue, Mar 03, 2020 at 02:27:46PM +0100, Tomáš Golembiovský
wrote:
> 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 scheduled with
> precision in seconds. So when scheduling in 00:00:00 it will be set to
> 00:01:00. But now that I look at it it should be 120 and not 119. That
> way it will always be 2 minutes. I am not sure what math error did I do
> when I wrote it originaly.
> 
> 
> > > During the first boot, after virt-v2v conversion, Windows
installs the
> > > drivers injected by virit-v2v. When this installation is finished
> > 
> > s/virit/virt/
> > 
> > > Windows enforces some kind of internal reboot. This unfortunately
> > > terminates any running firstboot scritps thus killing the
installation
> > 
> > s/scritpts/scripts/
> > 
> 
> Thanks for spotting the typos.
> 
> > > of qemu-ga MSI.
> > 
> > IIUC, the expectation is that the Windows installation of the
> > drivers will be completed *before* this 2 minute delay occurs.
> > Windows will then reboot, and the delayed GA job will be run
> > after this reboot ?
> 
> Correct.
> 
> > 
> > The key question is how confident are we that the 2 minute
> > delay is sufficient ?  Is there chance of still hitting the
> > problem if doing v2v on slow (ie HDD, not SSD) storage
> > for example ?
> 
> This is a best effort. What you're describing can happen and the user
> will be screwed. But bear in mind that as it is now it is virtualy never
> working. You cannot set the delay too long either. If the user starts
> doing something once the VM boots you don't want to restart the VM
(once
> MSI is installed) under the user's hands.
> 
> I am currently investigating how could we use PowerShell features to
> introduce some waiting mechanism (e.g. for the serial device) to handle
> this better. But that will take some time.
Ok, understood. Can you expand the commit message with some of this
info to make it clear this isn't a real fix, it is just a mitigation
with caveats about possible failure in slow VMs.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|