Description of problem: Currently the ISO included in the virtio-win RPM contains different files than the directories created by the RPM under /usr/share/virtio-win. If there's a reason for this, please provide a README file explaining the differences. If there is no reason for this, please make sure the files/dirs under /usr/share/virtio-win match to those in the ISO file. For example, /usr/share/virtio-win/drivers/amd64/Win7 contains only netkvm.cat, netkvm.inf, and netkvm.sys but ISO contains netkvm.cat, netkvm.inf, netkvm.pdb, netkvm.sys, netkvmco.dll, readme.doc. For a regular administator it's quite hard to know the reason for the differences and can the drivers in the directories used or is using the ISO always a must. Version-Release number of selected component (if applicable): virtio-win-1.7.1-1.el7.noarch
AFAIK the files located in /usr/share/virtio-win/drivers/ is same as the layout of virtio-win.vfd which is split into virtio-win_x86.vfd and virtio-win_amd64.vfd now. I see no reason why they are there ,and I believe they can be removed from the build. Mike
Lev, are you using /usr/share/virtio-win/drivers/? Does anybody see a reason to keep those files? Is it a compatibility issue?
(In reply to Ronen Hod from comment #3) > Lev, are you using /usr/share/virtio-win/drivers/? > Does anybody see a reason to keep those files? Is it a compatibility issue? If that's the exploded ISO tree, then I believe virt-v2v uses them, CCing rjones
Yes we are using those, do not delete them.
(In reply to Ronen Hod from comment #3) > Lev, are you using /usr/share/virtio-win/drivers/? > Does anybody see a reason to keep those files? Is it a compatibility issue? Ronen, we (RHEV) don't usually use these, but they may be useful to customers who want to provide the drivers through i.e. USB redirection of Spice. I see no harm of them being there, it's just a copy of the minimum set of drivers provided on VFDs.
Yeah it's a bit strange to me that we ship a copy of the .vfd driver contents in /usr/share, but not the rest of the drivers. And it's also confusing why the iso has .dlls and the .vfd doesn't, etc. There's probably reasons but I don't know them. I'll try and find out. I think it's worth looking into shipping the full iso contents under /usr/share, or maybe generating an additional RPM package that provides it if the size is prohibitive. I agree though that installing a README that explains what's going on a bit would be helpful. This stuff is confusing :) I've filed a bug to track it: https://bugzilla.redhat.com/show_bug.cgi?id=1217658
Cole, virt-v2v depends on the virtio-win package name and the current location of the drivers, so please don't move stuff around arbitrarily. Adding extra files is fine.
Defering to 7.3, this isn't critical and I won't get to this in the near term
For spice-guest-tools/ovirt-guest-tools ( http://cgit.freedesktop.org/spice/spice-nsis/ ), having all the virtio-win drivers available in /usr/share/virtio-win/drivers (or wherever appropriate) would be very useful. Having this in the main package or in a different package does not matter for us. Currently, oVirt regenerates an RPM with the same content as the ISO, but unpacked: https://gerrit.ovirt.org/gitweb?p=ovirt-wgt-toolchain.git;a=blob;f=specs/virtio-win-drivers/virtio-win-drivers.spec;h=9c5bdaf05d3abe404d33e5abb20fa07c7d049bd0;hb=HEAD (this work is probably going to be moved to spice-guest-tools build instead).
Christophe and Cole, thanks for discussing this and adding the above comment. A small addition - if/when you resolve this issue, please keep identical files hard-linked, as they are currently inside the iso. Thanks.
(In reply to Marko Myllynen from comment #0) > Description of problem: > Currently the ISO included in the virtio-win RPM contains different files > than the directories created by the RPM under /usr/share/virtio-win. If > there's a reason for this, please provide a README file explaining the > differences. If there is no reason for this, please make sure the files/dirs > under /usr/share/virtio-win match to those in the ISO file. > > For example, /usr/share/virtio-win/drivers/amd64/Win7 contains only > netkvm.cat, netkvm.inf, and netkvm.sys but ISO contains netkvm.cat, > netkvm.inf, netkvm.pdb, netkvm.sys, netkvmco.dll, readme.doc. For a regular > administator it's quite hard to know the reason for the differences and can > the drivers in the directories used or is using the ISO always a must. > > Version-Release number of selected component (if applicable): > virtio-win-1.7.1-1.el7.noarch netkvm.cat, netkvm.inf, and netkvm.sys - those are the driver files. netkvm.pdb - this is a symbol file that can be used with WinDbg or Visual Studio to analyse the crash dumps or debug driver behaviour. netkvmco.dll, readme.doc - this is a netsh plugin that can be used to change parameters of virtio-net driver from command line (for example MTU size or different offload settings). The existence of this tool is mandated by MS as part of certification requirements. The tools itself is not referenced by driver INF file, so it is not mandatory for the installation but it can be useful for testing\system administration.
There's been some discussions and patches in this area. http://thread.gmane.org/gmane.comp.emulators.guestfs/8341/focus=8576 https://www.redhat.com/archives/virt-tools-list/2016-January/msg00060.html
This is another one that keeps limping along and there isn't any pressing customer need, so moving to the upstream product=Virtualization Tools. This should be done as part of the large file reorg to accomodate bug 1223668
The public virtio-win-0.1-173-4 RPM now has a complete driver tree, with two different layouts: * /usr/share/virtio-win/drivers/by-driver: matches the ISO driver layout * /usr/share/virtio-win/drivers/by-os: uses $arch/$os naming, with $arch matching what windows expects for auto driver detection The old drivers/i386 and drivers/amd64 files are still there, but they will not be extended in the future, so don't use them.