date:20160406

Re: [libvirt] [PATCH v2 0/4] Add a domain masterKey secret for qemu,

2016-04-06 Thread John Ferlan



On 03/29/2016 07:11 PM, John Ferlan wrote:
> v1: http://www.redhat.com/archives/libvir-list/2016-March/msg01206.html
> 
> Patch 1 is already ACK'd. I assume this code won't go into 1.3.3, but
> would hopefully be early in 1.3.4 and I didn't want to break up the
> capability bits across releases...
> 
> Differences to v1
> 
>  - Patch 2 is new - it's taking the virUUIDGenerateRandomBytes and making
>it generic since we'll use it in Patch 3 (it already opens/reads from
>/dev/urandom, so I figured it'd be better to share than cut, copy, paste).
> 
>  - Patch 3 has changes from review:
> 
>* Less comments in qemuDomainGetMasterKeyFilePath
> 
>* Master key no longer base64 encoded to be written (or read). Instead
>  the Write code will open, truncate, and write the secret directly.
>  The Read code will read the secret directly
> 
>* The fallback algorithm for key generation uses virGenerateRandomBytes
> 
>* Changed 'masterKey' from "char *" to "uint8_t *" and added the
>  masterKeyLen
> 
>  - Patch 4 changes in order to tell qemu the format of the file is 'raw'.
>Also affects test .args file
> 
> 
> Removed references to encode/decode, adjusted commit messages.
> 
> Ran through Coverity checker... happy...
> 
> Created a domain that would pass/read the file...  Killed libvirtd, restarted
> and read the masterKey file properly. Also ensured the #else of the secret
> generation compiled...
> 
> John Ferlan (4):
>   qemu: Add capability bit for qemu secret object
>   util: Introduce virGenerateRandomBytes
>   qemu: Create domain master key
>   qemu: Introduce qemuBuildMasterKeyCommandLine
> 
>  src/libvirt_private.syms   |   1 +
>  src/qemu/qemu_alias.c  |  17 ++
>  src/qemu/qemu_alias.h  |   3 +
>  src/qemu/qemu_capabilities.c   |   2 +
>  src/qemu/qemu_capabilities.h   |   1 +
>  src/qemu/qemu_command.c|  68 ++
>  src/qemu/qemu_domain.c | 252 
> +
>  src/qemu/qemu_domain.h |  15 ++
>  src/qemu/qemu_process.c|  11 +
>  src/util/virutil.c |  36 +++
>  src/util/virutil.h |   3 +
>  src/util/viruuid.c |  30 +--
>  tests/qemucapabilitiesdata/caps_2.6.0-1.caps   |   1 +
>  tests/qemucapabilitiesdata/caps_2.6.0-1.replies|   3 +
>  .../qemuxml2argvdata/qemuxml2argv-master-key.args  |  23 ++
>  tests/qemuxml2argvdata/qemuxml2argv-master-key.xml |  30 +++
>  tests/qemuxml2argvtest.c   |   2 +
>  17 files changed, 469 insertions(+), 29 deletions(-)
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-master-key.args
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-master-key.xml
> 

Made requested adjustments and pushed.

Working through the IV support now...

Tks for the review,

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] libxl: libxl_domain_create_restore has an extra argument

2016-04-06 Thread Doug Goldstein

On 4/5/16 9:20 AM, Wei Liu wrote:
> In the latest libxenlight code, libxl_domain_create_restore accepts a
> new argument. Update libvirt's libxl driver for that. Use the macro
> provided by libxenlight to detect which version should be used.
> 
> The new parameter (send_back_fd) is set to -1 because libvirt provides
> no such fd.
> 
> Signed-off-by: Wei Liu 
> ---
> Build test with Xen 4.6.1 (old API) and Xen unstable (new API).
> ---
>  src/libxl/libxl_domain.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 04962a0..aed904b 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1070,7 +1070,12 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
> virDomainObjPtr vm,
>  ret = libxl_domain_create_new(cfg->ctx, _config,
>, NULL, _console_how);
>  } else {
> -#ifdef LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS
> +#if defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD)
> +params.checkpointed_stream = 0;
> +ret = libxl_domain_create_restore(cfg->ctx, _config, ,
> +  restore_fd, -1, , NULL,
> +  _console_how);
> +#elif defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS)
>  params.checkpointed_stream = 0;
>  ret = libxl_domain_create_restore(cfg->ctx, _config, ,
>restore_fd, , NULL,
> 

ACK

This fixes integration testing that Xen Project does with libvirt and
Xen so it would be nice to get in for 1.3.3.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] 200ms delay waiting for qemu monitor

2016-04-06 Thread Richard W.M. Jones

[Thanks to Dan Berrangé for doing the analysis of this one]

I was investigating a 200+ millisecond delay when libvirt starts a
qemu guest. You can see the traces here:

http://oirase.annexia.org/tmp/libvirt.log
http://oirase.annexia.org/tmp/libvirtd.log

The delay happens at around 16:52:57.327-6:52:57.528 in the libvirtd log.
As you can see the delay is almost precisely 200ms.

Dan found the cause which seems to be this code:

https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_monitor.c;h=10a6713c06ad36e2055f8144fba00b78630971e5;hb=HEAD#l365

(There are other examples of the same anti-pattern in src/fdstream.c
and src/qemu/qemu_agent.c, but it's the particular code above which
seems to be causing the delay).

To give you some sense why I regard this as a problem, the TOTAL time
taken to launch and shutdown the libguestfs appliance (that includes
qemu, BIOS, guest kernel, probing and mouting disks, running the
guestfs daemon, and the shutdown process in reverse), without libvirt,
is now 900ms. Libvirt adds about 220ms on top of this.

What can we do about this? Obviously we could simply reduce the
delay, but even if it was set to 20ms, that would be too much (aim is
to reduce the whole process from 900ms down to 150ms), and it would
also mean that libvirt was essentially polling.

Can we use inotify to detect if the socket has been created? Seems to
create portability problems.

Dan suggested:

Can we create the socket in libvirtd and pass it to qemu?

Can we pass a file descriptor to qemu?

Other suggestions?

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

56 matches

Mail list logo