qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] default mac address issue


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] default mac address issue
Date: Mon, 10 May 2010 14:33:27 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

Hi Bruce,

On 05/10/2010 02:07 PM, Bruce Rogers wrote:
I know this behavior has worked this way all along, but I wanted to bring up 
the following concern and float a few ideas about possible solutions. Please 
provide your perspective, opinion, etc.

qemu (or qemu-kvm) users can easily get into trouble when they don't specifying 
the mac address for their vm's nic and don't realize that multiple vm's running 
this way on the same network segment are colliding, since they all get a 
default mac address that is the same. They may be under the assumption that a 
random mac would be the default, as in many higher level tools for vm creation

This is certainly an important issue but it's one that's difficult to resolve.

Does it make sense to do any of the following:

1) have qemu print a warning to stdout/stderr that the default mac address is 
being used and that it will interfere with other vms running the same way on a 
common network segment

This is definitely reasonable.

2) what about changing the default behavior to randomizing the mac, and provide the legacy behavior 
with "-net nic,macaddr=default" or just "-use-default-mac"

(or, as a flip side to #2):

3) to at least make it easy for people to get around the problem, and just
use qem directly (without additional tools to launch qemu), add an option such as "-net 
nic,macaddr=randomize" or "-use-random-mac" which randomizes the mac for you
each time the machine is brought up, and hence avoids possible collisions.

A random mac address is almost always wrong. If you run a guest twice with this option, it's usually enough to trigger a new network detection which which rename the network device to ethN + 1. The result would be broken networking for naive users since distros don't bother configuring interfaces that weren't present during installation.

Regards,

Anthony Liguori

Of course having the same vm come up with a different mac each time is an issue 
for some guest os's, but for some usages, that is not a problem.

I imagine the concensus would be that the current behavior is appropriate, and 
it's up to management tools to do the randomization, but I think there is 
perhaps a place for randomization within qemu itself.  I'm interested to hear 
what you think.

Bruce







reply via email to

[Prev in Thread] Current Thread [Next in Thread]