Re: [Libguestfs] Fwd: [PATCH] v2v: virtio-win: include *.dll too
On Wed, 2015-10-28 at 14:53 +0300, Roman Kagan wrote:
On Wed, Oct 28, 2015 at 12:10:19PM +1100, Vadim Rozenfeld wrote:
> > > > To sum up, the packaging and naming policy of the virtio-win rpm and
the
> > > > virtio-win iso therein are different and neither is clear.
Hardcoding
> > > > the policy in v2v without actually knowing it appears risky at best.
>
> It's due to historical reasons mostly. The best way would be having a set of
separate
> distribution images packaged on per-platform base.
Let me try to get the libguestfs requirements straight:
given a set of Windows drivers, it should be able to identify the ones
appropriate for the particular Windows flavor, in order to
1) tell which devices can be configured
Not sure that I fully understated your
question. but if you are going to
create some sort of off-line automatic virtio-win drivers update
utility, then it shouldn't be too complicated. Firs of all you will need
to obtain the Windows kernel version by reading the following Registry
key - "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion". Let's say it
6.3, which means that it is Win8.1 or WS2012R2, parsing "BuildLabEx"
string from the same hive will give you information about the platform
bitness. Next you need to go through inf files, and find "DriverVer"
string, like this one . taken from from vioscsi.inf
DriverVer=08/01/2015,62.72.104.10800
This string contains build time and version stamps. The version stamp
looks as follow "62.72.104.10800"
where 62 means a target Windows kernel version multiplied by 10. In this
case it is 6.2 which means Win8 or WS2012
72 - the target host platform version multiplied bu 10 (was RHEL7.2)
104 just a magic number, but it can be changed, don't make any
assumption based on this number.
10800 our internal build number (build 108) multiplied by 100
If you found an inf file with the matching minor OS (6 in our case)
version and matching or less but close minor version number (2 vs 3)
then you are in the right directory.
2) offline-"install" the storage driver and thus enable the guest too
boot
This is not so easy. You can do the same thing that Rich does for v2v an
it should work fine. But in some cases, when a guest already has at
least one third party storport miniport device driver intalled, the boot
can fail
3) copy over the matching drivers into the guest and allow it to
pick
them up on the first boot.
It should be pretty the same what v2v does. Some
sort of emulation of
what "software first" installation procedure does.
Cheers,
Vadim.
Obviously virtio-win driver packaging and libguestfs must agree on how
to deal with this.
Could you please provide any guidance on how to address this problem?
Thanks,
Roman.