Prevent virt-manager from chowning ISOs

[Sudhir Khanger]

Hello,

VirtualBox when run as a userspace tool would not require root
password, not chown ISOs and VMs are created with regular user
privileges. Virt-Manager on the other hand requires root password,
changes ISO's owner to either qemu or root and VMs also created under
root user. Personally using root for such a trivial task is not
prefered. I can start Virt-Manager without root password using this
guide [1] but other two doesn't seem to be possible. Anyone know
anything about the issues I am facing.

[1] https://ask.fedoraproject.org/en/question/49928/install-fedora-vm-with-up...

-- 
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen

[Scott Dowdle]

Greetings,

----- Original Message from Sudhir Khanger -----
>  VirtualBox when run as a userspace tool would not require root
>  password, not chown ISOs and VMs are created with regular user
>  privileges. Virt-Manager on the other hand requires root password,
>  changes ISO's owner to either qemu or root and VMs also created under
>  root user. Personally using root for such a trivial task is not
>  prefered. I can start Virt-Manager without root password using this
>  guide [1] but other two doesn't seem to be possible. Anyone know
>  anything about the issues I am facing.
>  
>  [1]
>  https://ask.fedoraproject.org/en/question/49928/install-fedora-vm-with-up... 
I didn't see anything at that URL that about how to start Virt-Manager without the
root password.

Oddly, I don't need the root password to start virt-manager.  My user was setup as an
"Adminstrator" (aka, the account has sudo access) so I only need to type in my
user password.  That's how most people do it.

TYL,
-- 
Scott Dowdle
704 Church Street
Belgrade, MT 59714
[phone] [home]
[phone] [work]

[Cole Robinson]

On 07/12/2014 11:20 PM, Sudhir Khanger wrote:
>  Hello,
>  
>  VirtualBox when run as a userspace tool would not require root
>  password, not chown ISOs and VMs are created with regular user
>  privileges. Virt-Manager on the other hand requires root password,
>  changes ISO's owner to either qemu or root and VMs also created under
>  root user. Personally using root for such a trivial task is not
>  prefered. I can start Virt-Manager without root password using this
>  guide [1] but other two doesn't seem to be possible. Anyone know
>  anything about the issues I am facing.
>  
I wouldn't exactly describe virtualization management as a trivial task :)

virt-manager defaults to using the libvirt URI qemu:///system, which connects
to the system libvirtd instance, which runs as root. What you're requesting is
basically the qemu:///session URI, which auto-launches a libvirtd instance
running as your regular user, runs VMs as your user, and defaults to storing
images in $HOME/VirtualMachines. You can use that like 'virt-manager --connect
qemu:///session' or File->Add Connection->QEMU/KVM user session in new enough
virt-manager.

There's a lot of reasons why virt-manager doesn't default to qemu:///session,
here's the two big ones:

- Networking: historically the only real networking mode available with
qemu:///session is usermode networking, which has limited functionality
compared to what some users will expect by default. See
http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29

- Historical reasons: when virt-manager first grew qemu/kvm support,
qemu:///session couldn't even be used for actual KVM acceleration, which would
have made it a poor default. Nowadays that is no longer true, but to change
the default would require serious work: either lots of documentation and
warnings to explain to users the subtle differences between qemu:///system and
qemu:///session and importing of pre-existing VMs, or lots of work to try and
narrow the functionality gap between the two methods.

The chown'ing and selinux labeling of any storage attached to a VM is a
libvirt security feature that's not virt-manager's explicit doing. It has
historically been quite a pain WRT install media as you've likely discovered.
I've had a long standing todo item to fully investigate the issues that people
hit and try and come up with a solution, whether it's libvirt fixes,
virt-manager fixes, or just better error messages. But I haven't gotten around
to it yet.

- Cole

[Sudhir Khanger]

On Sunday, July 27, 2014 03:56:12 PM Cole Robinson wrote:
>  virt-manager --connect
>  qemu:///session 
Thanks Cole for the explanation. User session is what I wanted. I will go 
ahead and read more about it.

-- 
Sudhir Khanger,
http://sudhirkhanger.com
http://github.com/donniezazen

[Richard W.M. Jones]

On Sun, Jul 27, 2014 at 03:56:12PM -0400, Cole Robinson wrote:
>  - Networking: historically the only real networking mode available
> with
>  qemu:///session is usermode networking, which has limited functionality
>  compared to what some users will expect by default. See
>  http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29 
Sorry, just catching up on this list.

"historically" .. meaning there is something better than SLIRP
available for non-root users now?

