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

[Jamie Lokier]

Anthony Liguori wrote:
> 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.

Yes, I've seen this when moving disk images between (real)
motherboards.  In the good old days it Just Worked.

Now, current distros using udev remember the MAC from the old board,
so the new board gets an interface called "eth1" instead of "eth0".

That's fine, but rather stupidly they've configured a useful default
for "eth0" which is DHCP, but the default for "eth1" etc. is to leave
it down.  Result: Disk moved to a replacement motherboard, and the
machine no longer responds to network connections.  Quite annoying if
it's a headless box, or one which boots up as a kiosk or something
with no console access.

Anyway, Anthony's right: Changing the MAC address of a guest each time
it is run (with the same disk image) is likely to be annoying.

It might be a good idea to store the chosen MAC in the qcow2 metadata,
if qcow2 is used?

For my Perl-managed qemu/kvm VMs, I find I need a small config file,
and a small state file which records run time state that survives
reboots (like the MAC address, and things like which CD and floppy
images were loaded).

(Perhaps in the search for a holy grail of a qemu config file format,
it might also be worth a mention that it's handy to store non-config
state somewhere too.)

-- Jamie