etadata fields that can be supported by the journal; fields beyond
this limit are silently dropped (but the initial part of the message
sent). This was implemented in the previous patch, here we just
increase the limit to 32 fields total.
Signed-off-by: Miloslav Trmač
---
This version drops loggin
imposes an upper limit on the total number of iovs/buffers
used, and fields that wouldn't fit are silently dropped. This is not
significant in this patch, but will affect the following one.
Signed-off-by: Miloslav Trmač
---
src/util/logging.c
memory imposes a fixed limit on the number
of metadata fields that can be supported by the journal; fields beyond
this limit are silently dropped (but the initial part of the message
sent). This was implemented in the previous patch, here we just
increase the limit to 32 fields total.
Signed-off-b
ot;:""}
None of the existing log output formats (e.g. "syslog" or "file") is
affected.
Async-signal-safety is preserved by
a) providing a custom allocation function to yajl, and
b) using a custom print function.
Both use memory allocated within the stack frame.
Sig
... and update all users. No change in functionality, the parameter
will be used in the next patch.
Signed-off-by: Miloslav Trmač
---
src/util/logging.c | 14 +-
src/util/logging.h | 2 ++
tests/testutils.c | 1 +
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a
safe by the letter
of the standard, but safe in practice). I still think that having this
format output is desirable, but I'll accept it if you decide that it is
not wanted in libvirt.
Miloslav Trmač (5):
Add a metadata parameter to virLog{,V}Message
Add metadata to virLogOutputFunc
Use
iated
compiler checking.
Signed-off-by: Miloslav Trmač
---
src/util/logging.c | 6 +-
src/util/logging.h | 24 ++--
src/util/viraudit.c | 4 ++--
src/util/virterror.c | 2 +-
4 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/src/util/logging.c b/src
... and update all users. No change in functionality, the parameter
will be used in the next patch.
Signed-off-by: Miloslav Trmač
---
src/util/logging.c | 20 +++-
src/util/logging.h | 2 ++
tests/testutils.c | 1 +
3 files changed, 14 insertions(+), 9 deletions(-)
diff
... and update all users. No change in functionality, the parameter
will be used in later patches.
Signed-off-by: Miloslav Trmač
---
src/uml/uml_conf.c | 2 +-
src/util/logging.c | 13 +
src/util/logging.h | 17 +
src/util/viraudit.c | 4 ++--
src/util
Signed-off-by: Miloslav Trmač
---
src/libvirt_private.syms | 4 +
tests/Makefile.am| 6 +-
tests/errorjsontest.c| 211 +++
3 files changed, 220 insertions(+), 1 deletion(-)
create mode 100644 tests/errorjsontest.c
diff --git a/src
No change in functionality; the newly separated virLogPrioritySyslog
function will be used by the next patch.
Signed-off-by: Miloslav Trmač
---
src/util/logging.c | 36 +---
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/src/util/logging.c b/src
ge in the string mapping would be less likely to be noticed
The advantage of using strings is more readability, but note that the
"msg" field above already contains a readable description of the
error.
The JSON object is again allocated on the stack to avoid the risk of
allocations f
In addition to the preformatted text line, pass the raw message as well,
to allow the output functions to use a different output format.
This patch only changes the interface and callers, an output function
that takes advantage of this will follow.
Signed-off-by: Miloslav Trmač
---
src/util
nt than allocating them from the heap, but we don't have to care
about the allocations failing, calling virReportOOMError and deadlocking
on virLogMutex.
Signed-off-by: Miloslav Trmač
---
docs/logging.html.in | 3 ++
src/util/json.c | 20 +-
src/util/logging.c | 110 +++
Add a JSON API that allows creating a JSON data structure within
variables preallocated on the stack, without allocating memory in the
heap.
Signed-off-by: Miloslav Trmač
---
src/util/json.c | 82 +
src/util/json.h | 11
2 files
assumed that other parts of libvirt may add more event-specific
JSON fields in the future, based on demand by applications that process
the logs; I have, however, no immediate plans to add more.
Miloslav Trmač (12):
Drop unused return value of virLogOutputFunc
Add JSON API for preallocate
This allows incremental use of virJSONStringGeneratorAddProperties
without constructing a full object first, while isolating the rest of
libvirt from the yajl dependency.
Will be used later.
Signed-off-by: Miloslav Trmač
---
src/util/json.c | 60
Split yajl_gen (and handling of the yajl version differences) into
virYAJLInit().
No functionality changed; the function will be used in a later patch.
Signed-off-by: Miloslav Trmač
---
src/util/json.c | 35 ++-
1 file changed, 22 insertions(+), 13 deletions
g the unnecessary
return value in the virLogOutputFunc instance that will be added in this
series.
Signed-off-by: Miloslav Trmač
---
src/util/logging.c | 56 +-
src/util/logging.h | 14 ++
tests/testutils.c | 5 ++---
3 files ch
No functionality change (well, the index is now a size_t instead of int),
the function will be used later.
Signed-off-by: Miloslav Trmač
---
src/util/json.c | 35 ++-
src/util/json.h | 12
2 files changed, 38 insertions(+), 9 deletions(-)
diff --git
... to be more consistent with other sections.
* src/libvirt_private.syms: Add a missing comment.
---
src/libvirt_private.syms |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 3cb707e..73a3a80 100644
--- a/src/libvi
The interface allows qemudMonitorSendCont() to report errors that are
not overridden by its callers.
Also fix a potential infinite loop in qemuDomainCoreDump() if sending
cont repeatedly fails.
Changes since the fourth submission:
- Replace the "error_reported" parameter by using virGetLastError(
Changes since the fourth submission:
- Update for removed "error_reported" parameter to
qemudMonitorSendCont()
- Replace the "libvirt_internal_call" parameter of setValue() by
VIR_SECRET_GET_VALUE_INTERNAL_CALL.
* src/qemu_driver.c (findDomainDiskEncryption,
* findVolumeQcowPassphrase,
qemud
If the element does not specify a secret
during volume creation, generate a suitable secret and add it to the
tag. The caller can view the updated tag
using virStorageVolGetXMLDesc().
Similarly, when is specified while
creating a qcow or qcow2-formatted volume, change the format to "qcow"
and
* storage_encryption_conf.c: Fix a pasto in comment.
---
src/storage_encryption_conf.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/storage_encryption_conf.c b/src/storage_encryption_conf.c
index 7ec24af..7b9ee88 100644
--- a/src/storage_encryption_conf.c
+++ b/src
* src/virsh.c: Add virsh commands.
* docs/virsh.pod, virsh.1: Update documentation.
---
docs/virsh.pod | 43
src/virsh.c| 323
virsh.1| 34 ++-
3 files changed, 399 insertions(+), 1 deletions(-)
diff --git a/do
This implementation stores the secrets in an unencrypted text file,
for simplicity in implementation and debugging.
(Symmetric encryption, e.g. using gpgme, will not be difficult to add.
Because the TLS private key used by libvirtd is stored unencrypted,
encrypting the secrets file does not curren
Add a XML handling API, separate from the local driver, to
avoid manually generating XML in other parts of libvirt.
* src/secret_conf.c, src/secret_conf.h: New files.
* po/POTFILES.in, src/Makefile.am: Add secret_conf.
---
po/POTFILES.in |1 +
src/Makefile.am |7 +-
sr
Add a VIR_SECRET_GET_VALUE_INTERNAL_CALL flag value, replacing the
originally separate libvirt_internal_call parameter. The flag is used
to differentiate external virSecretGetValue() calls from internal calls
by libvirt drivers that need to use the secret even if it is private.
* src/libvirt_inte
* docs/formatsecret.html.in, docs/formatsecret.html: Document , replacing stand-alone .
* docs/schemas/secret.rng: Update schema to require
---
docs/formatsecret.html| 19 ---
docs/formatsecret.html.in | 25 -
docs/schemas/secret.rng | 14 ++
Major changes since the previous submission:
- Use one or two separate files per secret, using XML for metadata, instead
of a single file for all secrets using a custom format.
- Split XML handling from the local driver into secret_conf.[ch],
use it when auto-generating secrets.
- Use instead
Changes since the third submission:
- Add "flags" parameter to virSecretDefineXML(), virSecretGetXMLDesc(),
virSecretGetValue(), virSecretSetValue(), and all derived interfaces.
---
src/qemu_driver.c | 161 ++---
1 files changed, 153 insertions(+)
The interface allows qemudMonitorSendCont() to report errors that are
not overridden by its callers.
Also fix a potential infinite loop in qemuDomainCoreDump() if sending
cont repeatedly fails.
---
src/qemu_driver.c | 89 +++--
1 files changed, 52
Support arbitrary callbacks for "secondary prompts". Reimplement
qemudMonitorCommandExtra using such a callback.
---
src/qemu_driver.c | 84 +---
1 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.
If the element does not specify a secret
during volume creation, generate a suitable secret and add it to the
tag. The caller can view the updated tag
using virStorageVolGetXMLDesc().
Similarly, when is specified while
creating a qcow or qcow2-formatted volume, change the format to "qcow"
and
The XML allows , this implementation
canonicalizes the internal representation so that "disk->encryption" is
non-NULL iff encryption information is available.
A domain with partial encryption information can be defined,
completeness of the information is not verified. The domain won't
start until
The if ((nlptr...)) implicitly assumes commptr != NULL (and that "buf"
starts with "cmd"). Make the assumption explicit, it will be broken in
a future patch.
---
src/qemu_driver.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
(The implementation is not very generic, but that can be very
easily rectified if/when new encryption formats appear.)
---
src/storage_backend_fs.c | 61 +++--
1 files changed, 47 insertions(+), 14 deletions(-)
diff --git a/src/storage_backend_fs.c b/src/
Supports only virStorageVolCreateXML, not virStorageVolCreateXMLFrom.
Curiously, qemu-img does not need the passphrase for anything to create
an encrypted volume. This implementation thus does not need to touch
any secrets to work with cooperating clients. More generic passphrase
handling is add
The XML allows , this implementation
canonicalizes the internal representation so that "vol->encryption" is
non-NULL iff the volume is encrypted.
Note that partial encryption information (e.g. specifying an encryption
format, but not the key/passphrase) is valid, libvirt will automatically
choose
Define an tag specifying volume encryption format and
format-depenedent parameters (e.g. passphrase, cipher name, key
length, key).
Currently the only defined parameter is a reference to a "secret"
(passphrase/key) managed using the virSecret* API.
Only the qcow/qcow2 encryption format, and a "d
Sample session:
>>> import libvirt
>>> c = libvirt.open('qemu:///session')
>>> c.listSecrets()
['12247729-47d2-a783-88ce-b329d4781cd3', 'reee', 'abc']
>>> s = c.secretDefineXML(">> private='no'>\nSomething for
>>> use\n/foo/bar\n\n")
>>> s.UUIDString()
'340c2dfb-811b-eda8-da9e-25ccd7bfd650'
>
Changes since the third submission:
- Add "flags" parameter to virSecretDefineXML(), virSecretGetXMLDesc(),
virSecretGetValue(), virSecretSetValue(), and all derived interfaces.
- Add documentation to virsh.1
---
docs/virsh.pod | 43
src/virsh.c| 323 +
This implementation stores the secrets in an unencrypted text file,
for simplicity in implementation and debugging.
(Symmetric encryption, e.g. using gpgme, will not be difficult to add.
Because the TLS private key used by libvirtd is stored unencrypted,
encrypting the secrets file does not curren
Changes since the third submission:
- Add "flags" parameter to virSecretDefineXML(), virSecretGetXMLDesc(),
virSecretGetValue(), virSecretSetValue(), and all derived interfaces.
---
qemud/remote.c | 203
1 files changed, 203 insertions(+)
Changes since the third submission:
- Add "flags" parameter to virSecretDefineXML(), virSecretGetXMLDesc(),
virSecretGetValue(), virSecretSetValue(), and all derived interfaces.
---
qemud/remote_dispatch_args.h |7 ++
qemud/remote_dispatch_prototypes.h | 56 ++
qemud/remo
Changes since the third submission:
- Add "flags" parameter to virSecretDefineXML(), virSecretGetXMLDesc(),
virSecretGetValue(), virSecretSetValue(), and all derived interfaces.
---
src/datatypes.h |1 +
src/remote_internal.c | 328 +
2
Changes since the third submission:
- Add "flags" parameter to virSecretDefineXML(), virSecretGetXMLDesc(),
virSecretGetValue(), virSecretSetValue(), and all derived interfaces.
---
include/libvirt/virterror.h |2 +
src/libvirt.c | 504 +
Adds a new driver type.
Changes since the third submission:
- Add "flags" parameter to virSecretDefineXML(), virSecretGetXMLDesc(),
virSecretGetValue(), virSecretSetValue(), and all derived interfaces.
- Fix a copy&pasted comment
---
include/libvirt/virterror.h |1 +
src/datatypes.c
This patch adds a "secret" as a separately managed object, using a
special-purpose API to transfer the secret values between nodes and
libvirt users.
Rather than add explicit accessors for attributes of secrets, and
hard-code the "secrets are related to storage volumes" association in
the API, the
Hello,
the following patches add full support for qcow/qcow2 volume encryption,
assuming a client that supports it.
(Main changes since the previous version:
* Add "flags" argument to virSecretDefineXML(), virSecretGetXMLDesc(),
virSecretSetValue(), virSecretGetValue()
* Various clean-ups and
Changes since the second submission:
- Update for changed internal API
- s/secret_id/uuid/g
- Use "unsigned char *" for secret value
---
src/qemu_driver.c | 161 ++---
1 files changed, 153 insertions(+), 8 deletions(-)
diff --git a/src/qemu_driver.
The interface allows qemudMonitorSendCont() to report errors that are
not overridden by its callers.
Also fix a potential infinite loop in qemuDomainCoreDump() if sending
cont repeatedly fails.
Changes since the second submission:
- Handle one more, newly added, "cont" command
---
src/qemu_drive
Support arbitrary callbacks for "secondary prompts". Reimplement
qemudMonitorCommandExtra using such a callback.
---
src/qemu_driver.c | 84 +---
1 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.
The if ((nlptr...)) implicitly assumes commptr != NULL (and that "buf"
starts with "cmd"). Make the assumption explicit, it will be broken in
a future patch.
---
src/qemu_driver.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
The XML allows , this implementation
canonicalizes the internal representation so that "disk->encryption" is
non-NULL iff encryption information is available.
A domain with partial encryption information can be defined,
completeness of the information is not verified. The domain won't
start until
If the element does not specify a secret
during volume creation, generate a suitable secret and add it to the
tag. The caller can view the updated tag
using virStorageVolGetXMLDesc().
Similarly, when is specified while
creating a qcow or qcow2-formatted volume, change the format to "qcow"
and
Supports only virStorageVolCreateXML, not virStorageVolCreateXMLFrom.
Curiously, qemu-img does not need the passphrase for anything to create
an encrypted volume. This implementation thus does not need to touch
any secrets to work with cooperating clients. More generic passphrase
handling is add
(The implementation is not very generic, but that can be very
easily rectified if/when new encryption formats appear.)
---
src/storage_backend_fs.c | 61 +++--
1 files changed, 47 insertions(+), 14 deletions(-)
diff --git a/src/storage_backend_fs.c b/src/
The XML allows , this implementation
canonicalizes the internal representation so that "vol->encryption" is
non-NULL iff the volume is encrypted.
Note that partial encryption information (e.g. specifying an encryption
format, but not the key/passphrase) is valid, libvirt will automatically
choose
Define an tag specifying volume encryption format and
format-depenedent parameters (e.g. passphrase, cipher name, key
length, key).
Currently the only defined parameter is a reference to a "secret"
(passphrase/key) managed using the virSecret* API.
Only the qcow/qcow2 encryption format, and a "d
Sample session:
>>> import libvirt
>>> c = libvirt.open('qemu:///session')
>>> c.listSecrets()
['12247729-47d2-a783-88ce-b329d4781cd3', 'reee', 'abc']
>>> s = c.secretDefineXML(">> private='no'>\nSomething for
>>> use\n/foo/bar\n\n")
>>> s.getUUIDString()
'340c2dfb-811b-eda8-da9e-25ccd7bfd650'
Changes since the second submission:
- Change some command names to better follow the conventions
- Update for the changed public API
- Print (potentially auto-generated) secret UUID on successful
secret-define
- s/secret_id/uuid/g
- use "unsigned char *" for secret value
---
src/virsh.c | 323
This implementation stores the secrets in an unencrypted text file,
for simplicity in implementation and debugging.
(Symmetric encryption, e.g. using gpgme, will not be difficult to add.
Because the TLS private key used by libvirtd is stored unencrypted,
encrypting the secrets file does not curren
Changes since the second submission:
- Update for the changed public API
- s/secret_id/uuid/g
- use "unsigned char *" for secret value
---
src/datatypes.h |1 +
src/remote_internal.c | 323 +
2 files changed, 324 insertions(+), 0 deletions
Changes since the second submission:
- Update for the changed public API
- s/secret_id/uuid/g
- use "unsigned char *" for secret value
---
qemud/remote.c | 203
1 files changed, 203 insertions(+), 0 deletions(-)
diff --git a/qemud/remote.c
Changes since the second submission:
- Update for the changed public API
- s/secret_id/uuid/g
---
qemud/remote_dispatch_args.h |7 ++
qemud/remote_dispatch_prototypes.h | 56 +++
qemud/remote_dispatch_ret.h|6 ++
qemud/remote_dispatch_table.h | 40 +++
Changes since the second submission:
- Update for the changed public API
- s/secret_id/uuid/g
- use "unsigned char *" for secret value
---
include/libvirt/virterror.h |2 +
src/libvirt.c | 499 +++
src/virterror.c |9 +
3 f
Adds a new driver type.
Changes since the second submission:
- Update for changed public API
- Add virSecretPtr handling
- s/secret_id/uuid/g
- use "unsigned char *" for secret value
---
include/libvirt/virterror.h |1 +
src/datatypes.c | 153 +
This patch adds a "secret" as a separately managed object, using a
special-purpose API to transfer the secret values between nodes and
libvirt users.
Rather than add explicit accessors for attributes of secrets, and
hard-code the "secrets are related to storage volumes" association in
the API, the
Hello,
the following patches add full support for qcow/qcow2 volume encryption,
assuming a client that supports it.
(Main changes since the previous version:
* Significantly change the internal API, basing it on virSecretPtr instead of
(virConnectPtr, secret_id); details in patch 1
* Make vir
Changes since the first submission:
- Update to use the generic "secrets" encryption representation, and the
separate secret store.
- Use qemudMonitorSend()
---
include/libvirt/virterror.h |1 +
src/qemu_driver.c | 157 --
src/virterror.c
The interface allows qemudMonitorSendCont() to report errors that are
not overridden by its callers.
Also fix a potential infinite loop in qemuDomainCoreDump() if sending
cont repeatedly fails.
Changes since the first submission:
- Suport reporting errors that are not overridden by callers.
---
Support arbitrary callbacks for "secondary prompts". Reimplement
qemudMonitorCommandExtra using such a callback.
---
src/qemu_driver.c | 84 +---
1 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.
The if ((nlptr...)) implicitly assumes commptr != NULL (and that "buf"
starts with "cmd"). Make the assumption explicit, it will be broken in
a future patch.
---
src/qemu_driver.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
The XML allows , this implementation
canonicalizes the internal representation so that "disk->encryption" is
non-NULL iff encryption information is available.
A domain with partial encryption information can be defined,
completeness of the information is not verified. The domain won't
start until
If the element does not specify a secret
during volume creation, generate a suitable secret and add it to the
tag. The caller can view the updated tag
using virStorageVolGetXMLDesc().
Similarly, when is specified while
creating a qcow or qcow2-formatted volume, change the format to "qcow"
and
Supports only virStorageVolCreateXML, not virStorageVolCreateXMLFrom.
Curiously, qemu-img does not need the passphrase for anything to create
an encrypted volume. This implementation thus does not need to touch
any secrets to work with cooperating clients. More generic passphrase
handling is add
(The implementation is not very generic, but that can be very
easily rectified if/when new encryption formats appear.)
Changes since first submission:
- Move inside .
---
src/storage_backend_fs.c | 61 +++--
1 files changed, 47 insertions(+), 14 deletion
The XML allows , this implementation
canonicalizes the internal representation so that "vol->encryption" is
non-NULL iff the volume is encrypted.
Note that partial encryption information (e.g. specifying an encryption
format, but not the key/passphrase) is valid, libvirt will automatically
choose
Define an tag specifying volume encryption format and
format-depenedent parameters (e.g. passphrase, cipher name, key
length, key).
Currently the only defined parameter is a reference to a "secret"
(passphrase/key) managed using the virSecret* API.
Only the qcow/qcow2 encryption format, and a "d
---
src/virsh.c | 304 +++
1 files changed, 304 insertions(+), 0 deletions(-)
diff --git a/src/virsh.c b/src/virsh.c
index 94c3c4e..ad49052 100644
--- a/src/virsh.c
+++ b/src/virsh.c
@@ -41,6 +41,7 @@
#endif
#include "internal.h"
+#incl
Sample session:
>>> import libvirt
>>> c = libvirt.open('qemu:///session')
>>> c.virSecretListSecrets()
['12247729-47d2-a783-88ce-b329d4781cd3', 'reee', 'abc']
>>> c.virSecretAllocateID()
'17427ed8-4040-b6c8-10ba-9cce86dc3d8f'
>>> c.virSecretDelete('17427ed8-4040-b6c8-10ba-9cce86dc3d8f')
0
>>>
This implementation stores the secrets in an unencrypted text file,
for simplicity in implementation and debugging.
(Symmetric encryption, e.g. using gpgme, will not be difficult to add.
Because the TLS private key used by libvirtd is stored unencrypted,
encrypting the secrets file does not curren
---
qemud/remote.c | 149
1 files changed, 149 insertions(+), 0 deletions(-)
diff --git a/qemud/remote.c b/qemud/remote.c
index d32d513..2ecf55b 100644
--- a/qemud/remote.c
+++ b/qemud/remote.c
@@ -4515,6 +4515,155 @@ error:
VIR_FREE(
---
qemud/remote_dispatch_args.h |6 ++
qemud/remote_dispatch_prototypes.h | 56 +++
qemud/remote_dispatch_ret.h|5 ++
qemud/remote_dispatch_table.h | 40 +
qemud/remote_protocol.c| 107
qe
---
src/datatypes.h |1 +
src/remote_internal.c | 306 +
2 files changed, 307 insertions(+), 0 deletions(-)
diff --git a/src/datatypes.h b/src/datatypes.h
index 58a6d32..d17253f 100644
--- a/src/datatypes.h
+++ b/src/datatypes.h
@@ -130,6
---
src/libvirt.c | 365 +
1 files changed, 365 insertions(+), 0 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index 22bc34c..4beb822 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -8660,3 +8660,368 @@ error:
virSetConnErr
Adds a new driver type.
---
include/libvirt/virterror.h |2 +
src/datatypes.h |1 +
src/driver.h| 61 +++
src/libvirt.c | 55 ++
src/virterror.c |9
This patch adds a "secret" as a separately managed object, using a
special-purpose API to transfer the secret values between nodes and
libvirt users.
Rather than add explicit accessors for attributes of secrets, and
hard-code the "secrets are related to storage volumes" association in
the API, the
Hello,
the following patches add full support for qcow/qcow2 volume encryption,
assuming a client that supports it.
(Main changes since the previous version:
* Use a separate API for "secret" management
* Auto-generate the encryption format and passphrase if not supplied
See the specific patch
---
src/qemu_driver.c | 51 ++-
1 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 9ead5fd..b57db31 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2172,10 +2172,59 @@ qemudMonitor
Also fix a potential infinite loop in qemuDomainCoreDump() if sending
cont repeatedly fails.
---
src/qemu_driver.c | 43 ++-
1 files changed, 18 insertions(+), 25 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 12079f8..9ead5fd 10064
---
src/qemu_driver.c | 87
1 files changed, 73 insertions(+), 14 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index f2be27f..12079f8 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -87,6 +87,12 @@ static void qem
The XML allows , this implementation
canonicalizes the internal representation so that "disk->encryption" is
non-NULL iff encryption information is available.
Note that partial encryption information (e.g. specifying an encryption
format, but not the key/passphrase) is valid:
* virDomainGetXMLDesc
The if ((nlptr...)) implicitly assumes commptr != NULL. Make the
assumption explicit, it will be broken in a future patch.
---
src/qemu_driver.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index d2db1a2..f2be27f 100644
--- a
Supports only virStorageVolCreateXML, not virStorageVolCreateXMLFrom.
Curiously, qemu-img does not need the passphrase for anything to create
an encrypted volume. This implementation is sufficient for the qcow2
format, and for other formats when all encryption parameters are
pre-specified.
The q
(The implementation is not very generic, but that can be very
easily rectified if/when new encryption formats appear.)
---
src/storage_backend_fs.c | 61 +++--
1 files changed, 47 insertions(+), 14 deletions(-)
diff --git a/src/storage_backend_fs.c b/src/
The XML allows , this implementation
canonicalizes the internal representation so that "vol->encryption" is
non-NULL iff the volume is encrypted.
Note that partial encryption information (e.g. specifying an encryption
format, but not the key/passphrase) is valid:
* virStorageVolGetXMLDesc() will n
Define an tag specifying volume encryption format and
format-depenedent parameters (e.g. passphrase, cipher name, key
length, key).
In most cases, the "secrets" (passphrases/keys) should only be
transferred from libvirt users to libvirt, not the other way around.
(Volume creation, when libvirt ge
1 - 100 of 107 matches
Mail list logo
