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
Charles Duffy schrieb:
Mirko Raasch wrote:
How can i use valgrind or some other debugging options with
"/etc/init.d/libvirt-bin"?
This won't work for valgrind, but the gdb "attach" command will let
you connect to (and thus get a stack trace from) a running process.
If your libvirtd has PID
Hello,
I'm trying to get eucalyptus v1.5.2 working with debian lenny, the relevant
versions of libvirt software installed are from the apt-get repos, which are:
# dpkg -l|grep libvirt
ii libvirt-bin 0.4.6-10 the programs
for the libvirt library
ii lib
2009/8/14 Eduardo Otubo :
> On Fri, 2009-08-07 at 15:35 +0200, Chris Lalancette wrote:
>> Matthias Bolte wrote:
>> > Hi,
>> >
>> > I came across this line in the phypOpen function:
>> >
>> > char string[strlen(conn->uri->path)];
>> >
>> > Here the path part of the given URI is used without checking
23 matches
Mail list logo
