Re: [libvirt] configuring a disconnected <interface>
On 07/03/2013 05:27 AM, Daniel P. Berrange wrote:
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.
Actually we did ask for that (basically, for the ability to change the
frontend of a network device without changing the backend), and stefanha
kindly produced a patch that *kind of* did it, but due to internal
limitations of qemu, it wasn't fully functional; it worked for some
limited cases but not for everything. If I recall correctly, the split
between frontend and backend in qemu wasn't as clear cut and total as
the commands led us to believe, and even once Stefan's patch was in
place, switching from tap to macvtap (or vice versa) still didn't work
properly (am I remembering that correctly, Stefan?).