On 22/02/2017 11:05, Daniel P. Berrange wrote: > I'd also suggest just assigning the whole vHBA What do you mean by "assigning the whole vHBA"? There is no concept of a vHBA as e.g. a PCI virtual function. > , but We can still make > it possible for a mgmt app to dynamically add/remove LUNS from a vHBA. > Our node device APIs can report events when devices appear/disappear > so an app can create a vHBA and monitor for LUN changes & update the > guest. That said I'm curious how you'd handle remove, because surely > by the time you see a LUN disappear at vHBA, the guest is already > broken as its got an orphaned device. This seems like another reason > to just assign the vHBA itself to let the guest deal with LUN removal > more directly. This is the same on bare metal: the device is orphaned at the time you unplug it. If the guest is using it and doesn't have a fallback, bad things happen. If it is not using it, or if it's using multipath, things ought to work just fine. Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
