Re: configuring a disconnected <interface>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 03, 2013 at 09:39:57AM +0300, Dan Kenigsberg wrote:
> On Tue, Jul 02, 2013 at 05:32:20PM -0400, Laine Stump wrote:
> > On 07/02/2013 04:07 PM, Dan Kenigsberg wrote:
> > > On Mon, Jun 24, 2013 at 11:22:16AM +0100, Daniel P. Berrange wrote:
> > >> On Sun, Jun 23, 2013 at 03:34:06PM +0300, Dan Kenigsberg wrote:
> > >>> On Fri, Jun 21, 2013 at 04:31:53AM -0500, Daniel P. Berrange wrote:
> > >>>> So I'm not inclined to support this disconnected mode.
> > >>> Disconnected mode exists in actuality. It has valid use cases in the
> > >>> virtual world as well. I would like to discuss the domxml schema for
> > >>> representing it, and then, hopefully find the menpower to implement it
> > >>> outside the core libvirt team. So please, reconsider.
> > >> The XML schema is easy enough - it is just a new  <interface type=none>.
> > >> Ideally we would want some kind of support in QEMU for this, concept
> > >> so that we don't have to have a hidden dangling tap device
> > > That would be cool indeed. It would make it possible to
> > > virDomainUpdateDevice() from a tap-based connectivity to non-tap one.
> > >
> > > Until we have something like that in qemu, would it be reasonable to
> > > implement <interface type=none> via a dangling tap? Wouldn't it be fine
> > > to limit changing type=none to type=network only to bridge-based
> > > networks?
> > 
> > Well, that *is* how virDomainUpdateDevice behaves when switching from
> > one network connection to another - if the source and destination are
> > both implemented with tap, it works, otherwise it returns
> > OPERATION_UNSUPPORTED.
> 
> My question is slightly different: it's about switching from one
> interface type (=none) to another (=network), not between two networks.
> 
> I am asking whether it would be fine to implement type=none with tap,
> given this unsupportedness.

No, it doesn't really work properly. Not all type=network configs
are based on tap devices. We need to be able to ask QEMU to remove
the netdev backend, without affecting the guest device, and then 
add in a new netdev backend.

We should have asked for this when we first did dynamic network
re-configuration, but we took the easy way out back then. We need
to fix this properly so that all possible config changes work.

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 :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]