On Wed, Oct 28, 2015 at 04:15:06PM +0200, Yan Vugenfirer wrote:
> On 28 Oct 2015, at 13:53, Roman Kagan <rkagan(a)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.
>
> 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.”
Great, but apparently this style of packaging is supposed to happen on
virtio-win side of things, and libguestfs would just need to adapt.
Presumably there supposed to be a separate iso or floppy image
containing all the drivers for each Windows flavor, and some stable
naming convention for such images making it easy to map the guest OS to
the image.
Is there any work on that being done or planned?
Otherwise you will have to maintain the knowledge of binary
compatibility between Windows platforms, which is different according
to the driver type.
Indeed, this doesn't look realistic within libguestfs.
Thanks,
Roman.