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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list