[libvirt] [PATCH 3/5] virDomainNetDefParseXML: suppress generation of MAC when VIR_DOMAIN_PARSE_NO_GENERATE is set

Daniel P. Berrange berrange at redhat.com
Fri Mar 18 16:37:19 UTC 2011


On Fri, Mar 18, 2011 at 10:28:34AM -0600, Eric Blake wrote:
> On 03/18/2011 10:13 AM, Daniel P. Berrange wrote:
> >> I am not completely convinced this is what we want. If domain has
> >> exactly one NIC, device-detach semantic is clear. Or if we want to
> >> allow detaching interface by PCI address - MAC shouldn't be
> >> required, because it is redundant.
> > 
> > You're missing my point here - virsh is what is broken. It should *not*
> > be trying to guess what the unique attribute the HV driver wants. Each
> > HV may have different decision about this. Applications using the method
> > virDomainDetachDevice, are required to pass the full XML description for
> > the device to be detached as it is currently shown in the guest XML
> > config.
> > 
> > virsh really needs to call virDomainDumpXML and then extract the
> > <inteface> element that it wishes to detach, rather than trying
> > to craft some partial XML description on what it thinks the HV
> > might want.
> 
> If I'm understanding correctly: In other words, we can still do some
> smarts where partial info from the user is turned into the right
> interface, but the smarts should live in virsh not the drivers.  That
> is, virsh is the one that should say dumpxml only gave one device so
> that's the one to delete, vs. dumpxml gave two devices, so some
> additional argument (be it --mac, --address, or something else) better
> be present and unambiguously match one of the two devices.

Yes, that's pretty much what I meant.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list