Re: [libvirt] [PATCH REPOST v2 0/3] Add callback mech for qemu and nodedev

On Tue, Feb 21, 2017 at 11:33:25AM -0500, John Ferlan wrote: BTW, could you include the full cover letter in each new version rather than making people follow links all the way back to v1 to find info about the patch series goals. IIUC, the intention here is that we automatically create NPIV devices when starting guests and delete them when stopping guests. I can see some appeal in this, but at the same time I'm not convinced we should add such a feature. AFAICT, the node device APIs already allow a management application to achieve the same end goal without needing this integration. Yes, it would simplify usage of NPIV on the surface, but the cost of doing this is that it ends a specific usage policy for NPIV in the libvirt code and makes error handling harder. In particular it is possible to get into a situation where a VM fails to start and we're also unable to clear up the NPIV device we just auto-created. Now this could be said to apply to pretty much everything we do during guest startup, but in most cases the failure is harmless or gets auto-cleaned up by the kernel (ie the tap devices get auto-deleted when the FD is closed, or SELinux labels get reset next time a VM wants that file, locks are released when we close the virtlockd file handle, etc). NPIV is significantly more complicated and more likely to hit failure scenarios due to fact that it involves interactions with off-node hardware resources. Is there some aspect of NPIV mgmt that can only be achieved if libvirt is explicitly managing the device lifecycle during VM start/stop, as opposed to having the mgmt app manage it ? If OpenStack were to provide NPIV support I think it'd probably end up dealing with device setup explicitly via the node device APIs rather than relying on libvirt to create/delete them. That way it can track the lifecycle of NPIV devices explicitly, and if it is not possible to delete them at time of QEMU shutdown for some reason, it can easily arrange to delete them later. Overall I think one of the more successful aspects of libvirt's design has been the way we minimise the addition of usage policy decisions, in favour of providing mechanisms that applications can use to implement policies. This has had a cost in that applications need todo more work themselves, but on balance I still think it is a win to avoid adding policy driven features to libvirt. A key question is just where "autocreation/delete of NPIV devices" falls in the line between mechanism & policy, since the line is not entirely black & white. I tend towards it being policy though, since it is just providing a less general purpose way todo something that can be achieved already via the node device APIs. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|