On 10/20/2017 01:38 PM, Pavel Hrdina wrote: > On Fri, Oct 20, 2017 at 01:20:20PM +0200, Michal Privoznik wrote: >> On 10/19/2017 03:33 PM, Pavel Hrdina wrote: >>> 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) >> >> Okay, these are easy to resolve. >> >>> >>> 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. >> >> This one. Well, this function is called only for ancient QEMUs (those >> which lack QMP, and even not for all of them). So do we care? Sure, I >> can cripple my code and allow user aliases only if running sufficiently >> new QEMU. Or just shrug and walk away. > > In that case just ignore it, it will print an error message and since > this will affect only hot-plug of network devices with user alias > specified we can claim that this operation is unsupported. Yeah. Just don't forget the ancient QEMU part. So the whole story is that if you're running QEMU that's lacking -netdev, and you want to hotplug an interface with user supplied alias, we error out. Yeah, I'm okay with that. We have to draw a line somewhere and say: yeah, it's probably bad behaviour, be we don't care. Patches are welcome. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
