[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: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu
Date: Sat, 07 Nov 2009 08:04:01 -0600
User-agent: Thunderbird (X11/20090825)

Avi Kivity wrote:
Running qemu directly from the command line is absolutely an important use case.

Where does this requirement come from?

For most of qemu's lifetime, this was the only option. The current graphical front ends only support a subset of qemu's features and qemu's target architecture types. qemu is more than just KVM accelerated x86 guests.

I also disagree that only developers are interested in using qemu directly. There are a lot of power users who also use qemu directly.

A desktop user should not need things like libvirt and virt-manager.

virt-mananger is miles ahead of where you're aiming.

I'd like to a proper same-process graphical UI client. But I don't think this list is the place to create it. I don't think we have either the skills or the patience; also there's room for more than one. We should focus on making it easy to write one; that involves exporting the display surface in an embeddable non-vnc way and making everything controllable via QObjects (perhaps through the monitor, perhaps through bindings for scripting languages.

If it cannot be fixed in the kernel, we'll have to work around it in userspace. We can introduce our own spawn() function that works by fork()'ing very early and listening on a socketpair. This will sit reading from the socket waiting for commands to exec. Using a unix socket, we can pass fds that get inherited which we can't do with system().

Or we can admit to ourselves that qemu is too complex to be directly controlled by a user. It's good to have an easy to use command line for developers and power users; I'd welcome -net bridge as one of them. But we shouldn't try to invent access control systems or install suid helpers. Mainstream use needs to involve some management agent which does authentication and privileged configuration (it was already established that the the hotplug equivalent of -net bridge is racy if any configuration is required).

I disagree about the role a management app should play. For a casual user, a management app really should not be needed.


Anthony Liguori

reply via email to

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