On Thu, May 20, 2010 at 04:52:44PM -0400, Stefan Berger wrote: > Scott Feldman <scofeldm@xxxxxxxxx> wrote on 05/20/2010 03:22:12 PM: > > > > > Next steps for V3, etc: > > > > 1) merge with Stefan's latest patch, as much as possible > > Yes. Try to make it a patch on top of my V5 patch... > > > 2) assign VM device mac addr to eth and set macvtap mac addr to random > > Hm, why is this necessary? I have tested the macvtap device and always set > it to the address that libvirt assigned to it and that happened to be the > same as the one inside the VM? Is this something specific to your > underlying driver? > > > 3) figure out where host_uuid lives > > I posted a message a while ago. It's not anywhere right now and should > probably be provided via libvirt.conf overriding dmidecode, but dmidecode > being used if its output is valid and resorting to a temporary (between > libvirt restart) host uuid if everything fails... Agreed, we should likely put it in /etc/libvirt/libvirtd.conf and have a convenience function in src/util/uuid.h called virGetHostUUID() so we avoid putting this logic in the drivers. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list