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

Re: [libvirt] configuring a disconnected <interface>



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.

Dan.


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