[RFC] Dynamic creation of VFs in a network definition containing an SRIOV device

Paulo de Rezende Pinatti ppinatti at linux.ibm.com
Tue Jul 28 15:03:17 UTC 2020


Libvirt can already detect the active VFs of an SRIOV PF device 
specified in a network definition and automatically assign these VFs to 
guests via an <interface> entry referring to that network in the domain 
definition. This functionality, however, depends on the system 
administrator having activated in advance the desired number of VFs 
outside of libvirt (either manually or through system scripts).

It would be more convenient if the VFs activation could also be managed 
inside libvirt so that the whole management of the VF pool is done 
exclusively by libvirt and in only one place (the network definition) 
rather than spread in different components of the system.


We can extend the existing network definition by adding a new tag <vf> 
as a child of the tag <pf> in order to allow the user to specify how 
many VFs they wish to have activated for the corresponding SRIOV device 
when the network is started. That would look like the following:

    <forward mode='hostdev' managed='yes'>
      <pf dev='eth1'>
         <vf num='10'/>

At xml definition time nothing gets changed on the system, as it is 
today. When the network is started with 'virth net-start sriov-pool' 
then libvirt will activate the desired number of VFs as specified in the 
tag <vf> of the network definition.

The operation might require resetting 'sriov_numvfs' to zero first in 
case the number of VFs currently active differs from the desired value. 
In order to avoid the situation where the user tries to start the 
network when a VF is already assigned to a running guest, the 
implementation will have to ensure all existing VFs of the target PF are 
not in use, otherwise VFs would be inadvertently hot-unplugged from 
guests upon network start. In such cases, trying to start the network 
will then result in an error.

Stopping the network with 'virsh net-destroy' will cause all VFs to be 
removed. Similarly to when starting the network, the implementation will 
also need to verify for running guests in order to prevent inadvertent 

Is the functionality proposed above desirable?

Thanks and best regards,

Paulo de Rezende Pinatti

More information about the libvir-list mailing list