5:25 a.m.
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: delay installation of qemu-ga MSI
v2v/convert_windows.ml | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
--
2.25.0
5:26 a.m.
New subject: [PATCH 1/1] windows: delay installation of qemu-ga MSI
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: Tomáš Golembiovský <tgolembi(a)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
5:35 a.m.
New subject: [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(a)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(a)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 :|
7:27 a.m.
New subject: [PATCH 1/1] windows: delay installation of qemu-ga MSI
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(a)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(a)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(a)redhat.com>
7:37 a.m.
New subject: [PATCH 1/1] windows: delay installation of qemu-ga MSI
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 :|
8:46 a.m.
New subject: [PATCH 1/1] windows: delay installation of qemu-ga MSI
On Tue, Mar 03, 2020 at 01:37:24PM +0000, Daniel P. Berrangé wrote:
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.
Updated in v3. Let me know if you think I omitted something.
Tomas
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(a)redhat.com>
1755
days inactive
1756
days old
5 comments
2 participants
participants (2)
-
Daniel P. Berrangé -
Tomáš Golembiovský