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

[Jeff Nelson]

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