Laine Stump | 27 May 19:11 2016

[libvirt] inconsistency in attribute usage between hv drivers

I just came across this problem while looking for the proper place to 
put <ip> info for the host side of <interface type='ethernet'>. I don't 
think there's really anything that can be done about it now, since 
everything below has been in place for so long, but maybe it can serve 
as a cautionary tale.

Prologue: A week or two ago, I made patches to support <interface 
type='ethernet'> in the LXC driver. I did this not because I have a need 
for that, but because it seemed like the perfect avenue for 
investigating the best way to add IP address and route config to 
<interface>, as it is one environment where we have a need *and* the 
ability to setup IP info for both the host and guest sides of the 
interface. I accomplished this by simply generalizing the existing 
<interface type='bridge'> code to not attach the host-side veth device 
to a bridge.

This makes all common attributes between type='ethernet' and 
type='bridge' consistent, including the configuration of guest-side and 
host-side device names, and here we come to the first inconsistency - 
the device name for the veth/tap on the host side is  in the <target> 
element (which I've always been told is supposed to be used for 
device-specific info about how the device will be presented on the 
*guest* side, but I suppose this is because <interface type='direct'> 
uses <source dev='blah'> to provide the name of the physical device that 
the macvtap device (named in <target dev='macvblah'/> is attached to).  
And I guess because the dev attribute was already in-use in <target> the 
much more recently added guest-side name is given in the <guest> 
subelement (in LXC at least):

     <interface type='ethernet'>
(Continue reading)

Ján Tomko | 27 May 17:45 2016
Picon

[libvirt] [PATCH 0/3] Do not check for domain liveness in virDomainObjSetDefTransient

virDomainObjSetDefTransient has an unintuitive attribute 'live':
when set to 'true', it ignores the virDomainObjIsActive test.

The most common usage is on domain startup, where most of the callers
want to create a transient definition even though the domain is not
yet active.

The only place where live=false is still required is
virDomainObjGetPersistentDef (and its usage could possibly be cleaned
up too, since it's only called in the drivers that already do SetDefTransient
on domain startup).

Split out the virDomainObjIsActive check into virDomainObjGetPersistentDef
and remove it for the rest of the callers along with the 'live' attribute.

Ján Tomko (3):
  Clean up redundant usage of virDomainObjSetDefTransient
  Check if the domain is active in virDomainObjGetPersistentDef
  Do not check for domain liveness in virDomainObjSetDefTransient

 src/conf/domain_conf.c   | 15 ++++-----------
 src/conf/domain_conf.h   |  3 +--
 src/libxl/libxl_domain.c |  3 +--
 src/lxc/lxc_process.c    |  6 +-----
 src/qemu/qemu_process.c  |  4 ++--
 src/test/test_driver.c   |  2 +-
 src/uml/uml_driver.c     |  5 ++---
 7 files changed, 12 insertions(+), 26 deletions(-)

--

-- 
(Continue reading)

Mikhail Feoktistov | 27 May 17:16 2016

[libvirt] [PATCH] vz: implementation of domainSetUserPassword callback

---
 .gnulib            |  2 +-
 src/vz/vz_driver.c | 20 ++++++++++++++++++++
 src/vz/vz_sdk.c    | 31 +++++++++++++++++++++++++++++++
 src/vz/vz_sdk.h    |  5 ++++-
 4 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/.gnulib b/.gnulib
index 8d807a9..6cc32c6 160000
--- a/.gnulib
+++ b/.gnulib
 <at>  <at>  -1 +1  <at>  <at> 
-Subproject commit 8d807a99c6e8eecd2a9cf7c7b5d48ec0b2c934f8
+Subproject commit 6cc32c63e80bc1a30c521b2f07f2b54909b59892
diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c
index 177a57a..b204248 100644
--- a/src/vz/vz_driver.c
+++ b/src/vz/vz_driver.c
 <at>  <at>  -1252,6 +1252,25  <at>  <at>  static int vzDomainDetachDevice(virDomainPtr dom, const char *xml)
                                      VIR_DOMAIN_AFFECT_CONFIG | VIR_DOMAIN_AFFECT_LIVE);
 }

+static int
+vzDomainSetUserPassword(virDomainPtr domain,
+                        const char *user,
+                        const char *password,
+                        unsigned int flags)
+{
+    virDomainObjPtr dom = NULL;
+    int ret = -1;
(Continue reading)

Tomáš Ryšavý | 27 May 16:20 2016
Picon

[libvirt] [PATCH] Removed function virDomainDefNewFull.

The function virDomainDefNewFull() in src/conf/domain_conf.c was a thin
wrapper around virDomainDefNew() that was only used in a few places in
the code. The function was removed and the callers were re-implemented.
---
 src/conf/domain_conf.c   | 22 ----------------------
 src/conf/domain_conf.h   |  3 ---
 src/libvirt_private.syms |  1 -
 src/vz/vz_utils.c        |  8 +++++++-
 src/xen/xen_hypervisor.c | 26 ++++++++++++++++++--------
 src/xen/xend_internal.c  | 23 +++++++++++++++++++----
 src/xen/xm_internal.c    | 24 ++++++++++++++++++++++--
 7 files changed, 66 insertions(+), 41 deletions(-)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index fb05bf7..5721800 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
 <at>  <at>  -2754,28 +2754,6  <at>  <at>  virDomainDefNew(void)
 }

 
-virDomainDefPtr
-virDomainDefNewFull(const char *name,
-                    const unsigned char *uuid,
-                    int id)
-{
-    virDomainDefPtr def;
-
-    if (!(def = virDomainDefNew()))
-        return NULL;
(Continue reading)

John Ferlan | 27 May 15:57 2016
Picon

[libvirt] [PATCH 0/4] Move secret object command line building helpers

More "extractable" changes from my work on adding luks support.

While working through changes in storage_backend.c I found that the
building of the 'qemu-img' command to create a luks volume will need
to create a secret object.

In order to do that I found if I took the qemu_command code and moved
things around a bit, then I would be able to access the API's that I
need.  Moving the command line building from qemu_command.c to virjson.c
seemed logical since it was multipurpose/generic anyway.  I'm not "tied"
to the API name chosen - if there's suggestions, I'll adjust. Then splitting
out the generation of the secret object props into their own API and then
eventually into secret_util.c seemed to be the best avenue.  I can then
include secret_util into the storage driver.

The last change just cleans up the secinfo command building processing.
It was "complicated" when there was going to be hostdev and disk code
trying to generate the same objects... Now that just seems less important.
When/if iSCSI/hostdev support for the AES secret is added, I'll made the
appropriate adjustments then.

John Ferlan (4):
  qemu: Move and rename qemuBuildObjectCommandlineFromJSON
  qemu: Introduce qemuBuildSecretObjectProps
  qemu: Move and rename qemuBuildSecretObjectProps
  qemu: Rework secinfo command line building

 src/libvirt_private.syms    |   4 +-
 src/qemu/qemu_command.c     | 199 ++++++--------------------------------------
 src/qemu/qemu_command.h     |   4 -
(Continue reading)

Andrea Bolognani | 27 May 14:55 2016
Picon

[libvirt] [PATCH 0/3] Fix 'make rpm' failure with systemd 230

Turns out the libsystemd-daemon library, which we've been
using for the sd_notify() feature, has been deprecated for
a long time and has finally been removed as of systemd 230.

This means 'make rpm' no longer works on Fedora rawhide,
and that other distributions such as Debian sid are silently
disabling the sd_notify() feature.

Switch from libsystemd-daemon to libsystemd.

Andrea Bolognani (3):
  maint: Use libsystemd instead of libsystemd-daemon
  spec: Enable libsystemd on Fedora >= 21, RHEL >= 7
  systemd: Guard the call to sd_notify() properly

 configure.ac                                      |  4 ++--
 libvirt.spec.in                                   | 18 +++++++++++-------
 m4/{virt-systemd-daemon.m4 => virt-libsystemd.m4} | 14 +++++++-------
 src/Makefile.am                                   |  4 ++--
 src/util/virsystemd.c                             |  4 ++--
 5 files changed, 24 insertions(+), 20 deletions(-)
 rename m4/{virt-systemd-daemon.m4 => virt-libsystemd.m4} (73%)

--

-- 
2.5.5

Peter Krempa | 27 May 14:21 2016
Picon

[libvirt] [PATCH v2 00/10] Add domain config validation infrastructure

Similarly to post parse callbacks let's add infrastructure that will allow us
to introduce checks that will reject configrations that were previously valid.

This is achieved by flagging all the entry points to the config parser that need
to ignore invadid configurations and adding a callback infrastructure for 
driver specific checks.

Peter Krempa (10):
  conf: Rename VIR_DOMAIN_DEF_PARSE_VALIDATE to
    VIR_DOMAIN_DEF_PARSE_VALIDATE_SCHEMA
  conf: Add infrastructure for adding configuration validation
  conf: drop 'def' from struct virDomainDefPostParseDeviceIteratorData
  conf: Add device def validation callback
  qemu: process: Unexport qemuProcessStartValidate
  qemu: process: Convert multiple boolean args to a single flag
  qemu: process: Call the domain config validator when starting a new VM
  conf: Move disk info validator to the domain conf validator
  conf: Move validation of disk LUN device to the appropriate place
  qemu: Move check that validates 'min_guarantee' to
    qemuDomainDefValidate

 src/bhyve/bhyve_driver.c      |   4 +-
 src/conf/domain_conf.c        | 225 ++++++++++++++++++++++++++++++++++--------
 src/conf/domain_conf.h        |  31 +++++-
 src/conf/snapshot_conf.c      |   3 +-
 src/conf/virdomainobjlist.c   |   6 +-
 src/esx/esx_driver.c          |   2 +-
 src/libvirt_private.syms      |   2 +-
 src/libxl/libxl_domain.c      |   3 +-
 src/libxl/libxl_driver.c      |  10 +-
(Continue reading)

Katerina Koukiou | 27 May 11:23 2016

[libvirt] [PATCH] lxc: Fix virLXCDomainObjBeginJob position in lxcDomainSetMemoryParameters

Adjust the code to perform the virLXCDomainObjBeginJob first
and then the call virDomainLiveConfigHelperMethod.
As Ján Tomko pointed out, in virDomainLiveConfigHelperMethod,
there is a check to see if the domain is active when AFFECT_LIVE is set.
Since virLXCDomainObjBeginJob unlocks the virDomainObjPtr lock,
the domain could possibly be destroyed while we wait for the job
and the check results would no longer be valid.

Signed-off-by: Katerina Koukiou <k.koukiou <at> gmail.com>
---
 src/lxc/lxc_driver.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c
index 3aadd64..f883ffb 100644
--- a/src/lxc/lxc_driver.c
+++ b/src/lxc/lxc_driver.c
 <at>  <at>  -841,14 +841,16  <at>  <at>  lxcDomainSetMemoryParameters(virDomainPtr dom,
     cfg = virLXCDriverGetConfig(driver);

     if (virDomainSetMemoryParametersEnsureACL(dom->conn, vm->def, flags) < 0 ||
-        !(caps = virLXCDriverGetCapabilities(driver, false)) ||
-        virDomainLiveConfigHelperMethod(caps, driver->xmlopt,
-                                        vm, &flags, &vmdef) < 0)
+        !(caps = virLXCDriverGetCapabilities(driver, false)))
         goto cleanup;

     if (virLXCDomainObjBeginJob(driver, vm, LXC_JOB_MODIFY) < 0)
         goto cleanup;

(Continue reading)

Nikolay Shirokovskiy | 27 May 10:05 2016

[libvirt] [PATCH 0/3] add option to keep nvram file on undefine

  There is already a patch [1] on this topic with a different approach - keep
nvram file by default. There is also some discussion there. To sum up keeping
nvram on undefine could be useful in some usecases so there should be an option
to do it. On the other hand there is a danger of leaving domain assets after
its undefine and unsing them unintentionally on defining domain with the same
name.

  AFAIU keeping nvram by default was motivated by domain disks behaviour.
I think there is a difference as libvirt never create disks for domain as
opposed to nvram and managed save and without disks domain will not start so
user is quite aware of disks files. On the other hand one can start using nvram
file solely putting <nvram> in config and managed save is created on daemon
shutdown. So user is much less aware of nvram and managed save existence. Thus
one can easily mess up by unaware define $name/using/undefine/define $name again
usecase. Thus I vote for keeping said assets only if it is specified explicitly
so user knows what he is doing.

  Adding option to undefine is best solution I come up with. The other options
are add checks on define or start and both are impossible. Such a check should
be done without any extra flags for it to be useful but this way we break
existing users.

  As this a proof of concept this series does not add extra flag for managed save.

[1] https://www.redhat.com/archives/libvir-list/2015-February/msg00915.html

Nikolay Shirokovskiy (3):
  api: add VIR_DOMAIN_UNDEFINE_KEEP_NVRAM flag
  qemu: add VIR_DOMAIN_UNDEFINE_KEEP_NVRAM support
  virsh: add --keep-nvram option to undefine command
(Continue reading)

John Ferlan | 26 May 23:52 2016
Picon

[libvirt] [PATCH 0/3] Clean up some virstorageencryption code

While working through adding luks support for libvirt, I have a few patches
that aren't really germane to adding support and rather than drop a large
patch series when I'm done - I figured I'd post a few adjustments.

In the long run the encryption code probably doesn't work, but I'm trying
to move it to the side at least.

John Ferlan (3):
  util: Clean up code formatting in virstorageencryption
  storage: Split out setting default secret for encryption
  storage: Split out a helper for encryption checks

 src/storage/storage_backend.c    | 80 ++++++++++++++++++++++++++--------------
 src/storage/storage_backend_fs.c | 79 ++++++++++++++++++++++++---------------
 src/util/virstorageencryption.c  | 58 ++++++++++++++---------------
 3 files changed, 128 insertions(+), 89 deletions(-)

--

-- 
2.5.5

Artur Zochniak | 26 May 20:20 2016
Picon
Gravatar

[libvirt] New account at Wiki

Hello! 

Can I have an account for wiki? 
I ask here because I am following http://wiki.libvirt.org/page/Main_Page#libvirt_Wiki

preferred username: arjamizo

Thanks!

BR
Artur
<div><div dir="ltr">
<div>Hello!&nbsp;</div>
<div><br></div>
<div>Can I have an account for wiki?&nbsp;</div>
<div>I ask here because I am following <a href="http://wiki.libvirt.org/page/Main_Page#libvirt_Wiki">http://wiki.libvirt.org/page/Main_Page#libvirt_Wiki</a>
</div>
<div><br></div>
<div>preferred username: arjamizo</div>
<div><br></div>
<div>Thanks!</div>
<div><br></div>
<div>BR</div>
<div>Artur</div>
</div></div>

Gmane