On Tue, Aug 23, 2011 at 01:53:42PM +0200, D. Herrendoerfer wrote:
On Aug 23, 2011, at 12:50 PM, Daniel P. Berrange wrote:
>[...snip...]
>
>>This makes using SRIOV VFs via PCI passthrough very unpalatable. The
>>problem can be solved by setting the MAC address of the ethernet
>>device prior to assigning it to the guest, but of course the
>><hostdev> element used to assign PCI devices to guests has no place
>>to specify a MAC address (and I'm not sure it would be appropriate
>>to add something that function-specific to <hostdev>).
>
>In discussions at the KVM forum, other related problems were
>noted too. Specifically when using an SRIOV VF with VEPA/VNLink
>we need to be able to set the port profile on the VF before
>assigning it to the guest, to lock down what the guest can
>do. We also likely need to a specify a VLAN tag on the NIC.
>The VLAN tag is actally something we need to be able todo
>for normal non-PCI passthrough usage of SRIOV networks too.
>
I guess there is a issue with PCI-passtrough here, If the VEPA link
is set up prior to VM start then that information is lost when the VM
OS resets the device during initialization.
IIUC, this is not a problem. When libvirt sets the VEPA/VNLink
information, it does so against the PF of the NIC. When a VF
is reset, it pulls its configuration from a config space in the
PF. So if the guest resets the VF, it'll just reinitialize itself
with the data libvirt set on the PF.
Only on NICs with an integrated bridge can this setup be persistent
because the bridge can handle the VLAN tagging and port setup.
I see a major drawback with storing MAC adresses in <hostdev>
elements: It would require great care to make sure that MAC adresses
are unique across a big datacenter.
Most large scale deployments are going to be using some kind of
management tool that tracks guests across all hosts. Such a tool
has a global view of the network, so can hand out unique MACs
for guests as required.
Libvirt also recently gained support for integrating with lock
managers. We use this to ensure unique access to disk images
currently. We can in theory extend this to do uniqueness checks
on any type of resource associated with a guest. So we could
add locks based on the MAC addresses to avoid duplication.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|