On Thu, May 06, 2021 at 17:42:58 +, Moshe Levi wrote:
>
>
> > -Original Message-
> > From: Peter Krempa
> > Sent: Thursday, May 6, 2021 8:16 PM
> > To: Gavi Teitz
> > Cc: libvir-list@redhat.com; Moshe Levi
> > Subject: Re: [PATCH v2] Add page_per_vq flag to the 'driver' element of
On Fri, 2021-05-07 at 08:36 +0200, Erik Skultety wrote:
> On Thu, May 06, 2021 at 05:34:55PM +0200, Peter Krempa wrote:
> > On Thu, May 06, 2021 at 17:08:38 +0200, Tim Wiederhake wrote:
> > > meson supports the following sanitizers: "address" (e.g. out-of-
> > > bounds
> > > memory access, use-afte
On Fri, May 07, 2021 at 09:10:44AM +0200, Tim Wiederhake wrote:
> On Fri, 2021-05-07 at 08:36 +0200, Erik Skultety wrote:
> > On Thu, May 06, 2021 at 05:34:55PM +0200, Peter Krempa wrote:
> > > On Thu, May 06, 2021 at 17:08:38 +0200, Tim Wiederhake wrote:
> > > > meson supports the following saniti
On Tue, May 04, 2021 at 06:16:11PM +0200, Kashyap Chamarthy wrote:
[...]
> Kashyap Chamarthy (2):
> docs: kbase: Add a doc on live full disk backup
> docs: kbase: Add a doc on merging disk image chains
Here's the HTML rendering (converted with `rst2html`):
https://kashyapc.fedorapeople.or
On a Tuesday in 2021, Michal Privoznik wrote:
Since its introduction in v0.9.1~65 the virOnce() was expected to
follow the usual retval logic (0 for success, a negative number
for failure). However, that was never the case.
On the other hand, looking into glibc and musl the pthread_once()
never
On 5/4/21 6:16 PM, Kashyap Chamarthy wrote:
> This is a rewrite of:
>
>
> https://wiki.libvirt.org/page/Live-merge-an-entire-disk-image-chain-including-current-active-disk
>
> Once this commit merges, the above wiki should point to this kbase
> document.
>
> Signed-off-by: Kashyap Chamarthy
On 5/4/21 6:16 PM, Kashyap Chamarthy wrote:
> This is a rewrite of:
>
> https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit
>
> Once this commit merges, the above wiki should point to this kbase
> document.
>
> Signed-off-by: Kashyap Chamarthy
> ---
> docs/kbase/index.rs
On Tue, May 04, 2021 at 18:16:12 +0200, Kashyap Chamarthy wrote:
> This is a rewrite of:
>
> https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit
>
> Once this commit merges, the above wiki should point to this kbase
> document.
>
> Signed-off-by: Kashyap Chamarthy
> ---
>
Thanks for Michal's nice review opinions.
I followed these proposals rewrite and retest the patch again, and will send
the v2 patch through git send-email later.
int
virDomainReloadTLSCertificates(virDomainPtr domain,
unsigned int type,
On Fri, May 07, 2021 at 01:22:13PM +0200, Peter Krempa wrote:
> On Tue, May 04, 2021 at 18:16:12 +0200, Kashyap Chamarthy wrote:
[...]
> > diff --git a/docs/kbase/live_full_disk_backup.rst
> > b/docs/kbase/live_full_disk_backup.rst
> > new file mode 100644
> > index 00..f4ef7f2cc7
> > --
On Fri, May 07, 2021 at 12:29:26PM +0200, Michal Prívozník wrote:
> On 5/4/21 6:16 PM, Kashyap Chamarthy wrote:
[...]
> > Signed-off-by: Kashyap Chamarthy
> > ---
> > docs/kbase/index.rst | 3 +
> > docs/kbase/live_full_disk_backup.rst | 111 +++
> > 2
I'm not going to apply this yet as I realized that I have broken
internal secrets with monolithic libvirtd instead :-(
On Tue, May 04, 2021 at 06:43:41PM +0100, Daniel P. Berrangé wrote:
> If you define a secret with private="yes", then libvirt won't let any
> client query the secret value after i
On 5/7/21 2:33 PM, Daniel P. Berrangé wrote:
> I'm not going to apply this yet as I realized that I have broken
> internal secrets with monolithic libvirtd instead :-(
You did? I've tested it (by starting a pool with a secret) and it worked.
Michal
On Fri, May 07, 2021 at 03:43:32PM +0200, Michal Prívozník wrote:
> On 5/7/21 2:33 PM, Daniel P. Berrangé wrote:
> > I'm not going to apply this yet as I realized that I have broken
> > internal secrets with monolithic libvirtd instead :-(
>
> You did? I've tested it (by starting a pool with a sec
On 5/7/21 3:46 PM, Daniel P. Berrangé wrote:
> On Fri, May 07, 2021 at 03:43:32PM +0200, Michal Prívozník wrote:
>> On 5/7/21 2:33 PM, Daniel P. Berrangé wrote:
>>> I'm not going to apply this yet as I realized that I have broken
>>> internal secrets with monolithic libvirtd instead :-(
>>
>> You d
On Fri, May 07, 2021 at 03:48:42PM +0200, Michal Prívozník wrote:
> On 5/7/21 3:46 PM, Daniel P. Berrangé wrote:
> > On Fri, May 07, 2021 at 03:43:32PM +0200, Michal Prívozník wrote:
> >> On 5/7/21 2:33 PM, Daniel P. Berrangé wrote:
> >>> I'm not going to apply this yet as I realized that I have br
On 5/7/21 4:08 PM, Daniel P. Berrangé wrote:
> On Fri, May 07, 2021 at 03:48:42PM +0200, Michal Prívozník wrote:
>> On 5/7/21 3:46 PM, Daniel P. Berrangé wrote:
>>> On Fri, May 07, 2021 at 03:43:32PM +0200, Michal Prívozník wrote:
On 5/7/21 2:33 PM, Daniel P. Berrangé wrote:
> I'm not goin
On 4/27/21 10:25 AM, Tim Wiederhake wrote:
> Linux 5.13 introduces "kcpuid", a tool similar to cpuid, which we depend
> on for cpu-data collection with tests/cputestdata/cpu-data.py.
>
> This series adds support for kcpuid to cpu-data.py.
>
> See also
> https://git.kernel.org/pub/scm/linux/kernel
If you define a secret with private="yes", then libvirt won't let any
client query the secret value after it is set. Only other libvirt
drivers inside the daemon can query it by passing a special internal
only flag to the virSecretGetValue API. The remote driver/daemon
refuses to let this internal
A random token is simply a string of random bytes formatted in
hexidecimal.
Reviewed-by: Michal Privoznik
Signed-off-by: Daniel P. Berrangé
---
src/libvirt_private.syms | 1 +
src/util/virrandom.c | 18 ++
src/util/virrandom.h | 1 +
3 files changed, 20 insertions(+)
When creating the system identity set the system token. The system
token is currently stored in a local path
/var/run/libvirt/common/system.token
Obviously with only traditional UNIX DAC in effect, this is largely
security through obscurity, if the client is running at the same
privilege level
Reviewed-by: Michal Privoznik
Signed-off-by: Daniel P. Berrangé
---
src/util/viridentity.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/util/viridentity.c b/src/util/viridentity.c
index 8c939a507e..dabe416037 100644
--- a/src/util/viridentity.c
+++ b/src/util/viridentity.c
@@ -
We want a way to distinguish between calls from a libvirt daemon, and a
regular client application when both are running as the same user
account. This is not possible with the current set of attributes
recorded against an identity, as there is nothing that is common to all
of the modular libvirt d
This is essentially a way to determine if the current identity
is that of another libvirt daemon.
Reviewed-by: Michal Privoznik
Signed-off-by: Daniel P. Berrangé
---
src/libvirt_private.syms | 1 +
src/util/viridentity.c | 28
src/util/viridentity.h | 1 +
3 f
The drivers can all call virGetConnectXXX to open a connection to a
secondary driver. For example, when creating a encrypted storage volume,
the storage driver has to open a secret driver connection, or when
starting a guest, the QEMU driver has to open the network driver to
lookup a virtual networ
A secret can be marked with the "private" attribute. The intent was that
it is not possible for any libvirt client to be able to read the secret
value, it would only be accesible from within libvirtd. eg the QEMU
driver can read the value to launch a guest.
With the modular daemons, the QEMU, stor
When fetching the value of a private secret, we need to use an elevated
identity otherwise the secret driver will deny access.
When using the modular daemons, the elevated identity needs to be active
before the secret driver connection is opened, and it will apply to all
APIs calls made on that co
Reviewed-by: Michal Privoznik
Signed-off-by: Daniel P. Berrangé
---
src/libvirt_private.syms | 1 +
src/util/viridentity.c | 21 +
src/util/viridentity.h | 1 +
3 files changed, 23 insertions(+)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index aaa
When talking to the secret driver, the callers inside libvirt daemons
need to be able to run with an elevated privileges that prove the API
calls are made by a libvirt daemon, not an end user application.
The virIdentityElevateCurrent method will take the current identity
and, if not already prese
On 5/7/21 11:24 AM, Daniel P. Berrangé wrote:
> We want a way to distinguish between calls from a libvirt daemon, and a
> regular client application when both are running as the same user
> account. This is not possible with the current set of attributes
> recorded against an identity, as there is
On 5/7/21 11:24 AM, Daniel P. Berrangé wrote:
> When creating the system identity set the system token. The system
> token is currently stored in a local path
>
>/var/run/libvirt/common/system.token
>
> Obviously with only traditional UNIX DAC in effect, this is largely
> security through obs
The new virDomainReloadTlsCertificates API is used to notify domain reload
its certificates without restart, and avoid service interruption.
Currently, only QEMU VNC TLS certificates are supported, but parameters and
flags are also reserved for subsequent scenarios.
Take reload QEMU VNC TLS certi
32 matches
Mail list logo
