This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

This problem is much harder to fix than it first appears.

The virtual network capability in libvirt is built using a bridge device, which is not connected to any physical ethernet devices. When a guest is started, its TAP device is added to the bridge. Guest access to the LAN is done by setting up  ip forwarding + NAT from the bridge to the LAN devices.

The bridge device has an IP address so that the guest can talk to the host OS and lets the host offer DHCP services to the guest. Thus the bridge device is the default router for the guest.

In Linux, a bridge device's MAC address *must* match the MAC address of one of the network interfaces enslaved in the bridge. If it doesn't match, then no traffic will ever flow.  Thus it is impossible to give the bridge device a fixed MAC address. The bridge device will inherit the MAC address of the first guest to be booted. If that guest shuts down, the bridge device will inherit the MAC address of one of the other remaining guests that are still running. So clearly the MAC address is changing over time & not stable.

In this virtual network scenario, there is no interface which is permanently attached to the bridge, so no stable MAC address is possible. A normal bridging scenario doesn't suffer from this problem because it always has a physical NIC enslaved, as well as the guests.

The only option i see is to attempt to create a dummy interface on the host which is used for nothing, except to be permanently enslaved in the bridge. 
I'm not prepared to experiment with such a change at this stage in the RHEL6 release process though.

*** Bug 650097 has been marked as a duplicate of this bug. ***

I've done some experimenting with Daniel's suggested fix, and started a discussion upstream:

https://www.redhat.com/archives/libvir-list/2010-December/msg00325.html

Patches have been posted upstream, comments made, and updated patches posted. These are awaiting final ACK and push, after which a backport can be done:

Intro:
https://www.redhat.com/archives/libvir-list/2011-February/msg00222.html

There is some more discussion on this thread, but here are the two most important items:

Prerequisite:
https://www.redhat.com/archives/libvir-list/2011-February/msg00223.html
V2 of the "meat" patch:
https://www.redhat.com/archives/libvir-list/2011-February/msg00304.html

The fix for this bug has been committed upstream:

   commit 13ae7a02b313b49fac90aed052fc7fc12d346400
   Author: Laine Stump <laine>
   Date:   Wed Feb 9 01:20:39 2011 -0500
   Subject: Allow brAddTap to create a tap device that is down

   commit 5754dbd56d4738112a86776c09e810e32f7c3224
   Author: Laine Stump <laine>
   Date:   Wed Feb 9 03:28:12 2011 -0500
   Subject: Give each virtual network bridge its own fixed MAC address

and a rebased version (pure cherry-pick) posted to rhvirt-patches:

http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-February/msg01147.html

1 Check that libvirt-0.8.7-8.el6.src.rpm has contained the following two patches:
libvirt-Allow-brAddTap-to-create-a-tap-device-that-is-down.patch
libvirt-Give-each-virtual-network-bridge-its-own-fixed-MAC-address.patch

2 Verified it on RHEL6-x86_64-Server with the following components and it passed:
libvirt-0.8.7-8.el6
qemu-kvm-0.12.1.2-2.147.el6
kernel-2.6.32-117.el6

The steps are as follows:
1 Install a win7 guest, fully virtualized, x86_64, kvm, default virtual
network (NAT)
2 boot the machine, shutdown and power on, repeat for 5 times, no prompt for new network. And the mac addr of guest and bridge will not change.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
A linux bridge device will always take on the MAC address of the lowest-numbered interface that is connected. This had meant that the MAC address of the bridges libvirt uses for virtual networks could change over time, depending on which guests were currently running and connected. This could sometimes create a problem because it would mean that the MAC address of the "next hop" / default route in IPv4 was changing. The most extreme example of this was that some versions of Windows, when run as guests connected to a libvirt virtual network would see the changed MAC address as an indication that it had been connected to a new network, and automatically bring up a configuration wizard on the screen.

Libvirt now creates a "dummy" tap device (it isn't actually used for traffic) with a "guaranteed lowest" MAC address, and connects this tap device to the bridge when it is created, thus guaranteeing that the bridge's MAC address will never change (and Windows will cease mistakenly believing that a new network has been connected). The mac address of the tap device is stored with the network configuration so that it will persist across host reboots.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,3 +1 @@
-A linux bridge device will always take on the MAC address of the lowest-numbered interface that is connected. This had meant that the MAC address of the bridges libvirt uses for virtual networks could change over time, depending on which guests were currently running and connected. This could sometimes create a problem because it would mean that the MAC address of the "next hop" / default route in IPv4 was changing. The most extreme example of this was that some versions of Windows, when run as guests connected to a libvirt virtual network would see the changed MAC address as an indication that it had been connected to a new network, and automatically bring up a configuration wizard on the screen.
+The MAC address of libvirt's bridges could change over time depending on which guests were currently running and connected. This caused problems in some Windows guests, which assumed that the changed MAC address indicated a new network connection, and automatically launched a configuration wizard. libvirt now creates a dummy tap device with a guaranteed lowest MAC address that will not change. This address is stored as part of network configuration so that it will persist across host reboots.-
-Libvirt now creates a "dummy" tap device (it isn't actually used for traffic) with a "guaranteed lowest" MAC address, and connects this tap device to the bridge when it is created, thus guaranteeing that the bridge's MAC address will never change (and Windows will cease mistakenly believing that a new network has been connected). The mac address of the tap device is stored with the network configuration so that it will persist across host reboots.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html

*** Bug 705701 has been marked as a duplicate of this bug. ***

In recent kernel, you can set bridge ID by setting bridge's MAC address like this:
# ip link set virbr0 address 10:10:10:10:10:10
# ip link show virbr0
12: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 10:10:10:10:10:10 brd ff:ff:ff:ff:ff:ff
# brctl show virbr0
bridge name	bridge id		STP enabled	interfaces
virbr0		8000.101010101010	yes		vnet0

This may be cleaner solution for setting up bridge ID.

This fix is included into kernel at this commit:
> commit 92c0574f11598c8036f81e27d2e8bdd6eed7d76d
> Author: Stephen Hemminger <shemminger>
> Date:   Tue Jun 17 16:10:06 2008 -0700
> 
>     bridge: make bridge address settings sticky
>     
>     Normally, the bridge just chooses the smallest mac address as the
>     bridge id and mac address of bridge device. But if the administrator
>     has explictly set the interface address then don't change it.
>     
>     Signed-off-by: Stephen Hemminger <shemminger>
>     Signed-off-by: David S. Miller <davem>