Bug 427390 - simulated network devices should randomize macaddr
simulated network devices should randomize macaddr
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: David Woodhouse
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-03 12:25 EST by Frank Ch. Eigler
Modified: 2009-05-25 12:35 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-25 12:35:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frank Ch. Eigler 2008-01-03 12:25:32 EST
Description of problem:
When running more than one qemu(-kvm) instance on a given machine,
simulated network devices share the default macaddr.  On a brctl
type bridge, this makes all but one unusable at a time.


Version-Release number of selected component (if applicable):
qemu-0.9.0 / kvm-36-7

How reproducible:
always

Steps to Reproduce:
1. Run qemu(-kvm) with "-net nic -net tap" ..., with a suitable /etc/qemu-ifup
w/ brctl for a bridged interface
2. Observe it'll show up in arp and be fully networked
3. Start up another virtual machine.
4. Observe that it will share the same MAC address.
  
Actual results:
Network traffic to all but one of the VMs is blocked.

Expected results:
All VMs can talk independently concurrently.

Additional info:
By providing a non-default "-net nic,macaddr=AA:BB:CC:DD:EE:FF" parameter,
with different AA:...:FF of course, all virtual machines happily chat.  What
I'd like to see is the default (52:54:00:12:34:56) mac address to be replaced
by a randomized/unique one, so a VM user does not have to bother.
Comment 1 Bug Zapper 2008-05-14 00:16:45 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Edouard Bourguignon 2009-03-25 12:39:21 EDT
seems we have the same problem on RH5.2

ifconfig -a on VM shows same MAC on all interfaces
Comment 3 Chris Lalancette 2009-05-25 09:32:16 EDT
Hm, I'm not exactly sure that qemu is the right level to be solving this problem.  I can imagine a developer scenario where you want to make sure that your guest always has the same MAC, so that it always gets the same IP address for easy access, etc.

If you use the higher level management tools like libvirt, this problem goes away.  Libvirt does in fact randomize mac addresses (if not specified), so it takes care of this issue but at a higher level.  Does that suffice for your purposes?

Chris Lalancette
Comment 4 Frank Ch. Eigler 2009-05-25 09:45:54 EDT
(In reply to comment #3)
> Hm, I'm not exactly sure that qemu is the right level to be solving this
> problem.  I can imagine a developer scenario where you want to make sure that
> your guest always has the same MAC, so that it always gets the same IP address
> for easy access, etc.

Perhaps a simple change would be then to generate the MAC address based upon
a hash/random-seed based upon things like the disk image file's inode, or
a few similar quantities.  Those developers who really want to make sure of
the address staying the same can of course supply the macaddr manually.  The
question is which one is likely to make more sense by default.

> If you use the higher level management tools like libvirt, this problem goes
> away.

Well sure, one can wrap qemu any which way to do this, but the default
still seems unhelpful for users of multiple VMs.
Comment 5 Mark McLoughlin 2009-05-25 12:35:59 EDT
Upstream decided to reject this feature:

  http://www.ultraviolet.org/mail-archives/qemu.2009/msg01849.html

Closing as WONTFIX ... there's not too much point in debating the merits of it here if upstream has already rejected it. Please feel free to discuss further on qemu-devel@nongnu.org. Thanks

Note You need to log in before you can comment on or make changes to this bug.