[libvirt] [PATCH v1 00/14] Never ending story of user supplied aliases

Pavel Hrdina phrdina at redhat.com
Thu Oct 19 13:33:25 UTC 2017


On Thu, Oct 19, 2017 at 10:10:55AM +0200, Michal Privoznik wrote:
> As discussed earlier [1], we should allow users to set device
> aliases at the define time. While the discussed approach calls
> for generating missing aliases too, I'm saving that for another
> patch set. There are couple of reasons for that:
> 
> a) I don't think it's really necessary (if users are interested
>    in a device they can just set the alias).
> 
> b) This patch set is already big enough as is.
> 
> c) Generating aliases is going to have its own problems.
> 
> Therefore, for now I'm only proposing parsing user supplied
> aliases. The idea is that it's not enabled by default for all
> drivers. Any driver that want to/can provide this feature has to
> set VIR_DOMAIN_DEF_FEATURE_USER_ALIAS. Note that we have some
> drivers that don't have notion of device aliases. But the code is
> generic enough so that it should be easy to use in the drivers
> that do know what aliases are.

This patch series missed some of the important parts of code
that relies on our generated aliases:

1. qemuGetNextChrDevIndex() ... this will fail while attaching new
   chardev device without an alias if there is one already provided
   by user and doesn't match the one that we generate.

2. qemuAssignDeviceRedirdevAlias() ... same as 1)

3. qemuAssignDeviceShmemAlias() ... same as 1)

4. qemuDomainNetVLAN() ... similar to the previous ones, hot-plugging
   network interface with user alias will fail because the alias is used
   to figure out VLAN of the interface.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20171019/d85d8a4d/attachment-0001.sig>


More information about the libvir-list mailing list