[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: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Thu, 05 Nov 2009 18:33:27 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4

On 11/05/2009 06:25 PM, Anthony Liguori wrote:
That's not the case today, even with virt-manager.

I'm not going to pick on any particular tool, but kvm absolutely has a reputation of being difficult to use compared to other virtualization software out there. Nothing else requires modifying configuration files just to get a guest with bridged networking.

The two management tools I'm familiar with (virt-manager and RHEV-M) don't need configuration files. It's true that virt-manager does NAT, not full bridging, but -net bridge doesn't fix that.

I think we absolutely have to think about the full stack and how all the pieces interact. There are definitely problems in the stack right now. Security is the one I'm trying to address in this series. If you cannot launch a reasonable configured qemu from the command line as an unprivileged user, there's really no hope that we can expect a management tool to do that.

I'm almost offended on Dan's behalf.

We'll I guess it's about perspectives then. I don't see the fact that libvirt runs qemu as root as a libvirt deficiency. I see it as a qemu deficiency.

I don't understand why.  It's pretty easy to run qemu as non-root.

I suspect there isn't a management tool out there that does the right thing today.

I suspected as much based on how strongly you were advocating this.

You're a little too suspicious. RHEV-H has nothing to do with my opposition to -net bridge.

I think my point still stands though, there's an awful lot of management software out there that gets it wrong. It's great that you guys got it right but so far, the majority of users are not using qemu through RHEV-M so I still think we have a problem.

I'm worrying that we're transforming one problem into two different ones. Expanding the scope of qemu, and making it more difficult to use advanced networking functionality.

error compiling committee.c: too many arguments to function

reply via email to

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