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

[Daniel P. Berrangé]

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