> > When it is set to 'yes', some check whether a device is safe to be
> > assigned to a guest will be weakened.
>
> I think this is a rather ill-defined concept to be adding the guest XML,
> since there are many checks done for assignment, and this is only impacting
> one of them. Whether to allow a device beind a non-ACS enable switch to be
> used in a VM has implications beyond just the one VM it is assigned to. Thus
> is strikes me that the decision as to whether to allow use of devices behind
> non-ACS switches should be a host level attribute. eg a config item in the
> /etc/qemu/qemu.conf file
This was the idea behind:
What remains to be implemented is the logic of the whitelist that you
mention in comments #2 and #3. To be honest, I don't love this idea of the
whitelist; not only will we have to maintain some kind of table, we will need
to make sure the table is up-to-date every time new hardware comes out. It
also breaks the security of the setup without letting the user know about
(because it is on a magic whitelist that the user probably won't know anything
about).
I have an alternate proposal. What if we added a new <permissive/> tag
to the libvirt XML for device assignment? In the normal case, we wouldn't
allow *any* passthrough of devices behind non-ACS switches. However, if the
user knows what they are doing, and they want to take this risk, they can add
the <permissive/> tag to the XML, in which case it would allow the assignment
to happen. This can even be used pretty successfully in virt-manager; it just
needs to catch the appropriate exception from the first assignment, pop-up
"This is dangerous because of non-ACS, blah, blah. Are you sure?", and then
re-do the assignment with the <permissive/> tag.
I just changed it to an attribute as I think it fits better.
Jirka
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list