Re: [Libguestfs] [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 :|