Daniel P. Berrangé <berra...@redhat.com> writes: > On Wed, Apr 18, 2018 at 06:52:08PM +0200, Kevin Wolf wrote: >> Am 18.04.2018 um 18:34 hat Daniel P. Berrangé geschrieben: >> > On Wed, Apr 18, 2018 at 06:28:23PM +0200, Kevin Wolf wrote: >> > > Am 18.04.2018 um 17:06 hat Markus Armbruster geschrieben: >> > >> > > > Note that users can still configure authentication methods with a >> > > > configuration file. They probably do that anyway if they use Ceph >> > > > outside QEMU as well. >> > > >> > > This solution that we originally intended to offer was dismissed by >> > > libvirt as unpractical: libvirt allows the user to specify both a config >> > > file and a key, and if it wanted to use a config file to pass the key, >> > > it would have to create a merged config file and keep it sync with the >> > > user config file at all times. Understandable that they want to avoid >> > > this.
Yes. >> > Even if the config file does have auth info setup, we can't assume that >> > the QEMU VMs are supposed to use the same auth info. If the user tells you to use this config file, you better assume that's what he wants. >> > In fact to properly >> > protect against compromised QEMU, ideally every QEMU would use a completely >> > separate RBD user+password, so that compromised QEMU can't then access >> > RBD disks belonging to a different user. Yes, unless the user tells you otherwise. >> > So from libvirt POV we want to pretend the config file does not exist at >> > all and explicitly pass everything that is needed via normal per-disk >> > setup for blockdev. >> >> From the rbd driver: >> >> * The "conf" option specifies a Ceph configuration file to read. If >> * it is not specified, we will read from the default Ceph locations >> * (e.g., /etc/ceph/ceph.conf). To avoid reading _any_ configuration >> * file, specify conf=/dev/null. >> >> So what we actually expected libvirt to do is to create a config file >> for each rbd image and pass that to qemu. However, libvirt allows the >> user to specify their own config file and passes that, and therefore >> doesn't want to create its own config file. If the user doesn't specify >> a config file, libvirt should probably indeed use /dev/null at least. > > Yeah this is a mess - I wish we had never allowed users to pass a config > file, and had used /dev/null all the time. Unfortunately changing either > of these aspects would cause backcompat problems for existing deployments > now :-( So we just have to accept that the global config file is always > in present, but none the less libvirt should try to specify things as > fully as possible. I'm afraid you get backward compatibility problems no matter what. Whenever you extend libvirt to pass configuration C "via normal per-disk setup for blockdev", it breaks user config files containing C, doesn't it? <heresy>If you're going to break config files on every new feature anyway, why not break them once and for all, then use them the way we actually expected libvirt to do.</heresy>
