6:14 p.m.
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
11:31 p.m.
于 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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
2:15 a.m.
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. :)
4:33 a.m.
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 :|
5:21 a.m.
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 :|
5:32 a.m.
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.
5:21 a.m.
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. :)
6:13 a.m.
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
4:53 a.m.
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
5125
days inactive
5125
days old
8 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Justin Clift -
Osier Yang -
Richard W.M. Jones