On Tue, Apr 05, 2016 at 07:53:16PM +0300, Roman Kagan wrote:
On Tue, Apr 05, 2016 at 05:33:28PM +0200, Cedric Bosdonnat wrote:
> On Tue, 2016-04-05 at 17:19 +0300, Roman Kagan wrote:
> > On Tue, Apr 05, 2016 at 01:47:32PM +0200, Cédric Bosdonnat wrote:
> > > Setting the ConfigFlags to 0x40 for those will make windows quiet
> > > at the first boot about those new devices. The wizard must not be
> > > presented to the user since the needed drivers will automatically
> > > be installed at firstboot... or worse, the wizard can even block
> > > the installer.
> >
> > What installer?
>
> At least the VMDP installer running at firstboot is blocked by these
> wizards.
I see. Perhaps this needs to be fixed in that installer, then (no, I
have no idea how or whether it's possible at all)?
> > You're trying circumvent the usual PnP process people are used to.
> > I'm
> > not sure it's worth adding yet more unreliable hacks (yes, basically
> > the
> > whole v2v/windows_virtio.ml is a hack).
>
> Setting those keys forces windows to ignore the virtio net and balloon
> devices for the first boot time. Running the VMDP installer (or the RH
> equivalent one) will install the needed drivers and all will be fine
> after that.
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
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.
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?
Roman.