Bug 798467

Summary:	libvirt doesn't validate a manually specified MAC address for a KVM guest
Product:	Red Hat Enterprise Linux 6	Reporter:	Nandini Chandra <nachandr>
Component:	libvirt	Assignee:	Laine Stump <laine>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2	CC:	acathrow, cww, dallan, dyuan, jnevill, mshao, mzhan, rwu, whuang, zpeng
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	libvirt-0.9.13-3.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-21 07:08:27 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	782183

Description Nandini Chandra 2012-02-28 23:15:07 UTC

Description of problem:
For KVM guests, it is required that the first 3 pairs in the MAC address of the Ethernet interface be of the sequence ’52:54:00’.When a MAC address is not manually specified,the MAC address generated by libvirt is always of the sequence '52:54:00'.However,libvirt doesn't validate a manually specified MAC address for a KVM guest against the valid range.

For eg:The 'mac' parameter in virt-install can be used to specify the MAC address of the Ethernet interface on the KVM guest.

Version-Release number of selected component (if applicable):
libvirt-0.9.4-23.el6_2.5.x86_64


How reproducible:
Always

Steps to Reproduce:
1.While installing a KVM guest through virt-install,use the 'mac' parameter to
specify a MAC address where the first 3 octets are not of the sequence ’52:54:00’.
2.libvirt allows guest Ethernet interfaces to have a MAC address where the first 3 octets are not of the sequence ’52:54:00’.
3.
  
Actual results:
libvirt doesn't validate a manually specified MAC address for a KVM guest

Expected results:
libvirt should validate a manually specified MAC address for a KVM guest against the vaild range and display an appropriate error message.

Additional info:

Comment 2 Dave Allan 2012-02-29 01:15:46 UTC

There is no requirement that a KVM guest have a MAC with an OUI of 52:54:00 which is simply a 'locally administered' range that is used by qemu by convention and by libvirt's autogeneration mechanism.  In any event, libvirt does provides the mechanism to set whatever MAC the management application or the user specifies and should not second guess the user's choice.  This behavior is by design and is not a bug.

Comment 3 Nandini Chandra 2012-02-29 20:18:53 UTC

Bug 616517 was fixed in libvirt-0_8_1-17_el6. 

With this fix,libvirt assigns explicit MAC address to tap devices.The MAC address of the tap devices is computed by using the MAC address of the guest NIC,but with the high byte set to 0xFE.

So,if for some reason,the MAC address of the guest NIC is something like this:
[root@vm ~]ifconfig | grep eth0
eth0      Link encap:Ethernet  HWaddr FE:28:DD:C5:0D:54  
Note that the MAC address of the guest NIC has been manually specified in this case.

libvirt would assign the exact same address to the tap device
[root@kvmhost ~]#ifconfig | grep -i FE:28:DD:C5:0D:54
vnet11    Link encap:Ethernet  HWaddr FE:28:DD:C5:0D:54  


Because of this conflict,the KVM guest is unable to connect to the network and the following error message is seen on the KVM host:

Dec  7 10:24:43 bwy005223100d kernel: vnet9: received packet with own address as source address
Dec  7 10:24:44 bwy005223100d kernel: vnet9: received packet with own address as source address

Comment 6 Laine Stump 2012-03-05 17:06:14 UTC

I proposed this patch upstream:

https://www.redhat.com/archives/libvir-list/2012-March/msg00163.html

It logs an error and fails the domain start / device attach if it encounters a MAC address starting with 0xFE being attached to a bridge device. Is this a sufficient fix?

Comment 7 Laine Stump 2012-04-03 15:24:04 UTC

BTW, the above patch was pushed upstream and is in libvirt-0.9.11:

commit 5d57104538297a7e5dab21f9b7ca8070b80c24fb
Author: Laine Stump <laine>
Date:   Sun Mar 4 19:21:16 2012 -0500

    util: fail attempts to use same mac address for guest and tap
   
    If a guest's tap device is created using the same MAC address the
    guest uses for its own network card (which connects to the tap
    device), the Linux kernel will log the following message and traffic
    will not pass:
    
     kernel: vnet9: received packet with own address as source address
    
    This patch disallows MAC addresses with a first byte of 0xFE, but only in
    the case that the MAC address is used for a guest interface that's
    connected by way of a standard tap device. (In other words, the
    validation is done at runtime at the same place the MAC address is
    modified for the tap device, rather than when mac address is parsed,
    the idea being that it is then we know for sure the address will be
    problematic.)

Comment 11 Laine Stump 2012-05-16 19:42:58 UTC

Already upstream. so moving to POST

Comment 14 zhe peng 2012-07-25 03:24:15 UTC

I can reproduce this with build:libvirt-0.9.10-16.el6.x86_64

verify with:
libvirt-0.9.13-3.el6.x86_64

step:
1: via virt-install to install a guest with specify a MAC address:FE:28:DD:C5:0D:54

#virt-install -n demo -r 1024 -f /var/lib/libvirt/images/demo.img -s 4 --mac FE:28:DD:C5:0D:54 --cdrom /dev/cdrom
got libvirt error:
libvirtError: unsupported configuration: Unable to use MAC address starting with reserved value 0xFE - 'FE:28:DD:C5:0D:54' -
verification passed.

Comment 15 errata-xmlrpc 2013-02-21 07:08:27 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0276.html