[Top][All Lists]

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

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

From: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Thu, 5 Nov 2009 16:29:34 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

Avi Kivity wrote:
> On 11/05/2009 04:50 PM, Anthony Liguori wrote:
> Bridged network configuration is painful now, but only for a handful of 
> users (us developers).

I have to disagree.  Although I'm a developer too, if I put my system
administrator hat on for a moment...

I found the bridged network configuration annoying.  I gave up trying
to be dynamic and just preallocated user-owned static tap devices in
the system interface list for every VM that my users want to run
(which means they have to ask me when they want more VMs on the
bridges).  I still had to configure the servers' bridges and
interfaces for all that manually, and bind all the tap devices to
bridges even when not in use.  The iptables wasn't pretty either.

I think this qemu mode to call out to an external program for the
interface is an simple, useful change which will make dynamic
interfaces easier.

You _can_ do the same thing with a management program or script.  At
first (like you) I was wondering why the helper is needed since you
can do it so easily with a wrapper around QEMU, and then I realised:

Because it's very hard to write a wrapper script which correctly
matches QEMU options and inserts an "fd=..." option in the right
place, for all different QEMU/KVM versions.

If you're using a management program with it's own configuration with
generates all the QEMU command options anyway, there's no problem.

But if you want useful networking, while specifying ordinary QEMU
options e.g. from a command line or simple script... then it's
difficult and fragile to make a script wrapper for that without
Anthony's change.

Btw, I'll probably replace the helper program with something which
does the permission checks and interface setup in a different way, but
it's still a good pattern to call one.

> For the vast majority it is handled behind their 
> back by management, which has to deal with a bunch of privileged stuff 
> anyway (assigned LVM volumes, assigned pci and usb devices, setting up 
> the bridge, large pages, guest priorities).  Why are we adding code to 
> benefit so few people, many of whom don't really use qemu as users?

Perhaps qemu should call out to helper programs to request access to
block devices, pci and usb devices, priorities and access to large
pages too?

It would at least be consistent if every "request for a system
resource which might need permission" could be replaced by
"user-configurable command for request for a system resouce".

Anyway, in my experience using QEMU and KVM, networking is the only
complicated bit of system configuration.  Everything else is just
usespace - I've never felt the need used LVM volumes, pass-through PCI
and USB devices, or guest priorities.  It's all VNC servers, emulated
USB mice, and disk images files, none of which needs system configuration.

Networking is unusual in being the only system service that virtually
every guest needs, so I guess my experience applies to most users who
are using QEMU/KVM directly.

-- Jamie

reply via email to

[Prev in Thread] Current Thread [Next in Thread]