On 1/20/12 1:50 PM, "Laine Stump" <laine@xxxxxxxxx> wrote: > To refresh everyone's memory, the origin of the problem I'm trying to > solve here is that the VFs of an SRIOV-capable ethernet card are given > new random MAC addresses each time the card is initialized. If those VFs > are then passed-through to a guest using the existing <hostdev> config, > the guest will see a new MAC address each time the host is restarted, > and will thus believe that a new ethernet card has been installed. This > can result in anything from a dialog claiming that the guest has > connected to a new network (MS products) to a new network device name > showing up (Linux - "hmm, eth0 was unplugged, but here's this new > device. Let's call it "eth1"!) > > Several months ago I sent out some mail proposing a scheme for > automatically allocating network devices from a pool to be assigned to > guests via PCI passthrough: > > https://www.redhat.com/archives/libvir-list/2011-August/msg00937.html > > > My idea was to have a new <network> forward mode combined with guest > <interface> definitions that would end up auto-generating a transient > <hostdev> entry in the guest's config (and setting the VF's mac address > in the process). Dan Berrange pointed out in that thread that we really > do need to have a persistent <hostdev> entry for these devices in the > domain xml, if for no other reason than to guarantee that the same > guest-side PCI address is always used (thus preventing surprises in the > guest, such as re-activation demands from Microsoft OSes). (There were > other reasons, but that one was the real "hard stop" for me.) > > I've come back to this problem, and have decided that, while having the > actual host device auto-allocated at runtime would be nice, first > implementing a less ambitious solution that uses a hand-picked device > would not preclude adding the more complicated/useful functionality > later. So, here's a new simpler proposal. > > > Step 1 > ------ > > In the end, the solution will be that the VF's auto-generated random MAC > address should be replaced with a fixed MAC address supplied by libvirt > prior to assigning the VF to the guest. As a first step to satisfy this > basic requirement, I'm figuring to just extend the <hostdev> xml in this > way: > > |<hostdev mode='subsystem' type='pci' managed='yes'> > |<source> > |<address bus='0x06' slot='0x02' function='0x0'/> > |</source> > |<mac address='11:22:33:44:55:66"/> > |</hostdev> > > > When libvirt sees <mac address...> in the hostdev at device attach time, > it would first verify that the device is a network device (if not, it > would log an error and fail the operation). If it is a network device, > the pci address would be converted into a network device name, and that > device would have its MAC address set to the configured value, and then > the attach would proceed. > > My main questions here are: > > 1) Is this the right place for the new element? Or should it go into > <source>? > > 2) Should we bother trying to save the original MAC address to restore > when the device is released? (I guess that might be important if, for > example, the guest config was changed to use a different device but same > MAC address - you could end up with two devices having the same MAC > address). > > 3) I've seen requests from 2 places to do host-side virtual port > association (i.e. vepa / 802.1Qb[gh]). Would it be feasible to do that > association with the device after setting MAC address and before > assigning it to the guest? (and likewise for the inverse) Or would the > act of PCI assignment screw that up somehow? (one of the messages in the > earlier thread says something about the device initialization by the > guest un-doing necessary setup) (if it would work, a <virtualport> could > just be added along with <mac address>). Sorry for the late comment on this one. I have read the rest of the emails on this thread and I like where the discussions are going. I can speak for 802.1Qbh, and the virtual port association after setting the mac address and before assigning the device to the guest is the right direction to go. It will be similar to what we do for macvtap today. We will set mac (IFLA_VF_MAC) and set port profile (IFLA_VF_PORT) for the VF before the VM comes up. And the device initialization by the guest will not undo the mac and port profile configured by the hypervisor. Thanks for all the work on this and I would be happy to contribute in any way I can. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list