>  The chown'ing and selinux labeling of any storage attached to a
> VM
>  is a libvirt security feature that's not virt-manager's explicit
>  doing. It has historically been quite a pain WRT install media as
>  you've likely discovered.  I've had a long standing todo item to
>  fully investigate the issues that people hit and try and come up
>  with a solution, whether it's libvirt fixes, virt-manager fixes, or
>  just better error messages. But I haven't gotten around to it yet. 
The central pain point for me is around NFS.  Put a disk image on NFS,
and libguestfs breaks (because of labelling).  You have to use 'export
LIBGUESTFS_BACKEND=direct' to work around it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Cole Robinson]

On 09/30/2014 09:38 AM, Richard W.M. Jones wrote:
>  On Sun, Jul 27, 2014 at 03:56:12PM -0400, Cole Robinson wrote:
> > - Networking: historically the only real networking mode available with
> > qemu:///session is usermode networking, which has limited functionality
> > compared to what some users will expect by default. See
> > http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
>  
>  Sorry, just catching up on this list.
>  
>  "historically" .. meaning there is something better than SLIRP
>  available for non-root users now?
>   
You can use the setuid qemu-bridge-helper to let a non-root qemu use virbr0
provided by the default network. That's what boxes does now. But you have to
hope that virbr0 is set up correctly, since non-root libvirtd can't manage it.

- Cole

[Richard W.M. Jones]

On Tue, Sep 30, 2014 at 09:42:44AM -0400, Cole Robinson wrote:
>  On 09/30/2014 09:38 AM, Richard W.M. Jones wrote:
>  > On Sun, Jul 27, 2014 at 03:56:12PM -0400, Cole Robinson wrote:
>  >> - Networking: historically the only real networking mode available with
>  >> qemu:///session is usermode networking, which has limited functionality
>  >> compared to what some users will expect by default. See
>  >> http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
>  > 
>  > Sorry, just catching up on this list.
>  > 
>  > "historically" .. meaning there is something better than SLIRP
>  > available for non-root users now?
>  > 
>
>  You can use the setuid qemu-bridge-helper to let a non-root qemu use
>  virbr0 provided by the default network. That's what boxes does
>  now. But you have to hope that virbr0 is set up correctly, since
>  non-root libvirtd can't manage it. 
OK .. be nice to get this working some time with libguestfs, for those
libguestfs applications that use the (not-enabled-by-default) network
support.  eg. virt-builder, virt-customize, virt-rescue --network.

Especially having 'ping' work would be a major breakthrough :-)

When you say "virbr0 is set up correctly" does that mean virbr0 is set
up using the 192.168.122 network, or just that virbr0 exists and is
working in some respect?  Most of my machines have virbr0 bridged to
the physical ethernet device.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Cole Robinson]

On 09/30/2014 09:50 AM, Richard W.M. Jones wrote:
>  On Tue, Sep 30, 2014 at 09:42:44AM -0400, Cole Robinson wrote:
> > On 09/30/2014 09:38 AM, Richard W.M. Jones wrote:
> >> On Sun, Jul 27, 2014 at 03:56:12PM -0400, Cole Robinson wrote:
> >>> - Networking: historically the only real networking mode available with
> >>> qemu:///session is usermode networking, which has limited functionality
> >>> compared to what some users will expect by default. See
> >>> http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29
> >>
> >> Sorry, just catching up on this list.
> >>
> >> "historically" .. meaning there is something better than SLIRP
> >> available for non-root users now?
> >>
> >
> > You can use the setuid qemu-bridge-helper to let a non-root qemu use
> > virbr0 provided by the default network. That's what boxes does
> > now. But you have to hope that virbr0 is set up correctly, since
> > non-root libvirtd can't manage it.
>  
>  OK .. be nice to get this working some time with libguestfs, for those
>  libguestfs applications that use the (not-enabled-by-default) network
>  support.  eg. virt-builder, virt-customize, virt-rescue --network.
>  
>  Especially having 'ping' work would be a major breakthrough :-)
>  
>  When you say "virbr0 is set up correctly" does that mean virbr0 is set
>  up using the 192.168.122 network, or just that virbr0 exists and is
>  working in some respect?  Most of my machines have virbr0 bridged to
>  the physical ethernet device. 
I just meant 'virbr0 exists'. Which requires libvirt-daemon-config-network to
be installed, the 'default' network to be running and set to autostart.

- Cole

[Richard W.M. Jones]

On Tue, Sep 30, 2014 at 10:04:51AM -0400, Cole Robinson wrote:
>  I just meant 'virbr0 exists'. Which requires
> libvirt-daemon-config-network to
>  be installed, the 'default' network to be running and set to autostart. 
Thanks - I have filed an RFE bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1148012

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/