[libvirt] [virt-tools-list] [PATCH virt-manager v4] Add inspection to virt-manager

[Richard W.M. Jones]

On Tue, Jul 19, 2011 at 03:40:53PM +0100, Daniel P. Berrange wrote:
> On Tue, Jul 19, 2011 at 10:17:02AM -0400, Cole Robinson wrote:
> > On 07/19/2011 03:49 AM, Richard W.M. Jones wrote:
> > > On Mon, Jul 18, 2011 at 05:41:00PM -0400, Cole Robinson wrote:
> > >> On 07/18/2011 02:53 PM, Richard W.M. Jones wrote:
> > >>> This updates 1/4 with the fixes you suggested.  Also, all check-pylint
> > >>> warnings and errors have been fixed.
> > >>>
> > >>> Rich.
> > >>>
> > >>
> > >> Thanks! Pushed the series.
> > > 
> > > In reply to your comment on IRC:
> > > 
> > > crobinso> rjones: so in the default usage of virt-manager in fedora,
> > >                   the guest inspection probably won't work since we
> > >                   save disk images in /var/lib/libvirt/images/, which
> > >                   regular user doesn't have access to.
> > > crobinso> rjones: that's not entirely clear from feature page.
> > > crobinso> rjones: I'm thinking of adding a disk path access check in
> > >                   the inspection thread, to avoid flooding the logs
> > >                   with errors if we can't even read the disk
> > >                   image. that should be safe to do?
> > > 
> > > I always run virt-manager as root (or from sudo) so this hasn't been
> > > an issue.  What user does virt-manager run as normally?
> > >
> > 
> > I think most common usage is just running virt-manager as the logged in
> > user, using policykit to authenticate the libvirt connection so the rest
> > of the app doesn't have root privs.
> > 
> > > AFAICT if there's no access to the disks, then the call to either
> > > g.add_drive_opts or g.launch will throw an exception.  But the
> > > inspection._vmseen hash will mean this will only happen once per
> > > domain per run of virt-manager.
> > > 
> > > On an unrelated note: I think we need to cache inspection between runs
> > > of virt-manager.  Does virt-manager currently store permanent state (I
> > > assume it must do - ie. list of connections), and where?
> > > 
> > 
> > We store config like that in gconf, though I don't think sticking
> > largish data like list of applications or a png in there is a good idea.
> > hostname + os info could be cached, though ideally the latter would be
> > stored in libvirt XML at some point.
> 
> Agreed, it would be desirable to cache the PNGs in $HOME/.virt-manager
> though, perhaps as
> 
>   $HOME/.virt-manager/icons/$CONN_URI/$DOMAIN_UUID
> 
> To avoid growing without bound, probably want to have virt-manager
> purge files in that directory on startup, if the PNG is older than
> 3 months and the associated connection or domain no longer exists.
> ie don't immediately purge them, since a user might later re-add a
> connection or re-create a VM.
> 
> Another thought though is that we've also got some work going on a
> little plugin for gnome-shell to capture & display screenshots of
> VMs. It might be nice for virt-manager to take advantage of this
> too, while also the shell plugin might like the icon image. So
> perhaps we should declare a standard location for storing assets
> related to a VM, which are expensive to extract/fetch.
> 
>  $HOME/.local/libvirt/$CONN_URI/$DOMAIN_UUID/screenshot.png
>  $HOME/.local/libvirt/$CONN_URI/$DOMAIN_UUID/icon.png
>  $HOME/.local/libvirt/$CONN_URI/$DOMAIN_UUID/osinfo.json
> 
> or something like that

+1

CC-ing to libvir-list.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora