Re: [libvirt] [virt-tools-list] [PATCH virt-manager v4] Add inspection to virt-manager
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? 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
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. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
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. 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 :|
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Richard W.M. Jones