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

Daniel P. Berrange berrange at redhat.com
Tue Jul 19 15:09:30 UTC 2011

On Tue, Jul 19, 2011 at 08:54:59AM -0600, Eric Blake wrote:
> On 07/19/2011 08:47 AM, Richard W.M. Jones wrote:
> >On Tue, Jul 19, 2011 at 10:46:49AM -0400, Cole Robinson wrote:
> >>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.
> >
> >You can't do that without getting into trademark issues.  The icon
> >that is displayed must have come from precisely the same guest.
> >
> >The icons are not large anyhow.
> >
> >One thing I meant to ask about Dan's proposal:
> >
> >>>  $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
> >
> >Do we need the connection URI?  Isn't the dom UUID unique enough?
> Technically, a UUID should be unique enough.  But right now, libvirt
> does not enforce cross-connection uniqueness, and it is possible to
> reuse a uuid value across hypervisors (even though such reuse
> violates the definition of uuid), so using $CONN_URI protects us
> from that potential for reuse.  Besides, we already use $CONN_URI in
> the paths of other files, such as per-domain logs (for example,
> /var/log/libvirt/$CONN_URI/$DOMAIN_NAME.log), so it's a reasonable
> proposal to keep that naming hierarchy elsewhere.

Actually, using  dom UUID alone would be desirable here, so that
when a guest is migrated, you don't need to re-extract the images.

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

More information about the libvir-list mailing list