Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu

[Avi Kivity <avi@redhat.com>]

On 11/05/2009 06:19 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
>> No, of course not, I use qemu from the command line and would benefit 
>> from -net bridge.  My badly-conveyed objection is that qemu should 
>> not take a system management role (and enforce system-wide policies) 
>> but leave that to system management tools.
>
> I do not consider this system management functional no more than I see 
> providing a global configuration file as system management 
> functional.  They are both mechanisms.  The ACL file is a mechanism 
> just like VNC sasl ACLs are a mechanism.

I meant system as in outside the scope of a single VM.  VNC 
authentication is for a single VM.  Determining who is allowed to bridge 
where is system-wide functionality.

>
> However, I think you're wrong to think of that as a policy.  I've seen 
> many exotic network configurations over the years and I've never seen 
> anyone do anything other than that with a tap device.  It really 
> doesn't make sense to do anything more than that.

guest-specific ebtables rules
traffic control / QoS
statistics on the tap interface
vlan encapsulation
selinux labelling (if that makes sense)

>
>>> I strongly disagree with the way you separate users who use 
>>> management software from people who invoke qemu directly.  libvirt 
>>> and virt-manager are existence proofs that management software 
>>> heavily relies on the defaults and mechanisms we establish within qemu. 
>>
>> So you say, if someone makes a wrong decision, we should fix it by 
>> making the decision ourselves?
>>
>> -net bridge will only dig them deeper into qemu defaults.
>
> I'm suggesting we should get off our ivory tower claiming that 
> management tools should do a better job than they are today and 
> proactively make it easier for them to do the right thing.  We've 
> always touted the improvement of security that qemu/kvm bridges 
> because it allows a guest to run as an unprivileged user.  But this is 
> chart-ware because it's simply not the case today.

Fine, but fix it where it's broken, not in qemu.  Configuring a tap is 
not rocket science, it's just 200 lines.

>>> We can say all we want about how management software should do 
>>> things but the best way is to make it easy for them to do the right 
>>> thing.
>>
>> Except it's not the right thing, at least not completely.  Creating 
>> the tap and attaching it to a bridge is just a part of configuring 
>> networking.  You're making it easy to do that part and impossible to 
>> do the rest.
>
> What is impossible to do with -net bridge?  Certainly, you can still 
> capture the network interface very easily.  You can also still program 
> ebtables rules as it's trivial to discover the name of the network 
> device.

How, through the qemu monitor?

>>
>> Perhaps the same patchset, but to libvirt-devel, would be more useful 
>> since they can then add any extra features without burdening qemu.
>
> Except why limit this functionality to libvirt when it's useful to all 
> management tools?
>

Because each will need to do something slightly different.

-- 
error compiling committee.c: too many arguments to function