3:35 a.m.
Hi, all
We have some new requirements of preferences, I listed
which of them I known, and think is useful as follows:
1) for the path of x509 certificate and keys of client
The path of x509 certificate and keys of client is hard
coded in remote driver. e.g.
/* Defaults for PKI directory. */
# define LIBVIRT_PKI_DIR SYSCONFDIR "/pki"
# define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem"
# define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private
/clientkey.pem"
# define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem"
2) for default default driver and subdriver for disk image
Another requirement of new preference is default driver and subdriver
for disk images, currently we use "phy" for "driver" in virsh, and
"raw" for "subdriver" in qemu driver by default if user doesn't
specify
them, it causes bugs, though we could say to user "you should use
options --driver and --subdriver", but these two options are optional.
IMHO, the best solution for those bugs is to provide new preferences.
3) for default NIC and storage type
"Chris Phillips" raised up the requirement not long ago:
http://www.redhat.com/archives/libvirt-users/2010-November/msg00033.html
====================
Should we add these new preferences(if they are really neccessary)
in qemu.conf? or create new config file, e.g. The approch Justin
raised up an approch before:
http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
Though for Justin's approch, IMHO we'd better also to provide a
default config file, e.g. "/etc/libvirt/client.conf".
Any feedback is welcomed, thanks
- Osier
4:19 a.m.
On 01/12/2010, at 8:35 PM, Osier Yang wrote:
Should we add these new preferences(if they are really neccessary)
in qemu.conf? or create new config file, e.g. The approch Justin
raised up an approch before:
http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
Though for Justin's approch, IMHO we'd better also to provide a
default config file, e.g. "/etc/libvirt/client.conf".
Any feedback is welcomed, thanks
When thinking about this more, three levels of preference can be found in
other applications, and _might_ be the right approach for us to take as well.
1) System wide
Client preferences stored in a location that's applicable to all users.
ie: /etc/libvirt.conf or similar
We can't put it in the /etc/libvirt/ directory with the present permission
structure, because /etc/libvirt/ is not world readable. Would need to be
in a world readable location (/etc/ ?) or we could relax the perms of
/etc/libvirt/ (prob not likely).
2) Per user preference
ie: ~/.libvirt.conf or ~/.libvirt/client.conf or similar
For a user to permanently override the above system wide defaults,
in case their setup is different from everyone else on the system.
3) On the command line
ie: $ virsh --some-new-option=foo
For adhoc preference changes not to be stored in a pref file.
The other category of user preferences that I think are important, is
for the defaults of virsh. I strongly suspect people who use virsh a lot
would like to change some of it's command defaults. Specifically having
"--all" be the default for the *-list commands, having "--details"
automatically
be used for the storage list commands, and that kind of thing.
That's my thinking so far anyway. :)
Regards and best wishes,
Justin Clift
7:46 a.m.
On Wed, Dec 01, 2010 at 09:19:30PM +1100, Justin Clift wrote:
On 01/12/2010, at 8:35 PM, Osier Yang wrote:
> Should we add these new preferences(if they are really neccessary)
> in qemu.conf? or create new config file, e.g. The approch Justin
> raised up an approch before:
> http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
>
> Though for Justin's approch, IMHO we'd better also to provide a
> default config file, e.g. "/etc/libvirt/client.conf".
>
> Any feedback is welcomed, thanks
When thinking about this more, three levels of preference can be found in
other applications, and _might_ be the right approach for us to take as well.
Management of preferences belongs in application code, rather than
libvirt. Library APIs need to have standard, predictable behaviour
that apps can rely on in any deployment. We don't want that being
changed globally for all applications by config files.
Even if apps do want configuration data, we can't assume they want the
data stored in configuration files. Any current GTK application will
use GConf for any configuration, or in the future GSettings which
has pluggable backends per OS platform.
1) System wide
Client preferences stored in a location that's applicable to all users.
ie: /etc/libvirt.conf or similar
We can't put it in the /etc/libvirt/ directory with the present permission
structure, because /etc/libvirt/ is not world readable. Would need to be
in a world readable location (/etc/ ?) or we could relax the perms of
/etc/libvirt/ (prob not likely).
It is restricted because many of the files below /etc/libvirt contain
passwords and/or other sensitive data, so it can't be opened.
Regards,
Daniel
7:52 a.m.
On 02/12/2010, at 12:46 AM, Daniel P. Berrange wrote:
On Wed, Dec 01, 2010 at 09:19:30PM +1100, Justin Clift wrote:
> On 01/12/2010, at 8:35 PM, Osier Yang wrote:
>> Should we add these new preferences(if they are really neccessary)
>> in qemu.conf? or create new config file, e.g. The approch Justin
>> raised up an approch before:
>> http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
>>
>> Though for Justin's approch, IMHO we'd better also to provide a
>> default config file, e.g. "/etc/libvirt/client.conf".
>>
>> Any feedback is welcomed, thanks
>
> When thinking about this more, three levels of preference can be found in
> other applications, and _might_ be the right approach for us to take as well.
Management of preferences belongs in application code, rather than
libvirt. Library APIs need to have standard, predictable behaviour
that apps can rely on in any deployment. We don't want that being
changed globally for all applications by config files.
Even if apps do want configuration data, we can't assume they want the
data stored in configuration files. Any current GTK application will
use GConf for any configuration, or in the future GSettings which
has pluggable backends per OS platform.
Good point. Its a per client thing, and each client would store the
preferences in the way that makes best sense for it.
GConf for GTK things, something else for KDE, and a virsh appropriate
approach for that if/when we get around to it.
4:26 a.m.
On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote:
Hi, all
We have some new requirements of preferences, I listed
which of them I known, and think is useful as follows:
1) for the path of x509 certificate and keys of client
The path of x509 certificate and keys of client is hard
coded in remote driver. e.g.
/* Defaults for PKI directory. */
# define LIBVIRT_PKI_DIR SYSCONFDIR "/pki"
# define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem"
# define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private
/clientkey.pem"
# define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem"
We can't assume one set of certs/keys is suitable for all
URIs, so making this a preference setting doesn't help. There
needs to be a parameter in the URI to specify a cert/key name
to override the defaults on a per-connection basis
2) for default default driver and subdriver for disk image
Another requirement of new preference is default driver and subdriver
for disk images, currently we use "phy" for "driver" in virsh, and
"raw" for "subdriver" in qemu driver by default if user doesn't
specify
them, it causes bugs, though we could say to user "you should use
options --driver and --subdriver", but these two options are optional.
IMHO, the best solution for those bugs is to provide new preferences.
virsh is broken here. It shouldn't be setting the driver if the
user doesn't specify it. The libvirt hypervisor specific drivers
know the correct defaults if omitted, so virsh shouldn't try to
guess this (wrongly) itself.
3) for default NIC and storage type
"Chris Phillips" raised up the requirement not long ago:
http://www.redhat.com/archives/libvirt-users/2010-November/msg00033.html
This doesn't belong in libvirt. See my reply in that thread.
====================
Should we add these new preferences(if they are really neccessary)
in qemu.conf? or create new config file, e.g. The approch Justin
raised up an approch before:
http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
Though for Justin's approch, IMHO we'd better also to provide a
default config file, e.g. "/etc/libvirt/client.conf".
Library APIs like libvirt shouldn't really rely on preference files,
because such a file would silently change behaviour in ways that
applications using the API may not expect. ie the preference
may work nicely for one app/user of libvirt, but not for another
app. Environment variables would cause similar problems too. Anything
that needs to be configured should be configurable via the APIs or
XML.
Regards,
Daniel
9:45 a.m.
于 2010年12月01日 18:26, Daniel P. Berrange 写道:
On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote:
> Hi, all
>
> We have some new requirements of preferences, I listed
> which of them I known, and think is useful as follows:
>
> 1) for the path of x509 certificate and keys of client
>
> The path of x509 certificate and keys of client is hard
> coded in remote driver. e.g.
>
> /* Defaults for PKI directory. */
> # define LIBVIRT_PKI_DIR SYSCONFDIR "/pki"
> # define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem"
> # define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private
> /clientkey.pem"
> # define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem"
We can't assume one set of certs/keys is suitable for all
URIs, so making this a preference setting doesn't help. There
needs to be a parameter in the URI to specify a cert/key name
to override the defaults on a per-connection basis
yeah, reasonable, I didn't consider all of the drivers, will fix
this problem with adding parameters for URI.
> 2) for default default driver and subdriver for disk image
>
> Another requirement of new preference is default driver and subdriver
> for disk images, currently we use "phy" for "driver" in virsh,
and
> "raw" for "subdriver" in qemu driver by default if user
doesn't specify
> them, it causes bugs, though we could say to user "you should use
> options --driver and --subdriver", but these two options are optional.
>
> IMHO, the best solution for those bugs is to provide new preferences.
virsh is broken here. It shouldn't be setting the driver if the
user doesn't specify it. The libvirt hypervisor specific drivers
know the correct defaults if omitted, so virsh shouldn't try to
guess this (wrongly) itself.
will fix it.
> 3) for default NIC and storage type
>
> "Chris Phillips" raised up the requirement not long ago:
>
> http://www.redhat.com/archives/libvirt-users/2010-November/msg00033.html
This doesn't belong in libvirt. See my reply in that thread.
> ====================
>
> Should we add these new preferences(if they are really neccessary)
> in qemu.conf? or create new config file, e.g. The approch Justin
> raised up an approch before:
> http://www.redhat.com/archives/libvir-list/2010-November/msg00651.html
>
> Though for Justin's approch, IMHO we'd better also to provide a
> default config file, e.g. "/etc/libvirt/client.conf".
Library APIs like libvirt shouldn't really rely on preference files,
because such a file would silently change behaviour in ways that
applications using the API may not expect. ie the preference
may work nicely for one app/user of libvirt, but not for another
app. Environment variables would cause similar problems too. Anything
that needs to be configured should be configurable via the APIs or
XML.
good to known, thanks :-)
- Osier
Regards,
Daniel
3:38 p.m.
On Wed, Dec 01, 2010 at 10:26:35AM +0000, Daniel P. Berrange wrote:
On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote:
> Hi, all
>
> We have some new requirements of preferences, I listed
> which of them I known, and think is useful as follows:
>
> 1) for the path of x509 certificate and keys of client
>
> The path of x509 certificate and keys of client is hard
> coded in remote driver. e.g.
>
> /* Defaults for PKI directory. */
> # define LIBVIRT_PKI_DIR SYSCONFDIR "/pki"
> # define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem"
> # define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private
> /clientkey.pem"
> # define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem"
We can't assume one set of certs/keys is suitable for all
URIs, so making this a preference setting doesn't help. There
needs to be a parameter in the URI to specify a cert/key name
to override the defaults on a per-connection basis
As much as I disliked adding long ugly filenames to the URI, I do not
see any way around it now. A single client application may need to open
two connections with different cert/key pairs, so a single client.conf
or environment variables won't cut it.
4:32 a.m.
On Thu, Dec 02, 2010 at 11:38:26PM +0200, Dan Kenigsberg wrote:
On Wed, Dec 01, 2010 at 10:26:35AM +0000, Daniel P. Berrange wrote:
> On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote:
> > Hi, all
> >
> > We have some new requirements of preferences, I listed
> > which of them I known, and think is useful as follows:
> >
> > 1) for the path of x509 certificate and keys of client
> >
> > The path of x509 certificate and keys of client is hard
> > coded in remote driver. e.g.
> >
> > /* Defaults for PKI directory. */
> > # define LIBVIRT_PKI_DIR SYSCONFDIR "/pki"
> > # define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem"
> > # define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private
> > /clientkey.pem"
> > # define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR
"/libvirt/clientcert.pem"
>
> We can't assume one set of certs/keys is suitable for all
> URIs, so making this a preference setting doesn't help. There
> needs to be a parameter in the URI to specify a cert/key name
> to override the defaults on a per-connection basis
As much as I disliked adding long ugly filenames to the URI, I do not
see any way around it now. A single client application may need to open
two connections with different cert/key pairs, so a single client.conf
or environment variables won't cut it.
NB, I wasn't really suggesting adding the long filenames. Instead
I'd suggest adding some cert "name" tag, and use that to formulate
the filenames according to some pattern,
eg
$HOME/.libvirt/$name/cacert.pem
$HOME/.libvirt/$name/clientcert.pem
$HOME/.libvirt/$name/clientkey.pem
Daniel
5:48 a.m.
On Mon, Dec 06, 2010 at 10:32:21AM +0000, Daniel P. Berrange wrote:
On Thu, Dec 02, 2010 at 11:38:26PM +0200, Dan Kenigsberg wrote:
> On Wed, Dec 01, 2010 at 10:26:35AM +0000, Daniel P. Berrange wrote:
> > On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote:
> > > Hi, all
> > >
> > > We have some new requirements of preferences, I listed
> > > which of them I known, and think is useful as follows:
> > >
> > > 1) for the path of x509 certificate and keys of client
> > >
> > > The path of x509 certificate and keys of client is hard
> > > coded in remote driver. e.g.
> > >
> > > /* Defaults for PKI directory. */
> > > # define LIBVIRT_PKI_DIR SYSCONFDIR "/pki"
> > > # define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem"
> > > # define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private
> > > /clientkey.pem"
> > > # define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR
"/libvirt/clientcert.pem"
> >
> > We can't assume one set of certs/keys is suitable for all
> > URIs, so making this a preference setting doesn't help. There
> > needs to be a parameter in the URI to specify a cert/key name
> > to override the defaults on a per-connection basis
>
> As much as I disliked adding long ugly filenames to the URI, I do not
> see any way around it now. A single client application may need to open
> two connections with different cert/key pairs, so a single client.conf
> or environment variables won't cut it.
NB, I wasn't really suggesting adding the long filenames. Instead
I'd suggest adding some cert "name" tag, and use that to formulate
the filenames according to some pattern,
eg
$HOME/.libvirt/$name/cacert.pem
$HOME/.libvirt/$name/clientcert.pem
$HOME/.libvirt/$name/clientkey.pem
(but make sure it works for homeless daemons, too)
5100
days inactive
5105
days old
8 comments
4 participants
participants (4)
-
Dan Kenigsberg -
Daniel P. Berrange -
Justin Clift -
Osier Yang