[ale] Fw: VirtualBox

[Brian Pitts]

On 12/22/2010 08:17 AM, Derek Atkins wrote:
> Joseph Scalia <jscalia at redhat.com> writes:
> 
>> Jumping in a bit late in the thread... Was there a reason you did not
>> want to use Virt-Manager?
> 
> Last I checked, virt-manager requires running on the local machine.  I
> have remote users and want to give access to the console of particular
> VMs remotely.  I don't want to allow them (let alone require them) to
> ssh into my VM host box.

So you want to allow and deny access to certain virual machines for
certain users? With libvirt, there are two kinds of connections- the
system daemon and the per-user daemon. I don't know of any way to do
access control within a daemon. You'd need to use a higher-level
management tool on top of libvirt for that. If two different users
connect to qemu:///system they'll see the same virtual machines and have
equal rights to add virtual hardware, reboot them, etc. However, I
suppose you could get access control by using the per-user sessions. Two
different users can connect to qemu:///session and they won't see each
others virtual machines. This also might be a good fit for you because
when you connect to qemu:///system you can do things that require root
privileges like defining new virtual networks and storage pools, but
when you connect to qemu:///session you cannot. Note that using per-user
sessions does require that your remote users have accounts on your server.

> 
> I'm not sure what you mean by "remote libvirt calls" in this context.  I
> was under the impression that virt-manager was a Gtk App that ran locally,
> similar to vmware workstation (or player).  Is my impression incorrect?

As others have said, it's a gui tool that connect to your local machine
(e.g. qemu:///system or qemu:///session) or to remote machines using ssh
(e.g. qemu+ssh://root@example.com/system or
qemu+ssh://brian@example.com/session) or tls.

Your remote users would need to be running an OS that virt-manager runs
on; linux is the only one where it's easy.

-- 
All the best,
Brian Pitts