[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] [PATCH] v2v: virtio-win: include *.dll too


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.


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,
> >>>
> >>> This string contains build time and version stamps. The version stamp
> >>> looks as follow ""
> >>> 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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]