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