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

[Cole Robinson]

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.

- Cole

> 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
>