Open Stack

Hi
 
> 1) If the device is a "normal" PCI device, but is a network card, am I still able to
> take advantage of the advanced syntax added circa Juno to define the
> relationship between that card and a given physical network so that the
> scheduler can place accordingly (and does this still use the ML2 mech drvier for
> SR-IOV even though it's a "normal" device.

Actually libvirt won't allow using "normal" PCI devices for network interfaces into VM.
Following error is thrown by libvirt 1.2.9.1:
libvirtError: unsupported configuration: Interface type hostdev is currently supported on SR-IOV Virtual Functions only

I don't know why libvirt prohibits that. But we should prohibit that on Openstack side as well.
> 
> 2) There is no functional reason from a Libvirt/Qemu perspective that I couldn't
> pass through a PF to a guest, and some users have expressed surprise to me
> when they have run into this check in the Nova driver. I assume in the initial
> implementation this was prevented to avoid a whole heap of fun additional logic
> that is required if this is allowed (e.g. check that no VFs from the PF being
> requested are already in use, remove all the associated VFs from the pool when
> assigning the PF, who gets allowed to use PFs versus VFs etc.). Am I correct here
> or is there another reason that this would be undesirable to allow in future -
> assuming such checks can also be designed - that I am missing?
> 
I think that is correct. But even if the additional logic was implemented  it wouldn't work because of how libvirt behaves currently.

Regards
Przemek

> Thanks,
> 
> Steve
> 
> _________________________________________________________________
> _________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev