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 :| _______________________________________________ virt-tools-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-tools-list
