Re: [Libguestfs] [PATCH 6/7] v2v: quiet virtio net and balloon devices wizards
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.
> > @@ -196,6 +196,14 @@ and
add_viostor_to_critical_device_database g
> > root current_cs major =
> > [ "0", REG_SZ (sprintf
> >
"PCI\\VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00\\%s&20" subkey);
> > "Count", REG_DWORD 0x1_l;
> > "NextInstance", REG_DWORD 0x1_l ];
> > +
> > + [ current_cs; "Enum"; "PCI";
> > "VEN_1AF4&DEV_1000&SUBSYS_00011AF4&REV_00"; subkey ^
"&18" ],
> > + [ "ConfigFlags", REG_DWORD 0x40_l ];
> > + [ current_cs; "Enum"; "PCI";
> > "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00"; subkey ^
"&20" ],
> > + [ "ConfigFlags", REG_DWORD 0x0_l;
> > + "Service", REG_SZ driver_name ];
> > + [ current_cs; "Enum"; "PCI";
> > "VEN_1AF4&DEV_1002&SUBSYS_00051AF4&REV_00"; subkey ^
"&28" ],
> > + [ "ConfigFlags", REG_DWORD 0x40_l ];
>
> I'm curious how reliable those keys are; what are the chances that
> the
> devices get assigned different instance ids? I couldn't find any
> sources indicating that those instance ids are assigned in any
> predictable manner.
I have no idea how they are computed, but they are common accross all
windows versions except for the subkey that changes with windows
versions.
OK I just added another network adapter, and it got &38 at the end. So
this doesn't look like a reliable procedure, and you need to figure out
a better approach.
Roman.