[libvirt] [PATCH v2 24/25] qemu: Support scsi controller model=virtio-{non-}transitional
Cole Robinson
crobinso at redhat.com
Wed Feb 6 17:33:14 UTC 2019
On 1/31/19 11:02 AM, Andrea Bolognani wrote:
> On Wed, 2019-01-30 at 17:38 +0100, Pavel Hrdina wrote:
>> On Tue, Jan 29, 2019 at 04:32:09PM +0100, Andrea Bolognani wrote:
>>>> <value>virtio-scsi</value>
>>>> <value>lsisas1078</value>
>>>> + <value>virtio-transitional</value>
>>>> + <value>virtio-non-transitional</value>
>>>
>>> As mentioned during the previous round of reviews, I think we should
>>> support model='virtio' (which would behave the same as the existing
>>> model='virtio-scsi') in order to have a nice, consistent experience
>>> for users and management application developers.
>>
>> If we add model='virtio' we should always translate it back to
>> 'virtio-scsi'. It's not a new model or new feature, it's just a
>> different name for existing model and we should not break management
>> applications that are already using 'virtio-scsi'. It would be
>> basically only alias.
>
> Definitely.
>
>> The question is whether it's useful, if
>> management application starts using 'virtio' when creating new guest it
>> would still had to be able to parse 'virtio-scsi' and my guess is that
>> it would not help at all.
>
> I agree that the value proposition is not that impressive once
> you've established the above.
>
> That said, implementing it is only going to take a couple of lines
> of code and it will allow applications that can afford to require
> very recent libvirt to only special-case SCSI controllers when
> parsing the configuration, instead of both when parsing and when
> formatting.
>
> I guess I just don't see a reason *not* to implement it. But if
> Cole doesn't want to go through with it that's fine, I can just
> post patches later myself :)
>
My reason for objection was to not bog down the patch series with
essentially tangential discussions. If I added the patch here, and it
prompted a big discussion, it could block the whole series (this should
all be committed as a single unit so apps can key off a single
domaincapabilities field or libvirt version to determine if
-transitional support is in place)
It's also kind of new territory to add a model that's essentially an
alias like pavel points out, which potentially deserves a wider
discussion, and buried in a big series isn't really the place IMO. Plus
I wanted to dig a bit into the archives to see why model=virtio-scsi
naming was chosen in the first place, maybe there was a specific
argument for that naming.
All that said, I'm not opposed to the idea and it is on my list to look
into after this series is committed. It's just very much a side issue
here IMO
Thanks,
Cole
More information about the libvir-list
mailing list