[libvirt] Per user preference file
Hi all, Had a thought the other night, about a possible approach to having a "per user" libvirt preferences file. How about, in the user's home directory, we have a single text file, say ".libvirt-prefs", structured something like this: [common] default_uri = qemu+ssh://somehost/system default_socket = /path/to/somewhere-socket default_session_type = system tls_client_cert = /path/to/somewhere.cert tls_client_key = /path/to/somewhere.key log_file=/path/to/logfile.log some_other_preference=value [gtk-vnc] tls_client_cert = /path/that/overrides/the/common/section/if/present/somefile.cert tls_client_key = /path/that/overrides/the/common/section/if/present/somefile.key [virt-viewer] more_overrides=/value/foo The suggestion being, that we have a [common] section with preferences that general libvirt client apps can use (ie virsh). But also allowing other libvirt client apps (ie virt-viewer), to store overrides to that. Just thinking it would be useful to have these things in one place, so sensible defaults can be set once (ie for TLS certs), and things will then "automagically" use them. + Justin
于 2010年11月11日 08:14, Justin Clift 写道:
Hi all,
Had a thought the other night, about a possible approach to having a "per user" libvirt preferences file.
How about, in the user's home directory, we have a single text file, say ".libvirt-prefs", structured something like this:
[common] default_uri = qemu+ssh://somehost/system default_socket = /path/to/somewhere-socket default_session_type = system tls_client_cert = /path/to/somewhere.cert tls_client_key = /path/to/somewhere.key log_file=/path/to/logfile.log some_other_preference=value
[gtk-vnc] tls_client_cert = /path/that/overrides/the/common/section/if/present/somefile.cert tls_client_key = /path/that/overrides/the/common/section/if/present/somefile.key
[virt-viewer] more_overrides=/value/foo
The suggestion being, that we have a [common] section with preferences that general libvirt client apps can use (ie virsh). But also allowing other libvirt client apps (ie virt-viewer), to store overrides to that.
Just thinking it would be useful to have these things in one place, so sensible defaults can be set once (ie for TLS certs), and things will then "automagically" use them.
the "tls_client_cert" and "tls_client_key' are useful it will allow user put the cert and key files where he wants. For a non-root priviledge, could not get a system session, so "default_session_type" is meaningless, and actually you already specified it in "default_uri". :-) it will be convenient for user who doesn't want to always input characters. However, think there are not many configurable preferences currently for the clients. Anyway, I think it's a good idea. - Osier
+ Justin
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 11/11/2010, at 4:31 PM, Osier Yang wrote:
the "tls_client_cert" and "tls_client_key' are useful it will allow user put the cert and key files where he wants.
Yeah, they're just suggestions for things I could think of at the time. :) I've previously found it annoying that virsh doesn't support "user preference settings" for things (ie logging verbosity, other stuff). So having a preference system of some sort would be helpful.
For a non-root priviledge, could not get a system session, so "default_session_type" is meaningless
Actually, no. People recently seem to be looking at having libvirtd run as a non-root user. Some parts of that I'm not sure will work easily, but if it can be managed, then "system" type sessions for users would be useful.
and actually you already specified it in "default_uri". :-)
Yeah, just trying to show key = value parameters. :)
it will be convenient for user who doesn't want to always input characters. However, think there are not many configurable preferences currently for the clients.
Yeah. We don't seem to add preferences, to virsh at least, unless they're 100% critical, because it means they need to be added to the command line. "virsh -d 5 ... " style. And no-one's gotten around to writing up the code for preferences. :)
On Thu, Nov 11, 2010 at 11:14:09AM +1100, Justin Clift wrote:
Hi all,
Had a thought the other night, about a possible approach to having a "per user" libvirt preferences file.
How about, in the user's home directory, we have a single text file, say ".libvirt-prefs", structured something like this:
[common] default_uri = qemu+ssh://somehost/system default_socket = /path/to/somewhere-socket default_session_type = system tls_client_cert = /path/to/somewhere.cert tls_client_key = /path/to/somewhere.key log_file=/path/to/logfile.log some_other_preference=value
This is fine, except that default_session_type and default_socket are already encoded as part of the URI.
[gtk-vnc] tls_client_cert = /path/that/overrides/the/common/section/if/present/somefile.cert tls_client_key = /path/that/overrides/the/common/section/if/present/somefile.key
gtk-vnc is not tied to libvirt and so won't be using libvirt to store its preferences. Setting defaults for the library is really an application level problem, so it'd be part of say virt-viewer preferences
[virt-viewer] more_overrides=/value/foo
This isn't really something virt-viewer wants to use either. As a graphical desktop application, any preferences will belong in GConf / GSettings, as does virt-manager. So I'd really just call this ~/.virshrc Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Nov 11, 2010 at 10:33:57AM +0000, Daniel P. Berrange wrote:
On Thu, Nov 11, 2010 at 11:14:09AM +1100, Justin Clift wrote:
Hi all,
Had a thought the other night, about a possible approach to having a "per user" libvirt preferences file.
How about, in the user's home directory, we have a single text file, say ".libvirt-prefs", structured something like this:
[common] default_uri = qemu+ssh://somehost/system default_socket = /path/to/somewhere-socket default_session_type = system tls_client_cert = /path/to/somewhere.cert tls_client_key = /path/to/somewhere.key log_file=/path/to/logfile.log some_other_preference=value
This is fine, except that default_session_type and default_socket are already encoded as part of the URI.
Oh actually, we need to be able to specify TLS paths in the URI as well, so if we add that ability to the URI, then we don't need the config params for tls either. So we really come down to a config file with the URI and a logfile. Is this any better than just setting LIBVIRT_DEFUALT_URI and LIBVIRT_LOG_OUTPUTS in $HOME/.bashrc, which *will* actually impact any application using libvirt.so without needing any code changes on those apps Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On 11/11/2010, at 10:21 PM, Daniel P. Berrange wrote: <snip>
So we really come down to a config file with the URI and a logfile. Is this any better than just setting LIBVIRT_DEFUALT_URI and LIBVIRT_LOG_OUTPUTS in $HOME/.bashrc, which *will* actually impact any application using libvirt.so without needing any code changes on those apps
Having a preference file, per user, gives us a known place to put (and suggest) further preferences. Ages ago, when I was adding options to virsh like "--details" for the pool-list and vol-list commands, I really wanted a way to change the default behaviour for some commands. For example, two defaults I'd like to be able to change are: + having the *-list commands use "--all" by default + list --> list --all + net-list --> net-list --all + pool-list --> pool-list --all + vol-list --> vol-list --all Changing the virsh wide default though, instead of having it be a user preference, would likely break existing scripting. Not a go-er. :) + having the pool-list and vol-list commands also use "--details" by default + pool-list --> pool-list --details + vol-list --> vol-list --details Again, changing this in virsh without it being a user preference would just break existing stuff. Didn't/couldn't do the above, because we have no existing spot to store user preferences. If we did, then the above could happen, and I'm "pretty sure" other people would also tweak their often used stuff too. :) Of course, we could probably do it with environment variables. Seems like a non-optimal direction to take though, if we think there could be a bunch of things added over time.
On 11/11/2010, at 9:33 PM, Daniel P. Berrange wrote: <snip>
[virt-viewer] more_overrides=/value/foo
This isn't really something virt-viewer wants to use either. As a graphical desktop application, any preferences will belong in GConf / GSettings, as does virt-manager.
So I'd really just call this ~/.virshrc
That would work, but we kind of miss the lead in (opportunity) to provide a way for multiple apps to share "common" settings (intelligently). Still, it'd be a start. :)
On Thu, Nov 11, 2010 at 10:21:32PM +1100, Justin Clift wrote:
On 11/11/2010, at 9:33 PM, Daniel P. Berrange wrote: <snip>
[virt-viewer] more_overrides=/value/foo
This isn't really something virt-viewer wants to use either. As a graphical desktop application, any preferences will belong in GConf / GSettings, as does virt-manager.
So I'd really just call this ~/.virshrc
That would work, but we kind of miss the lead in (opportunity) to provide a way for multiple apps to share "common" settings (intelligently).
The problem is that the multiple apps are written in several different programming languages. Even if we decided on a config file format (eg. "let's use INI format") you'd still need to find libraries which worked the same across all languages including all the details like whitespace, quoting and escaping. That's "just" the technical problem. There's a social problem too. For guestfish, as it happens, I am looking around for a decent config file format as well, but I need a global (/etc) config and a per-user config file, and I'd kind of prefer it if it was called /etc/guestfish.conf because that makes it easier for users to find, oh and we don't want to have a hard dependency on libvirt, or anything that isn't a small, C library that is already available on Pardus, Gentoo, Debian and MeeGo. (Did I mention the library needs OCaml bindings for virt-top etc? And virt-top has a config file already, so it'd better be compatible!) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
I would agree with Dan that either this is libvirt-only, or it's a general virt-tools preferences file. However for virt-tools, good luck on getting everyone's agreement on how it should work (it's a serious technical as well as social challenge). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
participants (4)
-
Daniel P. Berrange -
Justin Clift -
Osier Yang -
Richard W.M. Jones