+Cole. There are some packaging scripts and proposed BZs for making the iso and rpm contents rational. Adding Cole, since he is owner of at least one of the BZs. -Jeff On Tue, Nov 10, 2015 at 09:17:48AM +1100, Vadim Rozenfeld wrote:
On Mon, 2015-11-09 at 18:08 +0300, Roman Kagan wrote:
On Sun, Nov 08, 2015 at 10:15:31AM +0200, Yan Vugenfirer wrote:
On 06 Nov 2015, at 08:51, Vadim Rozenfeld <vrozenfe@redhat.com> wrote:
On Thu, 2015-11-05 at 21:46 +0000, Richard W.M. Jones wrote:
On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote:
On Wed, 2015-10-28 at 14:53 +0300, Roman Kagan wrote: > 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
Hi Vadim,
I've almost finished implementing this, but I have a couple of technical questions:
(1) How can we tell from the .inf file what architecture (x86 or amd64) the driver is for? There is a [Manufacturer] section which looks hopeful, eg:
[Manufacturer] %RHEL% = RHEL,NTAMD64
but the contents are not very consistent across all the .inf files I have access to.
Hi Richard,
It should be consistent. We do specify target architecture (amd64 or x86) when stamping inf/inx files. IIRC, qemupciserial.inf is the only exception, but it goes without binaries. In any case, if you are going to use existing distribution media, you can rely on the media layout - for example, if "amd64" is a part of your current path - you are in 64-bit directory.
(2) If we have a directory containing multiple drivers, can we assume that if any .inf file found matches the guest OS, then all those drivers can be installed? So far this appears to be true.
Yes, we will never mix 32 and 64 bit drivers into the same directory. I swear:)
If not then we have to start associating drivers with .inf files, which seems a bit complicated.
(3) You write:
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.
When you say "close minor version number" is there a particular definition you have in mind? eg. minor or minor-1 is OK? Or do we have to consider all .inf files in totality and choose the nearest one? Ideally, we should try finding the exact match. If not, we have to find one with the same major version number and nearest minor number which is smaller than the target one. For example, let's say we are looking for a driver for Win8.1/WS2012R2, we know that both of them have kernel version 6.3 . So, ideally we should to find inf file with the following driver version string:
DriverVer=XX/YY/ZZZZ,63.AA.BBB.CCCCC
if we cannot find an inf file with such criteria, we should try finding another one with the OS version 62 (which means that a driver was build for kernel 6.2 Win8/WS2012 and technically should be compatible with 6.3). So, we are looking for DriverVer which looks like this one: DriverVer=XX/YY/ZZZZ,62.AA.BBB.CCCCC
Still no luck - decrease the target OS version to 61 and repeat.
For WDF drivers like balloon, vioserial, and rng you can go as far as you can trying to find an appropriate driver.
For miniport drivers like netkvm ( Yan, please confirm ), viostor and vioscsi I wouldn't go too far. For example drivers designed to fork in specific stacks at kernel version 5.1 (WinXP) can refuse working with kernel 6.2 (Win8).
While NDIS miniport designed for NDIS 5.1 (XP) still can run on latest Windows, I wouldn’t do that. For NDIS 6.x (Windows 2008 and newer), we can use older drivers on new OS. But installing a driver for a newer OS on older OS might lead to driver miss-behaviour.
I'm wondering how people who don't rely on virt-v2v are supposed to discover the virtio drivers for their guests? This includes both those who do it programmatically and those who locate the appropriate drivers manually.
I mean, both manual and programmatic procedures should resolve to the same set of drivers, and ideally the procedure should be the same, declared official and documented.
I see no problem implementing any particular algorithm, no matter how complex, in v2v, but I'd like to make sure that my colleagues who, say, write a tool for unattended deployment of Windows guests, or others, who manually set up their Windows VMs, arrive at the same configuration.
I tend to think that your original idea of sorting that out on the driver build side, and storing the resulting drivers grouped by Windows arch/version following a well-defined and stable naming convention is a more reliable and universal solution.
It definitely shouldn't be so complicated. Packaging drivers on per-platform base can solve most of the problems. One single iso image, containing both 32 and 64 bit drivers compatible to run on Win8/Win8.1/WS2012/WS2012R2, and exposing an appropriate media layout "understandable" by all these platforms, is what we need. After all, the information provided n this thread, should be enough for writing a script that can split our single iso image into several properly build ones. In this case, the only thing you should worry about, is that <os>\<architecture> naming pattern is not the same among the various Windows platforms. IIRC there were some changes around Vista/Longhorn when Microsoft did it.
Cheers, Vadim.
Thanks, Roman.