6:27 a.m.
----- "Matthew Booth" <mbooth(a)redhat.com> wrote:
One of the things we would really like to be able to do for V2V is
to
install a new driver in a Windows guest. There are a couple of reasons
for this:
* The guest may not be bootable without the driver installed, for
example because the underlying virtual hardware has changed from
vmscsi
to virtio.
* If the guest can boot, the alternative is to modify the guest to run
a
script on next boot. This requires making assumptions about supporting
software being installed and working correctly on the guest. Certain
environments, particularly heavily locked-down environments, make this
an unsafe assumption.
The Windows PE environment looks perfect for this task. It gives you a
very lightweight Windows OS which can be customised with additional
tools. It is specifically for doing installations. I spent Friday
trying
to use it to install a driver in a guest. Here's what I tried and why
it
didn't work.
Installing a driver in Windows is 'driven' by a .inf file. From my
(admittedly limited) understanding, this broadly describes:
* The files which need to be installed
* The hardware the driver is compatible with
The files, including the .inf file itself must be copied in to the
correct places. In addition, information from the .inf file must be
written to the registry. It is this last part which causes problems.
From reading documentation, it appears that a driver would normally
be
installed using the SetupCopyOEMInf() library call. I wrote a simple
wrapper round this and installed it in the Windows PE image, along
with
the VirtIO drivers. I booted into Windows PE and attempted to install
the driver. As you might expect, the drivers were installed into the
Windows PE image rather than the guest. I then tried setting
%systemdrive% and %systemroot% to the guest image. This appears to
have
no effect. This is what makes me suspect that the process is primarily
registry driven.
I started looking around for ways of using a different registry. I
discovered the Registry Editor PE plugin to BartPE
(https://sourceforge.net/projects/regeditpe/) which allows editing the
registry of a guest. Looking at how it does this, it uses reg.exe to
load the guests's hives. I confirmed that you can do this.
Unfortunately
you don't seem to be able to replace the default hives. The new hives
are loaded in a different part of the tree, and are therefore
ignored.
This is NOT doable. The registry holds too many configurations imperative
for the proper behaviour of the OS (in this case the WinPE hive). If this is at all
possible (I doubt it, too many open handles and things that require booting to change as
it is) Changing this would render the system unstable (if not BSOD you entirely if you
could get so far).
Now that I understand what you are trying to do (and I don't mean to discourage) but I
believe you are going about this the wrong way. A direct install of the driver probably
does even more things which you are not aware of and are hardwired to the system drive
(not through %SYSTEMDIR% and any other environment variable).
Just an example, Changing system environment variables require booting the machine
(http://technet.microsoft.com/en-us/library/bb726962.aspx) this is the relevant excerpt:
Note: When you create or modify system environment variables, the changes take effect when
you restart the computer. When you create or modify user environment variables, the
changes take effect the next time the user logs on to the system.
In addition, if the device driver is installed under the "system" user's
credentials then: you have to boot the machine after you change the environment variables
(because they are loaded only once at boot and cannot be refreshed) and changing the
systemdir for the entire machine and rebooting is probably not recommended.
In any event, in order to reverse engineer what is going on when the driver is installed
you can probably use some "recording" applications (apps which install filter
device drivers which monitor the registry and the hard drive, record changes and filter
out known things which are irrelevant).
The next phase would be to inject the relevant files directly where they should be and
make the relevant registry changes (for instance by loading the Hives as you did and
running a script that changes the relevant entries).
The other possibility is as I mentioned before offline tools which already know how to do
this (e.g. http://technet.microsoft.com/en-us/library/cc749465%28WS.10%29.aspx).
This is as far as I've got. Still on my list are:
* Ask on various Windows mailing lists how to do this
* Investigate if the packaged .msi containing the drivers is more
flexible.
* Look for other, possibly lower level, ways of replacing making a
process use a different registry.
Any and all suggestions are gratefully received,
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490