On Thu, 2015-10-29 at 08:34 +0000, Richard W.M. Jones wrote:
On Wed, Oct 28, 2015 at 02:54:00PM -0400, Jeff Nelson wrote:
> BZ 1223668 suggests reorganizing the directory structure to allow for
> automatic driver discovery. This would change the iso directory
> structure from:
>
> /<driver>/<os>/<arch>/<file>
>
> to:
>
> /<arch>/<os>/<file>
>
> which is the same structure used in /usr/share/virtio-win/drivers and
> in the vfd files.
>
> Would this work?
I don't think this would make a difference to virt-v2v, since
(currently) v2v matches bits of the path to try to determine which
driver(s) to apply. Code is here:
https://github.com/libguestfs/libguestfs/blob/master/v2v/utils.ml#L185-L226
As Vadim pointed out in the other email, this information is already
encoded in the .inf files, and that seems like a better place to get
it from. If we do that, then the exact path will matter even less.
The key point here is "automatic driver discovery". Couple of years ago
we tried to come up with some sort of "universal" iso layout which will
work for all supported (at that time) Windows platforms from WinXP to
Win8/WS2012. Unfortunately it doesn't work, mostly because MS changed
the naming conversion pattern during the time. It's why I said that
maintaining a separate per-OS iso image will be the easiest (an probably
the only) solution.
Best regards,
Vadim.
- - -
I think the specific problem Roman was saying was that the directory
and the ISO contain different, overlapping subsets of the total set of
drivers. Which seems strange ...
virt-v2v can pull drivers out of either the ISO or the filesystem, but
(currently) not both. So if you point virt-v2v at the ISO you'll get
a different subset of the drivers from pointing v2v at the filesystem.
See also discussion of "VIRTIO_WIN" environment variable here:
http://libguestfs.org/virt-v2v.1.html#environment-variables
Rich.