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

Hi,

I am the guy who puts together the virtio-win package for Red Hat. I
recently took over this role so I'm still in learning mode.


On Wed, Oct 28, 2015 at 04:15:06PM +0200, Yan Vugenfirer
wrote:
>> On 28 Oct 2015, at 13:53, Roman Kagan <rkagan@virtuozzo.com>
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.
Today, the virtio-win rpm contains:

* Individual driver files, installed onto the host contained in the
  directory hierarchy:

  /usr/share/virtio-win/drivers/<arch>/<os>/<file>

* an .iso file which is intended to be used within a Windows
  guest. The .iso directory hierarchy is:

  /<driver>/<os>/<arch>/<file>

* two vfd files--one for amd64 (x86_64), the other for x86 (i386)--
  that are floppy images, intended to be used as a Windows guest
  install-time alternative to the .iso. The vfd files contain
  essential drivers needed during installation: (block, scsi, net and
  qxl drivers).

>> 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
>>
>>  2) offline-"install" the storage driver and thus enable the
guest too
>>     boot
>>
>>  3) copy over the matching drivers into the guest and allow it to pick
>>     them up on the first boot
>>
>>
>> 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?
>
>As Vadim said: "The best way would be having a set of separate
distribution images packaged on per-platform base.”
>
>Otherwise you will have to maintain the knowledge of binary compatibility
between Windows platforms, which is different according to the driver type.
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?

-Jeff
>
>>
>> Thanks,
>> Roman.
>

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.

	- - -

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

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.
>