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

[Daniel P. Berrange]

On Tue, Jul 19, 2011 at 10:46:49AM -0400, Cole Robinson wrote:
> On 07/19/2011 10:40 AM, 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
> >
> 
> Maybe we can cache the png data per detected OS value rather than per
> VM? Not sure if that collides with licensing issues, but would likely
> mean storing less data on disk.

I don't think data storage is a big issue for VM icons, in comparison
to say the disk image size, or amount of data browsers use for images.
Also, a user might customize the icon in a guest OS, so we can't
link to the OS name

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|