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