Bug 667457

(In reply to comment #1)
> #ip link set dev eth1 vf 0 mac 00.11.22.33.44.55
> 

What does it change to in the VM?

(In reply to comment #1)
> (In reply to comment #1)
> > #ip link set dev eth1 vf 0 mac 00.11.22.33.44.55
> > 
> 
> What does it change to in the VM?

nothing happens to the VM if I set the mac address while the VM is running. Even if I restart the network, the VM keep its old Mac address.

(In reply to comment #1)
> (In reply to comment #1)
> > #ip link set dev eth1 vf 0 mac 00.11.22.33.44.55
> > 
> 
> What does it change to in the VM?

nothing happens to the VM if I set the mac address while the VM is running. Even if I restart the network, the VM keep its old Mac address.

Hello, 

I am a begginer with Linux. I apologize that my comment is about Centos 6 but I hope it is usefull.

I have been fighting with this bug for a week. I am using an AMD Opteron CPU with an Intel E1G42ET Dual Port NIC. I am using Centos 6.0 and KVM, kernel 2.6.32-71.el6.x86_64 (newer Kernel has issues with LSI card).

I repeated the issue several times but it seemed to dissapear after I did this:

- KVM HOST: With VMs running or not, I modified the MAC of all teh VFs using the command in the first post
- VM: I edited /etc/udev/rules*/70-persistent-net.rules to remove references to the 82576 VFs
- KVM HOST: Restarted libvirtd
- KVM HOST: Verified that the new MACs were still correct with ip link show dev eth0
- VMs: Rebooted all active VMs
- KVM HOST: After VMs were up, verified the new MACs were still correctly assigned to the VFs
- VMs: Verified 

I rebooted the VMs and also shut them down and restarted several times and the issue is gone. 
I will verify what happens when I reboot the host. I assume that I will get some random MACs so I will reassign the new MACs and RESTART libvirtd before I start any VM.

I will let you know what happens in another post.
Have a great day.

Hello, 

It looks like it is working for me.

I restarted the host, modified the VF MACs, restarted libvirtd, and then started the VM and the MACs are the same as before.

In the future, I will have to research whether there is a way to permanently set the MACs to the nic or the driver.

Thank you

(In reply to comment #3)
> (In reply to comment #1)
> > (In reply to comment #1)
> > > #ip link set dev eth1 vf 0 mac 00.11.22.33.44.55
> > > 
> > 
> > What does it change to in the VM?
> 
> nothing happens to the VM if I set the mac address while the VM is running.
> Even if I restart the network, the VM keep its old Mac address.

It looks like libvirtd keeps the old MACs in memory and reuse then when the VM is rebooted. That is what seems to happen in my host.

Restarting libvirtd seemed to fix it

Hope it helps.
Regards,

I can't explain why "restarting libvirtd seemed to fix it", but it isn't because of libvirtd remembering a MAC address; when a network device is assigned to a virtual guest via PCI passthrough, libvirt doesn't have any idea that it is a network device, and thus doesn't even know that there's a MAC address associated with the device.

Also, I'm curious what the entries in the udev file were for the VFs. I don't have any of this hardware, but I had understood that the VFs are given a new random MAC address on each reboot...

There has been some discussion about making libvirt's <hostdev> (PCI passthrough) aware of info normally associated with network interfaces (e.g. mac address and <virtualport> parameters), which might solve this problem. For example:

https://www.redhat.com/archives/libvir-list/2011-August/msg00937.html

(note that the proposal in that particular mail won't work, for the reasons given in the followups, but a future followup may point to an acceptable design.)

(In reply to comment #7)
> I can't explain why "restarting libvirtd seemed to fix it", but it isn't
> because of libvirtd remembering a MAC address; when a network device is
> assigned to a virtual guest via PCI passthrough, libvirt doesn't have any idea
> that it is a network device, and thus doesn't even know that there's a MAC
> address associated with the device.
> 
> Also, I'm curious what the entries in the udev file were for the VFs. I don't
> have any of this hardware, but I had understood that the VFs are given a new
> random MAC address on each reboot...
> 
> There has been some discussion about making libvirt's <hostdev> (PCI
> passthrough) aware of info normally associated with network interfaces (e.g.
> mac address and <virtualport> parameters), which might solve this problem. For
> example:
> 
> https://www.redhat.com/archives/libvir-list/2011-August/msg00937.html
> 
> (note that the proposal in that particular mail won't work, for the reasons
> given in the followups, but a future followup may point to an acceptable
> design.)

Laine, 

Thank you very much for your reply.
Please let me know if there is any file in my system that would give you more information and I will post it.
The workaround has been working fine for me. I haven't yet made the script run upon startup because I like to see how the system is configured before and after I run it.
BTW, you are right in that every time I reboot the MAC are completely different. That became an issue because my Linux guests could not find the NICs as a new eth nic was created for each MAC.

I apologize that I can not be more helpful. I am fairly new in Linux.
Please let me know what info you need and I will get it.

Regards,

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Sorry for not addressing this bug, but F14 is EOL now, so I'm closing this
report. Please reopen if this is still relevant in a more recent fedora.

I'm again working on a solution for this, hopefully to be in F17.

Here is a patch submitted upstream to support parsing/formatting <interface> devices of type='hostdev':

  https://www.redhat.com/archives/libvir-list/2012-February/msg00841.html

These devices will be treated just like <hostdev> devices, except that during attach time the mac address (and virtual port profile info) will be set by the host before assigning the device to the guest.

The low level code is on the way, too. Please comment on the config format in the mailing list thread.

I've updated my patches to properly present the PCI device to the guest if it's
defined as <interface type='hostdev'>. This completes all the basic infrastructure functionality, including hotplug attach/detach. All that is left now is the callouts from the hostdev code to save/set/restore mac address.

These patches are available either frmo the list archives:

  https://www.redhat.com/archives/libvir-list/2012-February/msg01126.html

or from a public repo on gitorious:

  git://gitorious.org/~laine/libvirt/laine-staging.git

The code in question is on the "passthrough8" branch. You should be able
to get that branch into your local repo like this:

  git remote add laine-staging \
      git://gitorious.org/~laine/libvirt/laine-staging.git
  git fetch laine-staging
  git checkout laine-staging/passthrough8

A 21 patch series to add this functionality has been pushed upstream 

Upstream commit ids in order (short form):

9890b31 conf: add missing device types to virDomainDevice(Type|Def)
4ec60df conf: relocate virDomainDeviceDef and virDomainHostdevDef
fdad9c3 conf: reorder static functions in domain_conf.c
37038d5 qemu: rename virDomainDeviceInfoPtr variables to avoid confusion
2f925c6 conf: add device pointer to args of virDomainDeviceInfoIterate callback
2929393 conf: make hostdev info a separate object
5560170 conf: HostdevDef parse/format helper functions
b973f92 conf: give each hostdevdef a parent pointer
3175df8 conf: put subsys part of virDomainHostdevDef into its own struct
cc5b1fe conf: hostdev utility functions
6fbb957 qemu: re-order functions in qemu_hotplug.c
93870c4 qemu: refactor hotplug detach of hostdevs
3b1c191 conf: parse/format type='hostdev' network interfaces
8639a42 qemu: support type='hostdev' network devices at domain start
ac9ca01 conf: change virDomainNetRemove from static to global
16520d6 qemu: use virDomainNetRemove instead of inline code
cf90342 qemu: support type=hostdev network device live hotplug attach/detach
b8b7027 util: two new pci util functions
5095bf0 util: support functions for mac/portprofile associations on hostdev
15bbfd8 util: Changes to support portprofiles for hostdevs
ce43483 qemu: install port profile and mac address on netdev hostdevs

For future reference, these patches will all be in libvirt-0.9.11