[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