On Thu, May 20, 2010 at 04:52:44PM -0400, Stefan Berger wrote:
Scott Feldman <scofeldm(a)cisco.com> 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 :|