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

On 02/21/2017 12:03 PM, Daniel P. Berrange wrote: > On Tue, Feb 21, 2017 at 11:33:25AM -0500, John Ferlan wrote: >> Repost: http://www.redhat.com/archives/libvir-list/2017-February/msg00501.html >> >> to update to top of branch as of commit id '5ad03b9db2' > > 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. OK - I'll try to remember. > > 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. A bit more than that - create the vHBA and assign the LUN's to the guest as they are discovered and remove them as they are removed (events from udev). This is a mechanism/idea from Paolo. The RHV team would be the primary consumer and IIRC they don't use storage pools. > > 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. I agree with your points. The "purpose" of libvirt taking care of it would be to let libvirt handle all those nasty and odd failure or integration issues - including migration. Of course from a libvirt perspective, I'd rather take the 'scsi_hostX' vHBA and just pass that through to QEMU directly to allow it (or the guest) to find the LUN's, but that's push the problem the other way. I said early on that this is something that could be done by the upper layers that would be able to receive the add/remove lun events whether they created a storage pool just for that purpose or they created the vHBA themselves. It's probably even in the bz's on this.