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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
