The randomly generated ethernet addresses are not guaranteed to be unique. They usually are but there is no guarantee. Mostly they serve as placeholders for testing and development. For real world usage I recommend that you use the latest iproute2 package's "ip link set" commands to set the Virtual Function devices' MAC addresses administratively. You'll also need to use a 2.6.34 or later Linux kernel. Or if you'd like to you can use Xen 4.0.1 with the upstream stable 2.6.32.x PVOPs kernel. You can then download and install the latest ixgbe driver from Sourceforge which is Rev 184.108.40.206. That also supports the iproute2 "ip link set" commands.
Here's an example from my own Xen 4.0.1 development machine. To set the MAC addresses for 4 VF's for Physical Function interface eth3:
/usr/sbin/ip link set eth3 vf 0 mac 00:01:02:BA:BB:00
/usr/sbin/ip link set eth3 vf 1 mac 00:01:02:BA:BB:01
/usr/sbin/ip link set eth3 vf 2 mac 00:01:02:BA:BB:02
/usr/sbin/ip link set eth3 vf 3 mac 00:01:02:BA:BB:03
If you run "ipi link show eth3" after setting the VF MAC addresses you get the following output:
8: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:1b:21:3c:a3:1c brd ff:ff:ff:ff:ff:ff
vf 0 MAC 00:01:02:ba:bb:00
vf 1 MAC 00:01:02:ba:bb:01
vf 2 MAC 00:01:02:ba:bb:02
vf 3 MAC 00:01:02:ba:bb:03
Using these methods you can guarantee that you are assigning a unique MAC address. This is the best known method for avoiding accidental MAC address collisions.
Edited to make it clear that if you use the upstream Xen stable-2.6.32.x PVOPs kernel you cannot use the in-kernel version of ixgbe for SR-IOV. In-kernel support for SR-IOV on the ixgbe driver did not get in place until 2.6.34.