Re: [Qemu-devel] Should we auto-generate IDs?

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

On 08/27/2015 01:08 PM, Jeff Cody wrote:
> On Thu, Aug 27, 2015 at 05:02:17PM +0100, Daniel P. Berrange wrote:
>>
>> Just to be clear - libvirt will *never* use an auto-generated device
>> IDs feature. It is way more complicated to let QEMU assign device IDs
>> and then auto-detect them from some 'info device-list' output, than
>> to just specify IDs upfront at device/object creation time which
>> it already does[1]. There is simply no benefit to auto-generating device
>> IDs for a mgmt app like libvirt, and plenty of downside.  Auto-generated
>> IDs will only be of interest to humans talking to the monitor directly
>> without a mgmt app involved.
>>
>> Regards,
>> Daniel
>>
>> [1] we don't provide IDs for qcow2 image backing file chain, but that's
>>     part of a bigger story that's being dealt with in this area.
> 
> This is the part that interests me the most :)
> 
> Do you think in dealing with image backing file chains, libvirt would
> ever make use of QEMU auto-generated node-names (either in the
> current feature set, or with future features)?  I'm not sure if your
> above statement is specific to device ID, or extends to node-names as
> well.

I have a patch series that I posted for libvirt that used a hack to try
and take advantage of auto-generated names (basically, you can't use
allocation watermark events on qcow2-over-block-devices without proper
node names).  Had we turned on auto node names in 2.4 (the release that
added the event), then it might be in libvirt now.  But now that we have
to support 2.4 without auto node names, it's in libvirt's long-term
interest to avoid technical debt and directly supply node names for all
BDS, rather than relying on node names, and rather than cheating by
waiting for qemu 2.5.

So my current task in libvirt is to try and fix things to supply node
names everywhere, then rewrite my allocation watermark event series atop
that change, at which point relying on auto names will not be necessary
for libvirt.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]