Re: [Libguestfs] [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards

On Wed, Apr 06, 2016 at 09:16:16AM +0200, Cedric Bosdonnat wrote: > On Tue, 2016-04-05 at 21:08 +0300, Roman Kagan wrote: > > > I'll talk to our guys doing similar things. I wonder what they > > > do > > > -- > > > they must have similar problems. > > > > Indeed they do. The solution we're considering ATM is > > > > 1) make the installer support running on a system where the > > drivers > > are > > already installed > > Our installer is already able to handle this case. > > > 2) make sure firstboot scripts aren't run before PnP is complete > > > > This should resolve the conflict you wrote about, by making the > > drivers > > brought in by v2v fully installed via standard Windows PnP > > manager > > first, and running the installer afterwards. > > I think it can't hurt to get the firstboot script run before PnP... > but > I have no idea how to do that, but may be you have one ;) I meant vice versa: run firstboot strcitly *after* PnP completes (including reboots if necessary). And yes Windows provides a way to wait until it's over: https://msdn.microsoft.com/en-us/library/windows/hardware/ff537916(v= vs.85).aspx I think we'll cook up a patch to rhsrvany to make use of that; as I said this will also benefit other firstboot scripts which then won't be interrupted by reboots caused by PnP driver installation; you should be able to do the same with your tool, too.

> > Item (2) is also useful to avoid similar conflicts with other > > firstboot > > scripts, because PnP often requires a reboot, and those firstboot > > scripts may not tolerate a reboot in the middle of execution. > > > > Will this work for you? > > Sure. If we manage to run the first boot before PnP this hack is no > longer needed. According to your comment to item (1), the other way around (firstboot after PnP) should also be OK, shouldn't it?