From: Anthony Liguori <anthony@codemonkey.ws>
To: Bruce Rogers <brogers@novell.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] default mac address issue
Date: Mon, 10 May 2010 14:33:27 -0500 [thread overview]
Message-ID: <4BE85F87.1010000@codemonkey.ws> (raw)
In-Reply-To: <4BE8050F02000048000952DA@sinclair.provo.novell.com>
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
>
>
>
>
next prev parent reply other threads:[~2010-05-10 19:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 19:07 [Qemu-devel] [RFC] default mac address issue Bruce Rogers
2010-05-10 19:33 ` Anthony Liguori [this message]
2010-05-11 15:46 ` Bruce Rogers
2010-05-11 22:16 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE85F87.1010000@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=brogers@novell.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).