Re: [ovirt-devel] SR-IOV feature

----- Original Message ----- The logical network can be vlan tagged. As you mentioned the vf_vlan is one of the parameters to the vdsm (on create verb). Setting the vlan on the vf is done as follows- ip link set {DEVICE} vf {NUM} [ vlan VLANID ] It is written in the notes section. It is not related to the use of virtio. The vlan can be set on the vf whether it is connected to the vm via macvtap or directly. Martin Polednik is working on pci-passthrough- http://www.ovirt.org/Features/hostdev_passthrough Maybe we should wait for his feature to be ready and then combine it with the sr-iov feature. As I see in his feature page he plans to attach a specific device directly to the vm. We can combine his feature with the sr-iov feature- 1. The network profile will have type property- bridge (the regular configuration we have today, vnic->tap->bridge->physical nic). virtio(in the current feature design it is called passthrough, vnic->macvtap->vf) pci-passthrough(vnic->vf) 2. Attaching a network profile with pci-passthrough type to a vnic will mark the vm as non-migratable. 3. When running a vm with pci-passthrough vnic a free VF will be attached to the vm with the vlan and mtu configuration of the profile/network (same as for virio profile, as described in the feature page). The benefit of it is that the user won't have to choose the vf directly and will be able to set vlan and mtu on the vf. :) Today we mark the logical network with a role (management/display/migration) when attaching it to the cluster. A logical network can be attached to one physical nic (PF). We can't use the current attachment of a role for sr-iov, since the network can be configured as "vf allowed" on more than one nic (maybe even on all the nics). If the network is "vf allowed" on the nic, a vnic with this network can be attached to a free vf on the nic. So we can't use the logical network to mark a vf with a role. We have to mark the vf explicitly. Since in the current design we don't expose the vf, setting the roles was blocked. But if there is a requirement for setting a vf as management/migration/display we can re-think about the design for it. Updated the wiki with the following- "It is used for admin to enable this number of VFs on the nic. Changing this value will remove all the VFs from the nic and create new #numOFVfs VFs on the nic." The max value reported by getVdsCaps is just the theoretical maximum value. As I wrote in the answer about the roles. There are two concepts- 1. The attachment of network to physical nic (what we have today). 2. Containing the network in the "VFs managenet tab=>allowed networks" of the nic. In 1, we actually configure the host's nics and bridges according to the setup networks. In 2, we just specify the "allowed" list, it doesn't even sent to the vdsm. It is used by the engine when it schedules a host for a vm. The connection between networks to nics is many to many. The same network can be part of 1 and 2 on the same nic. And even part of 2 in other sr-iov enabled nics. Since 2 is completely different concept than 1, we weren't sure that using drag and drop as for PFs isn't to much in this case. Expected to work (but wasn't tested yet).