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. - Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list