[libvirt] [PATCH] news: Fix xml dump of autogenerated websocket

[Nikolay Shirokovskiy]

---

Sorry for delay and thus not getting this news bit into release notes
in time.

 docs/news.xml | 9 +
 1 file changed, 9 insertions(+)

diff --git a/docs/news.xml b/docs/news.xml
index 95b021a..3ff8f4e 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -274,6 +274,15 @@
   for x86_64 HVM domains.
 
   
+  
+
+  qemu: Fix xml dump of autogenerated websocket
+
+
+  As a result autogenerated websocket port is regenerated on domain 
restore,
+  migration and such as it should be.
+
+  
 
   
   
-- 
1.8.3.1

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

[libvirt] [ libvirt-python BUG ?] Memory leak in libvirt_virConnectDomainEventJobCompletedCallback

[Hailiang Zhang]

Hi all,

It seems that, there is a memory leak bug in 
libvirt_virConnectDomainEventJobCompletedCallback()
function of libvirt-override.c.

We didn't decrease the reference of 'pyobj_dict' in this function or any other 
places
while pyt0bj_ret is not zero.

libvirt_virConnectDomainEventJobCompletedCallback()
{
  ... ...

  pyobj_ret = PyObject_CallMethod(pyobj_conn,

(char*)"_dispatchDomainEventJobCompletedCallback",
(char*)"OOO",
pyobj_dom, pyobj_dict, pyobj_cbData);

Py_DECREF(pyobj_cbData);
Py_DECREF(pyobj_dom);

 cleanup:
if (!pyobj_ret) {
DEBUG("%s - ret:%p\n", __FUNCTION__, pyobj_ret);
PyErr_Print();
Py_XDECREF(pyobj_dict);
} else {
Py_DECREF(pyobj_ret);
ret = 0;
}

LIBVIRT_RELEASE_THREAD_STATE;
return ret;
}

I don't think the reference of pyobj_dict will be stolen by PyObject_CallMethod
when it is passed to the Python function 
_dispatchDomainEventJobCompletedCallback.

In fact, we have a test which triggered lots of events and found that the memory
of the test process will keep raising slowly and could not be reclaimed
even we called gc.collect() explicitly in our codes.

So, is it a bug ? Any comments ?

Thanks,
hailiang


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

Re: [libvirt] Release of libvirt-3.0.0

[Christian Borntraeger]

On 01/17/2017 07:40 PM, Daniel Veillard wrote:
>   So I got mixed reports in the last day about the state of the head
> but one of the big issues seems solved, and I'm not sure keeping the
> freeze much longer will help, so libvirt-3.0.0 is out. It's tagged in
> git, signed tarball and rpms are available at thet usual place:

Very unfortunate.
Can we please spin a 3.0.1 with namespaces disabled soon?

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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Boris Fiuczynski]

On 01/17/2017 05:39 PM, Daniel P. Berrange wrote:

I'm thinking we've hit the limit of what we should try to force into the
3.0.0 release.

My vote at this poiint is to change the code so that namespaces are
disabled out of the box, and do a 3.0.0 release. Look at fixing the
bugs to turn it back on by default in 3.1.0


Daniel, I totally agree with your voting!
As it looks this morning 3.0.0 has been released and namespaces have not 
been disabled.

Have they been left enabled intentionally?

--
Mit freundlichen Grüßen/Kind regards
   Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

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

[libvirt] [PATCH 0/2] *** Expose host's cache information in capabilities ***

[Eli Qiao]

This series patches are the first step to support CAT featues, which also
called cache tune in libvirt.

First to expose cache information which could be tuned in capabilites XML,
later will add some more interface to do cache tune.

Some discussion about this feature support can be found from:
https://www.redhat.com/archives/libvir-list/2017-January/msg00644.html

Eli Qiao (2):
  Resctrl: Add some utils functions
  Resctrl: expose cache information to capabilities

 include/libvirt/virterror.h  |   1 +
 src/Makefile.am  |   1 +
 src/conf/capabilities.c  |  30 +++
 src/conf/capabilities.h  |  15 ++
 src/libvirt_private.syms |   5 +
 src/qemu/qemu_capabilities.c |  42 
 src/qemu/qemu_driver.c   |   4 +
 src/util/virerror.c  |   1 +
 src/util/virresctrl.c| 500 +++
 src/util/virresctrl.h| 121 +++
 tests/Makefile.am|   4 +
 11 files changed, 724 insertions(+)
 create mode 100644 src/util/virresctrl.c
 create mode 100644 src/util/virresctrl.h

--
1.9.1

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

[libvirt] [PATCH 2/2] Resctrl: expose cache information to capabilities

[Eli Qiao]

This patch expose cache information to host's capabilites xml.








There are some nits difference from RFC on mailing list.
https://www.redhat.com/archives/libvir-list/2017-January/msg00644.html

Signed-off-by: Eli Qiao 
---
 src/conf/capabilities.c  | 30 ++
 src/conf/capabilities.h  | 15 +++
 src/libvirt_private.syms |  1 +
 src/qemu/qemu_capabilities.c | 42 ++
 src/qemu/qemu_driver.c   |  4 
 5 files changed, 92 insertions(+)

diff --git a/src/conf/capabilities.c b/src/conf/capabilities.c
index 9ab343b..26aef73 100644
--- a/src/conf/capabilities.c
+++ b/src/conf/capabilities.c
@@ -844,6 +844,31 @@ virCapabilitiesFormatNUMATopology(virBufferPtr buf,
 return 0;
 }
 
+static int
+virCapabilitiesFormatCache(virBufferPtr buf,
+   size_t ncachebank,
+   virCapsHostCacheBankPtr *cachebank)
+{
+size_t i;
+
+virBufferAddLit(buf, "\n");
+virBufferAdjustIndent(buf, 2);
+
+for( i = 0 ; i < ncachebank; i++) {
+virBufferAsprintf(buf,
+  "\n",
+  cachebank[i]->id,
+  cachebank[i]->type,
+  cachebank[i]->size,
+  cachebank[i]->cpus,
+  cachebank[i]->min,
+  cachebank[i]->scope);
+}
+virBufferAdjustIndent(buf, -2);
+virBufferAddLit(buf, "\n");
+return 0;
+}
+
 /**
  * virCapabilitiesFormatXML:
  * @caps: capabilities to format
@@ -931,6 +956,11 @@ virCapabilitiesFormatXML(virCapsPtr caps)
 virBufferAddLit(&buf, "\n");
 }
 
+if (caps->host.ncachebank &&
+virCapabilitiesFormatCache(&buf, caps->host.ncachebank,
+   caps->host.cachebank) < 0)
+return NULL;
+
 if (caps->host.netprefix)
 virBufferAsprintf(&buf, "%s\n",
   caps->host.netprefix);
diff --git a/src/conf/capabilities.h b/src/conf/capabilities.h
index cfdc34a..b9f4633 100644
--- a/src/conf/capabilities.h
+++ b/src/conf/capabilities.h
@@ -138,6 +138,17 @@ struct _virCapsHostSecModel {
 virCapsHostSecModelLabelPtr labels;
 };
 
+typedef struct _virCapsHostCacheBank virCapsHostCacheBank;
+typedef virCapsHostCacheBank *virCapsHostCacheBankPtr;
+struct _virCapsHostCacheBank {
+unsigned int id;
+char* type;
+char* cpus;
+unsigned long long size;
+unsigned long long min;
+char* scope;
+};
+
 typedef struct _virCapsHost virCapsHost;
 typedef virCapsHost *virCapsHostPtr;
 struct _virCapsHost {
@@ -160,6 +171,10 @@ struct _virCapsHost {
 size_t nsecModels;
 virCapsHostSecModelPtr secModels;
 
+size_t ncachebank;
+size_t ncachebank_max;
+virCapsHostCacheBankPtr *cachebank;
+
 char *netprefix;
 virCPUDefPtr cpu;
 int nPagesSize; /* size of pagesSize array */
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index fe1334d..bdd717a 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2298,6 +2298,7 @@ virRandomInt;
 # util/virresctrl.h
 virResCtrlAvailable;
 virResCtrlInit;
+virResCtrlGet;
 
 # util/virrotatingfile.h
 virRotatingFileReaderConsume;
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 5427059..99cc7ce 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -45,6 +45,7 @@
 #include "qemu_domain.h"
 #define __QEMU_CAPSRIV_H_ALLOW__
 #include "qemu_capspriv.h"
+#include "virresctrl.h"
 
 #include 
 #include 
@@ -1093,7 +1094,45 @@ virQEMUCapsInitCPU(virCapsPtr caps,
 goto cleanup;
 }
 
+static int
+virQEMUCapsInitCache(virCapsPtr caps)
+{
+int i, j;
+unsigned bk_id = 0;
+virResCtrlPtr resctrl;
+virCapsHostCacheBankPtr bank;
 
+for (i = 0; i < RDT_NUM_RESOURCES; i ++)
+{
+resctrl = virResCtrlGet(i);
+if(resctrl->enabled) {
+for( j = 0; j < resctrl->num_sockets; j++)
+{
+if(VIR_RESIZE_N(caps->host.cachebank, 
caps->host.ncachebank_max,
+caps->host.ncachebank, 1) < 0)
+return -1;
+
+if(VIR_ALLOC(bank) < 0)
+return -1;
+
+bank->id = bk_id++;
+if(VIR_STRDUP(bank->type, resctrl->cache_level) < 0)
+goto err;
+if(VIR_STRDUP(bank->scope, resctrl->name) < 0)
+goto err;
+if(VIR_STRDUP(bank->cpus, 
virBitmapFormat(resctrl->cpu_mask[j])) < 0)
+goto err;
+bank->size = resctrl->cache_size[j];
+bank->min = resctrl->cache_min[j];
+caps->host.cachebank[caps->host.ncachebank++] = bank;
+}
+}
+}
+return 0;
+err:
+VIR_FREE(bank);
+return -1;
+}
 static int
 virQEMUCapsInitPages(virCa

[libvirt] [PATCH 1/2] Resctrl: Add some utils functions

[Eli Qiao]

This patch adds some utils struct and functions to expose resctrl
information.

virResCtrlAvailable: If resctrl interface exist on host
virResCtrlGet: get specify type resource contral information
virResCtrlInit: initialize resctrl struct from the host's sys fs.
ResCtrlAll[]: an array to maintain resource contral information.

Signed-off-by: Eli Qiao 
---
 include/libvirt/virterror.h |   1 +
 src/Makefile.am |   1 +
 src/libvirt_private.syms|   4 +
 src/util/virerror.c |   1 +
 src/util/virresctrl.c   | 500 
 src/util/virresctrl.h   | 121 +++
 tests/Makefile.am   |   4 +
 7 files changed, 632 insertions(+)
 create mode 100644 src/util/virresctrl.c
 create mode 100644 src/util/virresctrl.h

diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h
index 2efee8f..3dd2d08 100644
--- a/include/libvirt/virterror.h
+++ b/include/libvirt/virterror.h
@@ -132,6 +132,7 @@ typedef enum {
 
 VIR_FROM_PERF = 65, /* Error from perf */
 VIR_FROM_LIBSSH = 66,   /* Error from libssh connection transport */
+VIR_FROM_RESCTRL = 67,  /* Error from resource control */
 
 # ifdef VIR_ENUM_SENTINELS
 VIR_ERR_DOMAIN_LAST
diff --git a/src/Makefile.am b/src/Makefile.am
index d84c984..4026f8d 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -162,6 +162,7 @@ UTIL_SOURCES =  
\
util/virprocess.c util/virprocess.h \
util/virqemu.c util/virqemu.h   \
util/virrandom.h util/virrandom.c   \
+   util/virresctrl.h util/virresctrl.c \
util/virrotatingfile.h util/virrotatingfile.c   \
util/virscsi.c util/virscsi.h   \
util/virscsivhost.c util/virscsivhost.h \
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 2d23e46..fe1334d 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2295,6 +2295,10 @@ virRandomGenerateWWN;
 virRandomInt;
 
 
+# util/virresctrl.h
+virResCtrlAvailable;
+virResCtrlInit;
+
 # util/virrotatingfile.h
 virRotatingFileReaderConsume;
 virRotatingFileReaderFree;
diff --git a/src/util/virerror.c b/src/util/virerror.c
index ef17fb5..93dfd4f 100644
--- a/src/util/virerror.c
+++ b/src/util/virerror.c
@@ -139,6 +139,7 @@ VIR_ENUM_IMPL(virErrorDomain, VIR_ERR_DOMAIN_LAST,
 
   "Perf", /* 65 */
   "Libssh transport layer",
+  "Rescouce Control",
 )
 
 
diff --git a/src/util/virresctrl.c b/src/util/virresctrl.c
new file mode 100644
index 000..bcb47f1
--- /dev/null
+++ b/src/util/virresctrl.c
@@ -0,0 +1,500 @@
+/*
+ * virresctrl.c: methods for managing resource contral
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library.  If not, see
+ * .
+ *
+ * Authors:
+ *  Eli Qiao 
+ */
+#include 
+
+#include 
+#if defined HAVE_SYS_SYSCALL_H
+# include 
+#endif
+#include 
+#include 
+#include 
+
+#include "virresctrl.h"
+#include "viralloc.h"
+#include "virerror.h"
+#include "virfile.h"
+#include "virhostcpu.h"
+#include "virlog.h"
+#include "virstring.h"
+#include "nodeinfo.h"
+
+VIR_LOG_INIT("util.resctrl");
+
+#define VIR_FROM_THIS VIR_FROM_RESCTRL
+
+#define CONSTRUCT_RESCTRL_PATH(domain_name, item_name) \
+do { \
+if (NULL == domain_name) { \
+if (asprintf(&path, "%s/%s", RESCTRL_DIR, item_name) < 0)\
+return -1; \
+} \
+else { \
+if (asprintf(&path, "%s/%s/%s", RESCTRL_DIR, \
+domain_name, \
+item_name) < 0) \
+return -1;  \
+} \
+} while(0)
+
+static virResCtrl ResCtrlAll[] = {
+{
+.name = "L3",
+.domains = NULL,
+.cache_level = "l3",
+},
+{
+.name = "L3DATA",
+.domains = NULL,
+.cache_level = "l3",
+},
+{
+.name = "L3CODE",
+.domains = NULL,
+.cache_level = "l3",
+},
+{
+.name = "L2",
+.domains = NULL,
+.cache_level = "l2",
+},
+};
+
+/* Return pointer of  and ncount of schemata*/
+static virResSchemataPtr virParseSchemata(const char* schemata, int *ncount)
+{
+char type[MAX_SCHEMATA_LEN];
+const char *p, *q;
+ 

[libvirt] [PATCH] virsh: Modify description for LIBVIRT_DEBUG=4 in manpage

[Nitesh Konkar]

As LIBVIRT_DEBUG=4 logs only error messages and there
are no levels above it, adjusting the description in
the man page accordingly.

Signed-off-by: Nitesh Konkar 
---
 tools/virsh.pod | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/virsh.pod b/tools/virsh.pod
index c1bdbdd..9e45f09 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -4565,7 +4565,7 @@ Messages at level WARNING or above
 
 =item * LIBVIRT_DEBUG=4
 
-Messages at level ERROR or above
+Messages at level ERROR
 
 =back
 
-- 
1.9.3

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

Re: [libvirt] vms hung

[Umar Draz]

Hi Michal,

Well right now all the vms running fine, and this vm hung issue happening
occasionally. The following out put is one of my running VM

[root@kvm03 ~]# virsh qemu-monitor-command w7-DRAC
'{"execute":"query-status"}'
{"return":{"status":"running","singlestep":false,"running":true},"id":"libvirt-17597"}

-- Umar


On Tue, Jan 17, 2017 at 8:10 PM, Michal Privoznik 
wrote:

> On 01/16/2017 04:13 PM, Umar Draz wrote:
> > Hello,
> >
> > I am running libvirt-2.0.0-10.el7_3.2.x86_64 on CentOS 7.3, I have few
> vms
> > of CentOS and Windows 2012 servers.
> >
> > Randomly they are hung, but the status of virtual machine keep running,
> vnc
> > and network not responding.
> >
> > I have checked all /var/log/messages and /var/log/libvirt/qemu/vm.log but
> > nothing found anything wrong.
> >
> > Would you please help what should I do more so I can find the issue.
> >
> > -- Umar
> >
>
> What state is qemu process in? You may try to "ping" qemu on the monitor:
>
> virsh qemu-monitor-command $dom '{"execute":"query-status"}'
>
> But this sounds like a qemu bug to me.
>
> Michal
>
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH resend v2 2/2] virsh: introduce flage --direct for save command

[Chen Hanxiao]

From: Chen Hanxiao 

Base upon patches from Roy Keene 

This patch introduces --direct flag for save command.

We could use this flag to save vm to a PIPE.

We could saving a VM state directly to Ceph RBD images
without having an intermediate file.

How to test:
fifo="$(mktemp -u)"; mkfifo "${fifo}" && virsh save --pipe cirros  "${fifo}" &
cat "${fifo}" | rbd --id cinder import - hotsnapshot/test1234 & wait; rm -f 
"${fifo}"

Signed-off-by: Roy Keene 
Signed-off-by: Chen Hanxiao 
---
v2-resend:
  rebase on upstream

v2:
  rename VIR_DOMAIN_SAVE_PIPE to VIR_DOMAIN_SAVE_DIRECT
 tools/virsh-domain.c | 6 ++
 tools/virsh.pod  | 5 -
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 93587e8..88492e0 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -4187,6 +4187,10 @@ static const vshCmdOptDef opts_save[] = {
  .type = VSH_OT_BOOL,
  .help = N_("set domain to be paused on restore")
 },
+{.name = "direct",
+ .type = VSH_OT_BOOL,
+ .help = N_("write the file directly, needed by PIPE/FIFO")
+},
 {.name = "verbose",
  .type = VSH_OT_BOOL,
  .help = N_("display the progress of save")
@@ -4223,6 +4227,8 @@ doSave(void *opaque)
 flags |= VIR_DOMAIN_SAVE_RUNNING;
 if (vshCommandOptBool(cmd, "paused"))
 flags |= VIR_DOMAIN_SAVE_PAUSED;
+if (vshCommandOptBool(cmd, "direct"))
+flags |= VIR_DOMAIN_SAVE_DIRECT;
 
 if (vshCommandOptStringReq(ctl, cmd, "xml", &xmlfile) < 0)
 goto out;
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 0e434c0..25cfce3 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -1896,7 +1896,7 @@ have also reverted all storage volumes back to the same 
contents as when
 the state file was created.
 
 =item B I I [I<--bypass-cache>] [I<--xml> B]
-[{I<--running> | I<--paused>}] [I<--verbose>]
+[{I<--running> | I<--paused>}] [I<--direct>] [I<--verbose>]
 
 Saves a running domain (RAM, but not disk state) to a state file so that
 it can be restored
@@ -1911,6 +1911,9 @@ with B command (sent by another virsh 
instance). Another option
 is to send SIGINT (usually with C) to the virsh process running
 B command. I<--verbose> displays the progress of save.
 
+Usually B command will save the domain's state as a regular file.
+If you want to save it into a PIPE/FIFO, then flag I<--direct> must be set.
+
 This is roughly equivalent to doing a hibernate on a running computer,
 with all the same limitations.  Open network connections may be
 severed upon restore, as TCP timeouts may have expired.
-- 
2.7.4


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

[libvirt] [PATCH resend v2 0/2] Allow saving QEMU libvirt state to a pipe

[Chen Hanxiao]

This series introduce flag VIR_DOMAIN_SAVE_DIRECT
to enable command 'save' to write to PIPE.

Base upon patches from Roy Keene 
with some fixes.

Change from original patch:
1) Check whether the specified path is a PIPE.
2) Rebase on upstream.
3) Add doc for virsh command

v2-resend:
  rebase on upstream
v2:
  rename VIR_DOMAIN_SAVE_PIPE to VIR_DOMAIN_SAVE_DIRECT
  remove S_ISFIFO check


Chen Hanxiao (2):
  qemu: Allow saving QEMU libvirt state to a pipe
  virsh: introduce flage --direct for save command

 include/libvirt/libvirt-domain.h |  1 +
 src/qemu/qemu_driver.c   | 54 ++--
 tools/virsh-domain.c |  6 +
 tools/virsh.pod  |  5 +++-
 4 files changed, 47 insertions(+), 19 deletions(-)

-- 
2.7.4


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

[libvirt] [PATCH resend v2 1/2] qemu: Allow saving QEMU libvirt state to a pipe

[Chen Hanxiao]

From: Chen Hanxiao 

Base upon patches from Roy Keene 

Currently qemuDomainSaveMemory can save vm's config
and memory to fd.
It write a magic QEMU_SAVE_PARTIAL firstly,
then re-open it to change QEMU_SAVE_PARTIAL as QEMU_SAVE_MAGIC.

For pipes this is not possible, attempting to re-open the pipe
will not connect you to the same consumer.
Seeking is also not possible on a pipe.

This patch introduce VIR_DOMAIN_SAVE_DIRECT
If set, write QEMU_SAVE_MAGIC directly.

This is useful to me for saving a VM state directly to
Ceph RBD images without having an intermediate file.

Signed-off-by: Roy Keene 
Signed-off-by: Chen Hanxiao 
---
v2-resend:
  rebase on upstream

v2:
  rename VIR_DOMAIN_SAVE_PIPE to VIR_DOMAIN_SAVE_DIRECT
  remove S_ISFIFO check for dst path
 include/libvirt/libvirt-domain.h |  1 +
 src/qemu/qemu_driver.c   | 54 ++--
 2 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
index e303140..b28b9a4 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -1169,6 +1169,7 @@ typedef enum {
 VIR_DOMAIN_SAVE_BYPASS_CACHE = 1 << 0, /* Avoid file system cache 
pollution */
 VIR_DOMAIN_SAVE_RUNNING  = 1 << 1, /* Favor running over paused */
 VIR_DOMAIN_SAVE_PAUSED   = 1 << 2, /* Favor paused over running */
+VIR_DOMAIN_SAVE_DIRECT   = 1 << 3, /* Write QEMU_SAVE_MAGIC directly */
 } virDomainSaveRestoreFlags;
 
 int virDomainSave   (virDomainPtr domain,
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index d4422f3..e44d0c6 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3059,6 +3059,7 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
 virQEMUSaveHeader header;
 bool bypassSecurityDriver = false;
 bool needUnlink = false;
+bool canReopen = true;
 int ret = -1;
 int fd = -1;
 int directFlag = 0;
@@ -3066,7 +3067,6 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
 unsigned int wrapperFlags = VIR_FILE_WRAPPER_NON_BLOCKING;
 
 memset(&header, 0, sizeof(header));
-memcpy(header.magic, QEMU_SAVE_PARTIAL, sizeof(header.magic));
 header.version = QEMU_SAVE_VERSION;
 header.was_running = was_running ? 1 : 0;
 header.compressed = compressed;
@@ -3082,6 +3082,7 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
 goto cleanup;
 }
 }
+
 fd = qemuOpenFile(driver, vm, path,
   O_WRONLY | O_TRUNC | O_CREAT | directFlag,
   &needUnlink, &bypassSecurityDriver);
@@ -3094,6 +3095,20 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
 if (!(wrapperFd = virFileWrapperFdNew(&fd, path, wrapperFlags)))
 goto cleanup;
 
+/* Set the header magic.
+ * Setting flags VIR_DOMAIN_SAVE_DIRECT will write
+ * magic QEMU_SAVE_MAGIC directly.
+ * For PIPE, we should do this because it can't be reopen.
+ * Otherwise we'll update the magic after
+ * the saving completes successfully.
+ */
+if (flags & VIR_DOMAIN_SAVE_DIRECT) {
+canReopen = false;
+memcpy(header.magic, QEMU_SAVE_MAGIC, sizeof(header.magic));
+} else {
+memcpy(header.magic, QEMU_SAVE_PARTIAL, sizeof(header.magic));
+}
+
 /* Write header to file, followed by XML */
 if (qemuDomainSaveHeader(fd, path, domXML, &header) < 0)
 goto cleanup;
@@ -3102,28 +3117,30 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
 if (qemuMigrationToFile(driver, vm, fd, compressedpath, asyncJob) < 0)
 goto cleanup;
 
-/* Touch up file header to mark image complete. */
+if (canReopen) {
+/* Touch up file header to mark image complete. */
 
-/* Reopen the file to touch up the header, since we aren't set
- * up to seek backwards on wrapperFd.  The reopened fd will
- * trigger a single page of file system cache pollution, but
- * that's acceptable.  */
-if (VIR_CLOSE(fd) < 0) {
-virReportSystemError(errno, _("unable to close %s"), path);
-goto cleanup;
-}
+/* Reopen the file to touch up the header, since we aren't set
+* up to seek backwards on wrapperFd.  The reopened fd will
+* trigger a single page of file system cache pollution, but
+* that's acceptable.  */
+if (VIR_CLOSE(fd) < 0) {
+virReportSystemError(errno, _("unable to close %s"), path);
+goto cleanup;
+}
 
-if (virFileWrapperFdClose(wrapperFd) < 0)
-goto cleanup;
+if (virFileWrapperFdClose(wrapperFd) < 0)
+goto cleanup;
 
-if ((fd = qemuOpenFile(driver, vm, path, O_WRONLY, NULL, NULL)) < 0)
-goto cleanup;
+if ((fd = qemuOpenFile(driver, vm, path, O_WRONLY, NULL, NULL)) < 0)
+goto cleanup;
 
-memcpy(header.magic, QEMU_SAVE_MAGIC, sizeof(header.magic));
+memcpy(header.magic, QEMU_S

Re: [libvirt] [PATCH v2] Add support for Veritas HyperScale (VxHS) block device protocol

[ashish mittal]

On Mon, Jan 16, 2017 at 1:10 AM, Daniel P. Berrange  wrote:
> On Sat, Jan 14, 2017 at 10:31:05AM -0500, John Ferlan wrote:
>> [...]
>>
>> >> diff --git 
>> >> a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args 
>> >> b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args
>> >> new file mode 100644
>> >> index 000..f6e3e37
>> >> --- /dev/null
>> >> +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args
>> >> @@ -0,0 +1,24 @@
>> >> +LC_ALL=C \
>> >> +PATH=/bin \
>> >> +HOME=/home/test \
>> >> +USER=test \
>> >> +LOGNAME=test \
>> >> +QEMU_AUDIO_DRV=none \
>> >> +/usr/libexec/qemu-kvm \
>> >> +-name QEMUGuest1 \
>> >> +-S \
>> >> +-M pc \
>> >> +-cpu qemu32 \
>> >> +-m 214 \
>> >> +-smp 1,sockets=1,cores=1,threads=1 \
>> >> +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
>> >> +-nographic \
>> >> +-nodefaults \
>> >> +-monitor unix:/tmp/lib/domain--1-QEMUGuest1/monitor.sock,server,nowait \
>> >> +-no-acpi \
>> >> +-boot c \
>> >> +-usb \
>> >> +-drive 
>> >> file=vxhs://192.168.0.1:/eb90327c-8302-4725-9e1b-4e85ed4dc251,\
>> >> +format=raw,if=none,id=drive-virtio-disk0,cache=none \
>> >
>> > Please use the modern syntax for disk specification, not the
>> > legacy URI syntax  ie
>> >
>> >   -drive  driver=vxhs,vdisk-id=eb90327c-8302-4725-4e85ed4dc251,\
>> >   server.host=example.com,server.port=12345,format=raw,
>> >   if=none,id=driver-virtio-disk0,cache=0
>> >
>>
>> FWIW: qemuBuildDriveStr doesn't support that yet for any driver -
>> although it probably should be updated... Timing wise whether that work
>> could get done before this work is ready - I'm not sure. While I agree
>> the code "should" use the new syntax - I do think we'd have to make
>> adjustments to all drive strings. That would probably mean knowing
>> whether the new syntax was "in place" before the current libvirt qemu
>> minimum version...
>
> The pre-existing drivers in libvirt need to support both new & old syntax,
> in order that we have compat with older QEMU versions. As a brand new driver,
> IMHO, VXHS must support the new syntax exclusively - there's no reason to
> use the old syntax. We don't need to convert all existing drivers to the
> new syntax at the same time, but the VHXS patch can start the trend.
>

Sometime back, during the qemu patch discussion, we had agreed to have
support for both URI syntax and also the QAPI syntax within qemu. It
was also decided to limit the URI syntax to supporting only one host
server, and use the QAPI exclusively for more than one servers.

Now that the failover code has moved from qemu to libqnio, vxhs will
accept only one server. Failover will be handled entirely within
libqnio. Given that gluster is the only network protocol that supports
the new syntax, and that too only for the case when more than one
servers are specified, would it be acceptable if vxhs goes with the
URI syntax for now? We could add support for the new syntax to vxhs
later when doing it for the other protocols!

Thanks!

> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

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

Re: [libvirt] [PATCH v2] Add support for Veritas HyperScale (VxHS) block device protocol

[ashish mittal]

On Mon, Jan 16, 2017 at 5:48 AM, John Ferlan  wrote:
>
>
> On 01/16/2017 04:07 AM, Peter Krempa wrote:
>> On Sat, Jan 14, 2017 at 10:31:05 -0500, John Ferlan wrote:
>>> [...]
>>>
> diff --git 
> a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args 
> b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args
> new file mode 100644
> index 000..f6e3e37
> --- /dev/null
> +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-vxhs.args
>>
>> [...]
>>
> +-drive 
> file=vxhs://192.168.0.1:/eb90327c-8302-4725-9e1b-4e85ed4dc251,\
> +format=raw,if=none,id=drive-virtio-disk0,cache=none \

 Please use the modern syntax for disk specification, not the
 legacy URI syntax  ie

   -drive  driver=vxhs,vdisk-id=eb90327c-8302-4725-4e85ed4dc251,\
   server.host=example.com,server.port=12345,format=raw,
   if=none,id=driver-virtio-disk0,cache=0

>>>
>>> FWIW: qemuBuildDriveStr doesn't support that yet for any driver -
>>> although it probably should be updated... Timing wise whether that work
>>> could get done before this work is ready - I'm not sure. While I agree
>>> the code "should" use the new syntax - I do think we'd have to make
>>> adjustments to all drive strings. That would probably mean knowing
>>> whether the new syntax was "in place" before the current libvirt qemu
>>> minimum version...
>>
>> That's not true. The new syntax is used for multi-host gluster disks
>> (qemuGetDriveSourceProps). Also we have QMP introspection code in place
>> which can detect whether given configuration option is supported by the
>> given qemu (virQEMUCapsQMPSchemaQueries[]).
>
> hmm.. missed that path - it's not exactly well described how to get
> there though. Suffice to say, well obfuscated.
>
> I see that the syntax built for the gluster is "-drive
> file.driver=gluster,..." though rather than just plain "-drive
> driver=gluster,...". Whether vxhs would need to follow that model or the
> one Daniel pointed out - I'm not quite sure.
>
> In any case, to help "find" that for the Veritas team - see commit id
> '7b7da9e28'... If you use gitk - the commits just before that are where
> Peter has modified qemuBuildDriveSourceStr in order to accept a json
> object to parse through in order to generate the newer syntax. In those
> changes there is also the adjustment to the gluster backend storage code
> to support the newer model - something that could be a model once/if a
> vxhs storage backend is created.
>

Thanks for the pointer!

>>
>> Also we should not fully update the command line generator in cases
>> where it's not necessary as it would just make the code more complex
>> without any real benefit. The new protocols can use the new syntax
>> though.
>>
>
> Right - otherwise it'd already be done...
>
> Still would be nice for a non json object path that could generate the
> newer syntax especially since there's nothing else within the vxhs
> command line syntax that would be "unique" such that the command line
> generator had to be changed in order to support it (unlike the
> multi-host gluster disks syntax).
>
> I do know the syntax difference has come into play for the rbd driver
> decision point to add the password-secret and I'm guessing once secret
> support is added for vxhs it'll have a similar issue.
>
> John

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

Re: [libvirt] [PATCH] util: disallow resetting a pci-bridge device

[Laine Stump]

On 01/17/2017 09:51 AM, Shivaprasad G Bhat wrote:

It is distructive to attempt a reset on pci-bridge, the host can crash.
The bridges won't contain any guest data and neither they can be
passed through using vfio/stub. So, no point in allowing a reset for them.

Signed-off-by: Shivaprasad G Bhat 
---
  src/util/virpci.c |   10 ++
  1 file changed, 10 insertions(+)

diff --git a/src/util/virpci.c b/src/util/virpci.c
index 0601f49..860f7aa 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -933,6 +933,16 @@ virPCIDeviceReset(virPCIDevicePtr dev,



This function is a nice centralized place to perform this check, but it 
could lead to an odd error message if someone tried to assign a PCI 
bridge device to a guest - instead of logging "PCI bridge devices can't 
be assigned to guests" (or something like that) it would tell us that we 
can't *reset* the device. Maybe that can be remedied by doing an 
additional check at an earlier stage during virHostdevPreparePCIDevices().




  char *drvName = NULL;
  int ret = -1;
  int fd = -1;
+int hdrType = -1;
+
+if (virPCIGetHeaderType(dev, &hdrType) < 0)
+return -1;
+
+if (hdrType == VIR_PCI_HEADER_PCI_BRIDGE) {



I think we can only reset (or assign) endpoint devices, so how about 
using "hdrType != VIR_PCI_HEADER_ENDPOINT", and then having the error 
message say "Invalid attempt to reset non-endpoint PCI device at 
:xx:xx.x. Only PCI endpoint devices can be reset"




+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+   _("Resetting a pci-bridge device is not allowed"));



Using "pci-bridge" could be confusing, since that's the exact name of a 
particular emulated device in libvirt. The error message should include 
the PCI address of the device, and (as suggested above) just say that it 
isn't an endpoint device, so we can't reset it.




+return -1;
+}
  
  if (activeDevs && virPCIDeviceListFind(activeDevs, dev)) {

  virReportError(VIR_ERR_INTERNAL_ERROR,

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



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

[libvirt] Release of libvirt-3.0.0

[Daniel Veillard]

  So I got mixed reports in the last day about the state of the head
but one of the big issues seems solved, and I'm not sure keeping the
freeze much longer will help, so libvirt-3.0.0 is out. It's tagged in
git, signed tarball and rpms are available at thet usual place:

  ftp://libvirt.org/libvirt/

I also pushed python bindings release too which one can find at

  ftp://libvirt.org/libvirt/python/

It includes a fair amount of changes despite the slowdown around the end of
year break:

 * New features

- Domain events for metadata content changes
The domain events framework has a new event ID that can be used to get
notifications when domain metadata content changes.

- Event notifications for the secret object
The secret object now supports event notifications, covering lifcycle
changes and secret value changes.

- New localPtr attribute for "ip" element in network XML

- qemu: Support QEMU group I/O throttling
Add the capability to allow group I/O throttling via a new domain
  subelement "group_name" to allow sharing I/O throttling
quota between multiple drives.

- nss: Introduce libvirt_guest
New libvirt_guest nss module that translates libvirt guest names into
IP addresses.

- daemon: Add support for runtime logging settings adjustment
Logging-related settings like log outputs and filters can now be
adjusted during runtime using the admin interface without the necessity
of the daemon's restart.

- storage: Add virStorageVolInfoFlags API
Add the API to support using the VIR_STORAGE_VOL_GET_PHYSICAL flag in
order to return the host physical size in bytes of the image container
in the allocation field of the _virStorageVolInfo structure. The
--physical flag has been added to the virsh vol-info command to access
the data.

- libxl: Implement virDomainGetMaxVcpus API

- storage: Add overwrite flag checking for logical pool
Add support for the OVERWRITE flags for the logical storage backend
including checking for existing data on the target volumes when
building a new logical pool on target volume(s).
- qemu: Add support for guest CPU configuration on s390(x)

  * Improvements

- perf: Add more perf statistics
Add support to get the count of branch instructions executed, branch
misses, bus cycles, stalled frontend cpu cycles, stalled backend cpu
cycles, and ref cpu cycles by applications running on the platform.

- conf: Display  for volume xml
Add a display of the  size of a disk volume in the output of
the volume XML.

- qemu: Use virtio-pci by default for aarch64 mach-virt guests
virtio-pci provides several advantages over virtio-mmio, such as the
ability to hotplug devices and improved performance. While opting in to
virtio-pci has been possible for a while, newly-defined guests will now
use it automatically.

- vbox: remove support for VirtualBox 3.x and older
Those old VirtualBox versions have been unsupported by upstream for a
long time and the API of 4.0 and newer has diverged enough to require
code abstractions to handle differences. Removing support for those old
versions drops lots of code from the driver and simplifies the logic to
ease implementation of new features going forward.

- virsh: pool-info: introduce option --bytes
Add option --bytes to virsh pool-info in order ti allow display of
units in bytes rather than default of human readable output.

- scsi: Add parent wwnn/wwpn or fabric capability for createVport
Improve the algorithm searching for the parent scsi_host device for
vHBA/NPIV scsi_host creation. Rather than supplying the "parent" by
name, it's now possible to define the parent by it's wwnn/wwpn or
fabric_wwn in the node device create XML or the storage pool XML.

- qemu: aggregate pcie-root-ports onto multiple functions of a slot
When pcie-root-ports are added to pcie-root in order to provide a place
to connect PCI Express endpoint devices, libvirt now aggregates
multiple root ports together onto the same slot (up to 8 per slot) in
order to conserve slots. Using this method, it's possible to connect
more than 200 endpoint devices to a guest that uses PCIe without
requiring setup of any PCIe switches.

  * Bug fixes

- lxc: fix accidental killing of containers during libvirtd restart
The libvirt_lxc process was previously not moved into the container
scope. As a result, if systemd reloads its config after a container is
started, when libvirtd is later restarted it will accidentally kill the
containers.

- qemu: Correct GetBlockInfo values
For an active domain, correct the physical value provided for a

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Christian Borntraeger]

On 01/17/2017 05:39 PM, Daniel P. Berrange wrote:

> I'm thinking we've hit the limit of what we should try to force into the
> 3.0.0 release.
> 
> My vote at this poiint is to change the code so that namespaces are
> disabled out of the box, and do a 3.0.0 release. Look at fixing the

Ack.

> bugs to turn it back on by default in 3.1.0

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

Re: [libvirt] [PATCH] tests: fix compilation of shunloadtest

[Jim Fehlig]

On 01/17/2017 01:49 AM, Pavel Hrdina wrote:

On Mon, Jan 16, 2017 at 11:06:17AM -0700, Jim Fehlig wrote:

While local builds succeed fine, a build worker building in a
chroot environment is encountering the following error with
libvirt 3.0.0 release candidates

[  162s] shunloadtest.o: In function `main':
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:110: 
undefined reference to `dlopen'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:114: 
undefined reference to `dlsym'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:133: 
undefined reference to `dlclose'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:111: 
undefined reference to `dlerror'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:115: 
undefined reference to `dlerror'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:116: 
undefined reference to `dlclose'

Fix by appending LDADDS to shunloadtest_LDADD.

Signed-off-by: Jim Fehlig 
---
 tests/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index c7d4748..112396f 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1348,7 +1348,7 @@ libshunload_la_LDFLAGS = $(MOCKLIBS_LDFLAGS)

 shunloadtest_SOURCES = \
shunloadtest.c
-shunloadtest_LDADD = $(LIB_PTHREAD)
+shunloadtest_LDADD = $(LIB_PTHREAD) $(LDADDS)


I don't thing that this is a correct fix.  Some of the libs from LDADDS may
include the dlopen libs but you cannot count on that.  It should be enough to
add $(DLOPEN_LIBS).


Nod, thanks. V2 on the way...

Regards,
Jim

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

[libvirt] [PATCH V2] tests: fix compilation of shunloadtest

[Jim Fehlig]

While local builds succeed fine, a build worker building in a
chroot environment is encountering the following error with
libvirt 3.0.0 release candidates

[  162s] shunloadtest.o: In function `main':
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:110: 
undefined reference to `dlopen'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:114: 
undefined reference to `dlsym'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:133: 
undefined reference to `dlclose'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:111: 
undefined reference to `dlerror'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:115: 
undefined reference to `dlerror'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:116: 
undefined reference to `dlclose'

Fix by appending DLOPEN_LIBS to shunloadtest_LDADD.

Signed-off-by: Jim Fehlig 
---

V2: Use DLOPEN_LIBS instead of LDADDS

 tests/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index c7d4748..bcc2d1e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1348,7 +1348,7 @@ libshunload_la_LDFLAGS = $(MOCKLIBS_LDFLAGS)
 
 shunloadtest_SOURCES = \
shunloadtest.c
-shunloadtest_LDADD = $(LIB_PTHREAD)
+shunloadtest_LDADD = $(LIB_PTHREAD) $(DLOPEN_LIBS)
 shunloadtest_DEPENDENCIES = libshunload.la
 
 sysinfotest_SOURCES = \
-- 
2.9.2

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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Viktor Mihajlovski]

On 17.01.2017 14:21, Michal Privoznik wrote:
> On 01/17/2017 02:13 PM, Marc Hartmayer wrote:
>> Update:
>> It's a SELinux labeling problem and seems to be introduced by the
>> QEMU namespace patches.
>>
> 
> I wouldn't guess from the error message that qemu is getting EPERM.
> 
> Anyway, the SELinux issue is fixed in -rc2:
> 
> commit 93a062c3b293685024d60e841a37e93e303f4943
> Author: Michal Privoznik 
> AuthorDate: Fri Jan 13 10:03:23 2017 +0100
> Commit: Michal Privoznik 
> CommitDate: Fri Jan 13 14:45:52 2017 +0100
> 
> qemu: Copy SELinux labels for namespace too
> 
> When creating new /dev/* for qemu, we do chown() and copy ACLs to
> create the exact copy from the original /dev. I though that
> copying SELinux labels is not necessary as SELinux will chose the
> sane defaults. Surprisingly, it does not leaving namespace with
> the following labels:
> 
> crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 random
> crw---. root root system_u:object_r:tmpfs_t:s0 rtc0
> drwxrwxrwt. root root system_u:object_r:tmpfs_t:s0 shm
> crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 urandom
> 
> As a result, domain is unable to start:
> 
> error: internal error: process exited while connecting to monitor:
> Error in GnuTLS initialization: Failed to acquire random data.
> qemu-kvm: cannot initialize crypto: Unable to initialize GNUTLS
> library: Failed to acquire random data.
> 
> The solution is to copy the SELinux labels as well.
> 
> Reported-by: Andrea Bolognani 
> Signed-off-by: Michal Privoznik 
> 
> 
>> On Tue, Jan 17, 2017 at 11:18 AM +0100, Marc Hartmayer 
>>  wrote:
>>> Hey,
>>>
>>> I have tried to live hot plug a disk backed on a qcow2 disk (see XML
>>> snippet below) on a s390 system and I've got the following error
>>> message:
>>>
>>> 
>>> internal error: unable to execute QEMU command 'device_add': Property
>>> 'scsi-hd.drive' can't find value 'drive-scsi0-0-0-0'
>>> 
>>>
>>> 
>>> 
>>>   
>>>   
> 
> My namespace patches should not clash with this as this isn't a device
> from /dev/*. In the namespace, it's just /dev that is different to the
> parent namespace. So anything else (e.g. under /tmp) is "shared" with
> the parent namespace (it is the same mount in fact).
> 
>>>   
>>> 
>>> 
>>>
>>> With v2.5.0 everything has worked. I'll take a closer look to it today.
> 
> You can try and see if this is a namespace caused issue. Just disable
> the namespaces and retry. If it succeeds with namespaces disabled, the
> bug indeed is in my namespaces patches.
> 
> btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf
> 
> Michal
Somewhat related: I built 3.0.0-rc2 on an x86 Ubuntu box and could not
get it to run in conjunction with apparmor.
By this I mean I could not start a simple KVM guest.
I could get past the audit failures by adding an unconditional mount
permission in /etc/apparmor.d/usr.sbin.libvirtd but ended up with a
generic failure message doing a virsh start.
Disabling namespaces helps (obviously). It would be nice if someone
apparmor-savvy could have a look. Thanks!
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 


-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Daniel P. Berrange]

On Tue, Jan 17, 2017 at 04:41:57PM +0100, Michal Privoznik wrote:
> On 01/17/2017 04:28 PM, Marc Hartmayer wrote:
> > On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik 
> >  wrote:
> >> [Dropping libvirt-announce]
> >>
> >> On 01/17/2017 02:51 PM, Boris Fiuczynski wrote:
> >>> On 01/17/2017 02:21 PM, Michal Privoznik wrote:
> >>   
> >> 
> >> 
> >>
> >> With v2.5.0 everything has worked. I'll take a closer look to it today.
>  You can try and see if this is a namespace caused issue. Just disable
>  the namespaces and retry. If it succeeds with namespaces disabled, the
>  bug indeed is in my namespaces patches.
> 
>  btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf
> 
>  Michal
> >>>
> >>> With disabled namespaces the problem does NOT occur.
> >>>
> >>>
> >>
> >> Okay, can you share the debug logs then please? Both daemon and domain 
> >> logs.
> >>
> >> Michal
> > 
> > Yes - I'll send you also the important part of audit.log (with SELINUX
> > permissive).
> > 
> > Evaluation with some combinations (0 = no, 1 = yes):
> > 
> > | namespace enabled | SELinux enabled | works |
> > |---|-|---|
> > | 0 |   0 | 1 |
> > | 0 |   1 | 1 |
> > | 1 |   0 | 1 |
> > | 1 |   1 | 0 |
> 
> Yeah, I've just managed to reproduce this issue in my environment. And
> something interesting is happening here:
> 
> # grep avc /var/log/audit/audit.log
> type=AVC msg=audit(1484667144.960:323): avc:  denied  { open } for
> pid=32367 comm="qemu-kvm" path="/tmp/disk1.qcow2" dev="vda2"
> ino=17080167 scontext=system_u:system_r:svirt_tcg_t:s0:c551,c756
> tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
> 
> 
> (I've simplified the disk path in my testing compared to your XML).
> 
> Although, if I disable namespaces I'm still unable to attach the disk. I
> mean the SELinux is still denying the operation.

The problem is the qemuSecuritySetDiskLabel() method. It skips labelling
the disk if namespace are enabled, with the claim that the namespace
code already labelled stuff. This is not true though, the namespace code
only labelled block devices, not file backed devices.

I'm not seeing an immediately easy fix for this since we can't tell the
security driver to only label file backed devices.

I think we need to take the security manager code out of the
qemuDomainAttachDeviceMknodHelper method, and the change the
qemuSecuritySetDiskLabel() method to run inside the namespace.

I'm thinking we've hit the limit of what we should try to force into the
3.0.0 release.

My vote at this poiint is to change the code so that namespaces are
disabled out of the box, and do a 3.0.0 release. Look at fixing the
bugs to turn it back on by default in 3.1.0

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

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

Re: [libvirt] [PATCH] qemu: catch failure of drive_add

[Marc Hartmayer]

On Tue, Jan 17, 2017 at 05:15 PM +0100, "Daniel P. Berrange" 
 wrote:
> Previously when QEMU failed "drive_add" due to an error opening
> a file it would report
>
>   "could not open disk image"
>
> These days though, QEMU reports
>
>   "Could not open '/tmp/virtd-test_e3hnhh5/disk1.qcow2': Permission denied"
>
> which we were not detecting as an error condition.
>
> Signed-off-by: Daniel P. Berrange 
> ---
>  src/qemu/qemu_monitor_text.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c
> index bc83218..76d7497 100644
> --- a/src/qemu/qemu_monitor_text.c
> +++ b/src/qemu/qemu_monitor_text.c
> @@ -1959,6 +1959,16 @@ int qemuMonitorTextAddDrive(qemuMonitorPtr mon,
>  goto cleanup;
>  }
>
> +if (strstr(reply, "Could not open")) {
> +size_t len = strlen(reply);
> +if (reply[len - 1] == '\n') {
> +reply[len - 1] = '\0';
> +}
> +virReportError(VIR_ERR_OPERATION_FAILED, "%s",
> +   reply);
> +goto cleanup;
> +}
> +
>  ret = 0;
>
>   cleanup:
> --
> 2.9.3
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>

Tested-by: Marc Hartmayer 

--
Beste Grüße / Kind regards
   Marc Hartmayer

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


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

[libvirt] [PATCH] qemu: catch failure of drive_add

[Daniel P. Berrange]

Previously when QEMU failed "drive_add" due to an error opening
a file it would report

  "could not open disk image"

These days though, QEMU reports

  "Could not open '/tmp/virtd-test_e3hnhh5/disk1.qcow2': Permission denied"

which we were not detecting as an error condition.

Signed-off-by: Daniel P. Berrange 
---
 src/qemu/qemu_monitor_text.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c
index bc83218..76d7497 100644
--- a/src/qemu/qemu_monitor_text.c
+++ b/src/qemu/qemu_monitor_text.c
@@ -1959,6 +1959,16 @@ int qemuMonitorTextAddDrive(qemuMonitorPtr mon,
 goto cleanup;
 }
 
+if (strstr(reply, "Could not open")) {
+size_t len = strlen(reply);
+if (reply[len - 1] == '\n') {
+reply[len - 1] = '\0';
+}
+virReportError(VIR_ERR_OPERATION_FAILED, "%s",
+   reply);
+goto cleanup;
+}
+
 ret = 0;
 
  cleanup:
-- 
2.9.3

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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Daniel P. Berrange]

On Tue, Jan 17, 2017 at 04:41:57PM +0100, Michal Privoznik wrote:
> On 01/17/2017 04:28 PM, Marc Hartmayer wrote:
> > On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik 
> >  wrote:
> >> [Dropping libvirt-announce]
> >>
> >> On 01/17/2017 02:51 PM, Boris Fiuczynski wrote:
> >>> On 01/17/2017 02:21 PM, Michal Privoznik wrote:
> >>   
> >> 
> >> 
> >>
> >> With v2.5.0 everything has worked. I'll take a closer look to it today.
>  You can try and see if this is a namespace caused issue. Just disable
>  the namespaces and retry. If it succeeds with namespaces disabled, the
>  bug indeed is in my namespaces patches.
> 
>  btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf
> 
>  Michal
> >>>
> >>> With disabled namespaces the problem does NOT occur.
> >>>
> >>>
> >>
> >> Okay, can you share the debug logs then please? Both daemon and domain 
> >> logs.
> >>
> >> Michal
> > 
> > Yes - I'll send you also the important part of audit.log (with SELINUX
> > permissive).
> > 
> > Evaluation with some combinations (0 = no, 1 = yes):
> > 
> > | namespace enabled | SELinux enabled | works |
> > |---|-|---|
> > | 0 |   0 | 1 |
> > | 0 |   1 | 1 |
> > | 1 |   0 | 1 |
> > | 1 |   1 | 0 |
> 
> Yeah, I've just managed to reproduce this issue in my environment. And
> something interesting is happening here:
> 
> # grep avc /var/log/audit/audit.log
> type=AVC msg=audit(1484667144.960:323): avc:  denied  { open } for
> pid=32367 comm="qemu-kvm" path="/tmp/disk1.qcow2" dev="vda2"
> ino=17080167 scontext=system_u:system_r:svirt_tcg_t:s0:c551,c756
> tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
> 
> 
> (I've simplified the disk path in my testing compared to your XML).
> 
> Although, if I disable namespaces I'm still unable to attach the disk. I
> mean the SELinux is still denying the operation.

I see the same behaviour Marc is reporting. If namespaces are enabled,
hotplug fails, if disabled, it works.

When namespace are disabled I see 2 lines from the sec driver in the logs:

2017-01-17 16:05:50.539+: 21387: info : 
virSecuritySELinuxSetFileconHelper:1155 : Setting SELinux context on 
'/tmp/virtd-test_e3hnhh5/disk1.qcow2' to 
'system_u:object_r:svirt_image_t:s0:c203,c529'
2017-01-17 16:05:50.540+: 21387: info : 
virSecurityDACSetOwnershipInternal:555 : Setting DAC user and group on 
'/tmp/virtd-test_e3hnhh5/disk1.qcow2' to '107:107'


with namespaces enabled, those lines never appear and we get the permission
problem.

BTW, your test put the file directlry in /tmp - I'd suggest using a subdir
like Marc has, since /tmp has some "special" behaviour with SELinux.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Marc Hartmayer]

On Tue, Jan 17, 2017 at 04:41 PM +0100, Michal Privoznik  
wrote:
> On 01/17/2017 04:28 PM, Marc Hartmayer wrote:
>> On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik 
>>  wrote:
>>> [Dropping libvirt-announce]
>>>
>>> On 01/17/2017 02:51 PM, Boris Fiuczynski wrote:
 On 01/17/2017 02:21 PM, Michal Privoznik wrote:
>>>   
>>> 
>>> 
>>>
>>> With v2.5.0 everything has worked. I'll take a closer look to it today.
> You can try and see if this is a namespace caused issue. Just disable
> the namespaces and retry. If it succeeds with namespaces disabled, the
> bug indeed is in my namespaces patches.
>
> btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf
>
> Michal

 With disabled namespaces the problem does NOT occur.


>>>
>>> Okay, can you share the debug logs then please? Both daemon and domain logs.
>>>
>>> Michal
>>
>> Yes - I'll send you also the important part of audit.log (with SELINUX
>> permissive).
>>
>> Evaluation with some combinations (0 = no, 1 = yes):
>>
>> | namespace enabled | SELinux enabled | works |
>> |---|-|---|
>> | 0 |   0 | 1 |
>> | 0 |   1 | 1 |
>> | 1 |   0 | 1 |
>> | 1 |   1 | 0 |
>
> Yeah, I've just managed to reproduce this issue in my environment. And
> something interesting is happening here:
>
> # grep avc /var/log/audit/audit.log
> type=AVC msg=audit(1484667144.960:323): avc:  denied  { open } for
> pid=32367 comm="qemu-kvm" path="/tmp/disk1.qcow2" dev="vda2"
> ino=17080167 scontext=system_u:system_r:svirt_tcg_t:s0:c551,c756
> tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
>
>
> (I've simplified the disk path in my testing compared to your XML).
>
> Although, if I disable namespaces I'm still unable to attach the disk. I
> mean the SELinux is still denying the operation.
>
> Michal

Hmm, I've just double checked it... and it works if I'm disabling only
namespaces in qemu.conf (and restart libvirtd).


--
Beste Grüße / Kind regards
   Marc Hartmayer

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


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

Re: [libvirt] [PATCH] tests: fix QED disk test in xlconfigtest

[Jim Fehlig]

On 01/17/2017 04:39 AM, Joao Martins wrote:



On 01/16/2017 06:45 PM, Jim Fehlig wrote:

When LIBXL_HAVE_QED is defined, xlconfigtest fails

 9) Xen XL-2-XML Format disk-qed  ... command line: config parsing error
 in disk specification: no vdev specified in
 
`target=/var/lib/libvirt/images/XenGuest2,format=qed,backendtype=qdisk,vdev=hda,access=rw'
FAILED

As per the xl-disk-configuration(5) man page, target= must come
last in the disk specification when specified by name:

When this parameter is specified by name, ie with the target=
syntax in the configuration file, it consumes the whole rest of the
DISKSPEC including trailing whitespaces.  Therefore in that case
it must come last.

Change tests/xlconfigdata/test-disk-qed.cfg to adhere to this
restriction.

Signed-off-by: Jim Fehlig 

Looks like Xen's osstest job doesn't run "make check" on the libvirt test case.


Right, otherwise we would have seen this earlier.


FWIW:

Acked-by: Joao Martins 


Thanks. I've pushed this now since it is a build-breaker with xen-unstable.

Regards,
Jim




---
 tests/xlconfigdata/test-disk-qed.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/xlconfigdata/test-disk-qed.cfg 
b/tests/xlconfigdata/test-disk-qed.cfg
index ee904e0..7842176 100644
--- a/tests/xlconfigdata/test-disk-qed.cfg
+++ b/tests/xlconfigdata/test-disk-qed.cfg
@@ -22,4 +22,4 @@ parallel = "none"
 serial = "none"
 builder = "hvm"
 boot = "d"
-disk = [ 
"target=/var/lib/libvirt/images/XenGuest2,format=qed,backendtype=qdisk,vdev=hda,access=rw"
 ]
+disk = [ 
"format=qed,backendtype=qdisk,vdev=hda,access=rw,target=/var/lib/libvirt/images/XenGuest2"
 ]





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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Michal Privoznik]

On 01/17/2017 04:28 PM, Marc Hartmayer wrote:
> On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik 
>  wrote:
>> [Dropping libvirt-announce]
>>
>> On 01/17/2017 02:51 PM, Boris Fiuczynski wrote:
>>> On 01/17/2017 02:21 PM, Michal Privoznik wrote:
>>   
>> 
>> 
>>
>> With v2.5.0 everything has worked. I'll take a closer look to it today.
 You can try and see if this is a namespace caused issue. Just disable
 the namespaces and retry. If it succeeds with namespaces disabled, the
 bug indeed is in my namespaces patches.

 btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf

 Michal
>>>
>>> With disabled namespaces the problem does NOT occur.
>>>
>>>
>>
>> Okay, can you share the debug logs then please? Both daemon and domain logs.
>>
>> Michal
> 
> Yes - I'll send you also the important part of audit.log (with SELINUX
> permissive).
> 
> Evaluation with some combinations (0 = no, 1 = yes):
> 
> | namespace enabled | SELinux enabled | works |
> |---|-|---|
> | 0 |   0 | 1 |
> | 0 |   1 | 1 |
> | 1 |   0 | 1 |
> | 1 |   1 | 0 |

Yeah, I've just managed to reproduce this issue in my environment. And
something interesting is happening here:

# grep avc /var/log/audit/audit.log
type=AVC msg=audit(1484667144.960:323): avc:  denied  { open } for
pid=32367 comm="qemu-kvm" path="/tmp/disk1.qcow2" dev="vda2"
ino=17080167 scontext=system_u:system_r:svirt_tcg_t:s0:c551,c756
tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file


(I've simplified the disk path in my testing compared to your XML).

Although, if I disable namespaces I'm still unable to attach the disk. I
mean the SELinux is still denying the operation.

Michal

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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Marc Hartmayer]

On Tue, Jan 17, 2017 at 03:28 PM +0100, Michal Privoznik  
wrote:
> [Dropping libvirt-announce]
>
> On 01/17/2017 02:51 PM, Boris Fiuczynski wrote:
>> On 01/17/2017 02:21 PM, Michal Privoznik wrote:
>   
> 
> 
>
> With v2.5.0 everything has worked. I'll take a closer look to it today.
>>> You can try and see if this is a namespace caused issue. Just disable
>>> the namespaces and retry. If it succeeds with namespaces disabled, the
>>> bug indeed is in my namespaces patches.
>>>
>>> btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf
>>>
>>> Michal
>>
>> With disabled namespaces the problem does NOT occur.
>>
>>
>
> Okay, can you share the debug logs then please? Both daemon and domain logs.
>
> Michal

Yes - I'll send you also the important part of audit.log (with SELINUX
permissive).

Evaluation with some combinations (0 = no, 1 = yes):

| namespace enabled | SELinux enabled | works |
|---|-|---|
| 0 |   0 | 1 |
| 0 |   1 | 1 |
| 1 |   0 | 1 |
| 1 |   1 | 0 |

--
Beste Grüße / Kind regards
   Marc Hartmayer

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


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

Re: [libvirt] [PATCH v3 0/2] Fabric name must not be required for fc_host capability

[Boris Fiuczynski]

On 01/17/2017 04:22 PM, John Ferlan wrote:



On 01/16/2017 08:27 AM, Boris Fiuczynski wrote:

fabric_name is one of many fc_host attributes in Linux that is optional
and left to the low-level driver to decide if it is implemented.

---
Changes sinve v2:
 - removed virReadFCHostOption method
 - changed additional file check to be used permanently

Changes since v1:
 - split of minor correction in documenting comment
 - added news entry...
 - added new virReadFCHostOption method
 - added check for file existence when optional is set
 - rearranged fchost tests to fit the numbering

---
Boris Fiuczynski (2):
  util: add file exists check in virReadFCHost
  nodedev: Fabric name must not be required for fc_host capability

 docs/formatnode.html.in   |  2 +-
 docs/news.xml | 12 ++
 docs/schemas/nodedev.rng  |  8 ---
 src/node_device/node_device_linux_sysfs.c |  9 +++
 src/util/virutil.c|  5 +++-
 tests/fchostdata/fc_host/host6/node_name  |  1 +
 tests/fchostdata/fc_host/host6/port_name  |  1 +
 tests/fchostdata/fc_host/host6/port_state |  1 +
 tests/fchosttest.c| 40 ++-
 9 files changed, 67 insertions(+), 12 deletions(-)
 create mode 100644 tests/fchostdata/fc_host/host6/node_name
 create mode 100644 tests/fchostdata/fc_host/host6/port_name
 create mode 100644 tests/fchostdata/fc_host/host6/port_state



ACK series, but I'll only push after 3.0.0 is out (and move the release
note).

John


Thanks, John!

--
Mit freundlichen Grüßen/Kind regards
   Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

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

Re: [libvirt] [Qemu-devel] [PATCH 0/9] i386: query-cpu-model-expansion test script

[Jason J. Herne]

On 01/16/2017 08:01 PM, Eduardo Habkost wrote:

This is a follow-up to the series that implements
query-cpu-model-expansion. Before including the test script, the
series has some fixes to allow the results of
query-cpu-model-expansion to be used in the QEMU command-line.

The script probably will work on s390x too, but I couldn't test
it yet.



Eduardo,

This test seems to mostly work on s390. The only issue I ran into is 
querying host model using tcg only. s390 requires kvm to query the host 
model. Perhaps we could just skip the tcg host test case on s390?



hernejj: ['/usr/local/bin/qemu-system-s390x', '-chardev', 
'socket,id=mon,path=/var/tmp/qom-fetch-monitor.sock', '-mon', 
'chardev=mon,mode=control', '-display', 'none', '-vga', 'none', 
'-qtest', 'unix:path=/var/tmp/qom-fetch-qtest.sock', '-qtest-log', 
'/dev/null', '-machine', 'accel=qtest', '-machine', 'accel=tcg', '-S', 
'-cpu', 'host']

qemu-system-s390x: CPU definition requires KVM
E
==
ERROR: testTCGModels (__main__.CPUModelTest)
--
Traceback (most recent call last):
  File "./query-cpu-model-test.py", line 380, in testTCGModels
self.checkAllCPUModels()
  File "./query-cpu-model-test.py", line 375, in checkAllCPUModels
self.checkOneCPUModel(m)
  File "./query-cpu-model-test.py", line 304, in checkOneCPUModel
self.checkExpansions(model, msg)
  File "./query-cpu-model-test.py", line 221, in checkExpansions
'%s.static' % (msg))
  File "./query-cpu-model-test.py", line 177, in checkOneExpansion
type=type, model=model['model'])
  File "./../scripts/qemu.py", line 185, in command
raise Exception(reply["error"]["desc"])
Exception: The CPU definition 'host' requires KVM

--
Ran 2 tests in 74.622s


--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

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

Re: [libvirt] [PATCH v3 0/2] Fabric name must not be required for fc_host capability

[John Ferlan]

On 01/16/2017 08:27 AM, Boris Fiuczynski wrote:
> fabric_name is one of many fc_host attributes in Linux that is optional
> and left to the low-level driver to decide if it is implemented.
> 
> ---
> Changes sinve v2:
>  - removed virReadFCHostOption method
>  - changed additional file check to be used permanently
> 
> Changes since v1:
>  - split of minor correction in documenting comment
>  - added news entry...
>  - added new virReadFCHostOption method
>  - added check for file existence when optional is set
>  - rearranged fchost tests to fit the numbering
> 
> ---
> Boris Fiuczynski (2):
>   util: add file exists check in virReadFCHost
>   nodedev: Fabric name must not be required for fc_host capability
> 
>  docs/formatnode.html.in   |  2 +-
>  docs/news.xml | 12 ++
>  docs/schemas/nodedev.rng  |  8 ---
>  src/node_device/node_device_linux_sysfs.c |  9 +++
>  src/util/virutil.c|  5 +++-
>  tests/fchostdata/fc_host/host6/node_name  |  1 +
>  tests/fchostdata/fc_host/host6/port_name  |  1 +
>  tests/fchostdata/fc_host/host6/port_state |  1 +
>  tests/fchosttest.c| 40 
> ++-
>  9 files changed, 67 insertions(+), 12 deletions(-)
>  create mode 100644 tests/fchostdata/fc_host/host6/node_name
>  create mode 100644 tests/fchostdata/fc_host/host6/port_name
>  create mode 100644 tests/fchostdata/fc_host/host6/port_state
> 

ACK series, but I'll only push after 3.0.0 is out (and move the release
note).

John

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

Re: [libvirt] vms hung

[Michal Privoznik]

On 01/16/2017 04:13 PM, Umar Draz wrote:
> Hello,
> 
> I am running libvirt-2.0.0-10.el7_3.2.x86_64 on CentOS 7.3, I have few vms
> of CentOS and Windows 2012 servers.
> 
> Randomly they are hung, but the status of virtual machine keep running, vnc
> and network not responding.
> 
> I have checked all /var/log/messages and /var/log/libvirt/qemu/vm.log but
> nothing found anything wrong.
> 
> Would you please help what should I do more so I can find the issue.
> 
> -- Umar
> 

What state is qemu process in? You may try to "ping" qemu on the monitor:

virsh qemu-monitor-command $dom '{"execute":"query-status"}'

But this sounds like a qemu bug to me.

Michal

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

Re: [libvirt] [PATCH 1/2] security: DAC: fix the transaction model's list append

[Erik Skultety]

> > -if (VIR_APPEND_ELEMENT(list->items, list->nItems, item) < 0) {
> > -VIR_FREE(item);
> > -return -1;
> > -}
> > +if (VIR_APPEND_ELEMENT(list->items, list->nItems, item) < 0)
> > +goto cleanup;
> >  
> > -return 0;
> > +tmp = NULL;
> > +item = NULL;
> 
> This 'item = NULL' is not needed. VIR_APPEND_ELEMENT sets @item to NULL
> upon successful return. But I agree that it is hard to spot.

Oh, missed that one, thanks for the suggestion.

Erik

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

Re: [libvirt] [PATCH 2/2] security: SELinux: fix the transaction model's list append

[Erik Skultety]

> > @@ -111,21 +111,31 @@ 
> > virSecuritySELinuxContextListAppend(virSecuritySELinuxContextListPtr list,
> >  const char *tcon,
> >  bool optional)
> >  {
> > -virSecuritySELinuxContextItemPtr item;
> > +int ret = -1;
> > +char *tmp = NULL;
> > +virSecuritySELinuxContextItemPtr item = NULL;
> >  
> >  if (VIR_ALLOC(item) < 0)
> >  return -1;
> >  
> > -item->path = path;
> > +if (VIR_STRDUP(tmp, path) < 0)
> > +goto cleanup;
> > +
> > +item->path = tmp;
> >  item->tcon = tcon;
> 
> Unfortunately, while this was enough in the DAC driver, it is not enough
> here. @tcon may be dynamically allocated just for this call:
> 
> virSecuritySELinuxRestoreFileLabel ->
> virSecuritySELinuxSetFilecon ->
> virSecuritySELinuxSetFileconHelper ->
> virSecuritySELinuxTransactionAppend ->
> virSecuritySELinuxContextListAppend
> 
> However, I guess fixing that is trivial. ACK if you do so and safe for
> the freeze.

Adjusted both patches according to your suggestions and pushed, thanks.

Erik

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

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

[libvirt] [PATCH v2 4/5] storage: added vstorage pool backend volume functions

[Olga Krishtal]

Vstorage operates with volumes the same way as
directory pool and netfs pool. We use the same functions.

Signed-off-by: Olga Krishtal 
---
 src/storage/storage_backend_vstorage.c | 342 +
 1 file changed, 342 insertions(+)

diff --git a/src/storage/storage_backend_vstorage.c 
b/src/storage/storage_backend_vstorage.c
index 8332f4d..65b5ae0 100644
--- a/src/storage/storage_backend_vstorage.c
+++ b/src/storage/storage_backend_vstorage.c
@@ -534,6 +534,339 @@ virStorageBackendVzRefresh(virConnectPtr conn 
ATTRIBUTE_UNUSED,
 return ret;
 }
 
+static int createFileDir(virConnectPtr conn ATTRIBUTE_UNUSED,
+ virStoragePoolObjPtr pool,
+ virStorageVolDefPtr vol,
+ virStorageVolDefPtr inputvol,
+ unsigned int flags)
+{
+int err;
+
+virCheckFlags(0, -1);
+
+if (inputvol) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+   "%s",
+   _("cannot copy from volume to a directory volume"));
+return -1;
+}
+
+if (vol->target.backingStore) {
+virReportError(VIR_ERR_NO_SUPPORT, "%s",
+   _("backing storage not supported for directories 
volumes"));
+return -1;
+}
+
+
+if ((err = virDirCreate(vol->target.path,
+(vol->target.perms->mode == (mode_t) -1 ?
+ VIR_STORAGE_DEFAULT_VOL_PERM_MODE :
+ vol->target.perms->mode),
+vol->target.perms->uid,
+vol->target.perms->gid,
+(pool->def->type == VIR_STORAGE_POOL_NETFS
+ ? VIR_DIR_CREATE_AS_UID : 0))) < 0) {
+return -1;
+}
+
+return 0;
+}
+
+static int
+_virStorageBackendVzVolBuild(virConnectPtr conn,
+ virStoragePoolObjPtr pool,
+ virStorageVolDefPtr vol,
+ virStorageVolDefPtr inputvol,
+ unsigned int flags)
+{
+virStorageBackendBuildVolFrom create_func;
+
+if (inputvol) {
+if (vol->target.encryption != NULL) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+   "%s", _("storage pool does not support "
+   "building encrypted volumes from "
+   "other volumes"));
+return -1;
+}
+create_func = virStorageBackendGetBuildVolFromFunction(vol,
+   inputvol);
+if (!create_func)
+return -1;
+} else if (vol->target.format == VIR_STORAGE_FILE_RAW &&
+   vol->target.encryption == NULL) {
+create_func = virStorageBackendCreateRaw;
+} else if (vol->target.format == VIR_STORAGE_FILE_DIR) {
+create_func = createFileDir;
+} else if (vol->target.format == VIR_STORAGE_FILE_PLOOP) {
+create_func = virStorageBackendCreatePloop;
+} else {
+create_func = virStorageBackendCreateQemuImg;
+}
+
+if (create_func(conn, pool, vol, inputvol, flags) < 0)
+return -1;
+return 0;
+}
+
+/**
+ * Allocate a new file as a volume. This is either done directly
+ * for raw/sparse files, or by calling qemu-img for
+ * special kinds of files
+ */
+static int
+virStorageBackendVzVolBuild(virConnectPtr conn,
+virStoragePoolObjPtr pool,
+virStorageVolDefPtr vol,
+unsigned int flags)
+{
+virCheckFlags(VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA |
+  VIR_STORAGE_VOL_CREATE_REFLINK,
+  -1);
+
+return _virStorageBackendVzVolBuild(conn, pool, vol, NULL, flags);
+}
+
+/*
+ * Create a storage vol using 'inputvol' as input
+ */
+static int
+virStorageBackendVzVolBuildFrom(virConnectPtr conn,
+virStoragePoolObjPtr pool,
+virStorageVolDefPtr vol,
+virStorageVolDefPtr inputvol,
+unsigned int flags)
+{
+virCheckFlags(VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA |
+  VIR_STORAGE_VOL_CREATE_REFLINK,
+  -1);
+
+return _virStorageBackendVzVolBuild(conn, pool, vol, inputvol, flags);
+}
+
+/**
+ * Set up a volume definition to be added to a pool's volume list, but
+ * don't do any file creation or allocation. By separating the two processes,
+ * we allow allocation progress reporting (by polling the volume's 'info'
+ * function), and can drop the parent pool lock during the (slow) allocation.
+ */
+static int
+virStorageBackendVzVolCreate(virConnectPtr conn ATTRIBUTE_UNUSED,
+ virStoragePoolObjPtr pool,
+ virStorageVolDefPtr vol)
+{
+
+if (vol->target.format

[libvirt] [PATCH v2 3/5] storage: vstorage pool operations

[Olga Krishtal]

Added create/define/etc pool operations for vstorage backend.

The vstorage storage pool looks like netfs ones. Due to this
some of pool/volume functions were taken with no changes:
refresh pool function.

Signed-off-by: Olga Krishtal 
---
 src/storage/storage_backend_vstorage.c | 530 +
 1 file changed, 530 insertions(+)

diff --git a/src/storage/storage_backend_vstorage.c 
b/src/storage/storage_backend_vstorage.c
index 3a57385..8332f4d 100644
--- a/src/storage/storage_backend_vstorage.c
+++ b/src/storage/storage_backend_vstorage.c
@@ -6,11 +6,541 @@
 #include "storage_backend_vstorage.h"
 #include "virlog.h"
 #include "virstring.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #define VIR_FROM_THIS VIR_FROM_STORAGE
 
+#define VIR_STORAGE_VOL_FS_OPEN_FLAGS(VIR_STORAGE_VOL_OPEN_DEFAULT | \
+  VIR_STORAGE_VOL_OPEN_DIR)
+#define VIR_STORAGE_VOL_FS_PROBE_FLAGS   (VIR_STORAGE_VOL_FS_OPEN_FLAGS | \
+  VIR_STORAGE_VOL_OPEN_NOERROR)
+
+
+
 VIR_LOG_INIT("storage.storage_backend_vstorage");
+/**
+ * @conn connection to report errors against
+ * @pool storage pool to build
+ * @flags controls the pool formatting behaviour
+ *
+ *
+ * If no flag is set, it only makes the directory;
+ * If VIR_STORAGE_POOL_BUILD_NO_OVERWRITE set, it determines if
+ * the directory exists and if yes - we use it. Otherwise - the new one
+ * will be created.
+ * If VIR_STORAGE_POOL_BUILD_OVERWRITE is set, the dircetory for pool
+ * will used but the content and permissions will be updated
+ *
+ * Returns 0 on success, -1 on error
+ */
+
+static int
+virStorageBackendVzPoolBuild(virConnectPtr conn ATTRIBUTE_UNUSED,
+ virStoragePoolObjPtr pool,
+ unsigned int flags)
+{
+int ret = -1;
+char *parent = NULL;
+char *p = NULL;
+mode_t mode;
+unsigned int dir_create_flags;
+
+virCheckFlags(VIR_STORAGE_POOL_BUILD_OVERWRITE |
+  VIR_STORAGE_POOL_BUILD_NO_OVERWRITE, ret);
+
+VIR_EXCLUSIVE_FLAGS_GOTO(VIR_STORAGE_POOL_BUILD_OVERWRITE,
+ VIR_STORAGE_POOL_BUILD_NO_OVERWRITE,
+ error);
+
+if (VIR_STRDUP(parent, pool->def->target.path) < 0)
+goto error;
+if (!(p = strrchr(parent, '/'))) {
+virReportError(VIR_ERR_INVALID_ARG,
+   _("path '%s' is not absolute"),
+   pool->def->target.path);
+goto error;
+}
+
+if (p != parent) {
+/* assure all directories in the path prior to the final dir
+ * exist, with default uid/gid/mode. */
+*p = '\0';
+if (virFileMakePath(parent) < 0) {
+virReportSystemError(errno, _("cannot create path '%s'"),
+ parent);
+goto error;
+}
+}
+
+dir_create_flags = VIR_DIR_CREATE_ALLOW_EXIST;
+mode = pool->def->target.perms.mode;
+
+if (mode == (mode_t) -1 && !virFileExists(pool->def->target.path))
+mode = VIR_STORAGE_DEFAULT_POOL_PERM_MODE;
+
+/* Now create the final dir in the path with the uid/gid/mode
+ * requested in the config. If the dir already exists, just set
+ * the perms. */
+if (virDirCreate(pool->def->target.path,
+ mode,
+ pool->def->target.perms.uid,
+ pool->def->target.perms.gid,
+ dir_create_flags) < 0)
+goto error;
+
+/* Delete directory content if flag is set*/
+if (flags & VIR_STORAGE_POOL_BUILD_OVERWRITE)
+   if (virFileDeleteTree(pool->def->target.path))
+   goto error;
+
+ret = 0;
+
+ error:
+VIR_FREE(parent);
+return ret;
+}
+
+static int
+virStorageBackendVzPoolStart(virConnectPtr conn ATTRIBUTE_UNUSED,
+ virStoragePoolObjPtr pool)
+{
+int ret = -1;
+virCommandPtr cmd = NULL;
+char *grp_name = NULL;
+char *usr_name = NULL;
+char *mode = NULL;
+
+/* Check the permissions */
+if (pool->def->target.perms.mode == (mode_t) - 1)
+pool->def->target.perms.mode = VIR_STORAGE_DEFAULT_POOL_PERM_MODE;
+if (pool->def->target.perms.uid == (uid_t) -1)
+pool->def->target.perms.uid = geteuid();
+if (pool->def->target.perms.gid == (gid_t) -1)
+pool->def->target.perms.gid = getegid();
+
+/* Convert ids to names because vstorage uses names */
+
+grp_name = virGetGroupName(pool->def->target.perms.gid);
+if (!grp_name)
+return -1;
+
+usr_name = virGetUserName(pool->def->target.perms.uid);
+if (!usr_name)
+return -1;
+
+if (virAsprintf(&mode, "%o", pool->def->target.perms.mode) < 0)
+return -1;
+
+cmd = virCommandNewArgList(VSTORAGE_MOUNT,
+   "-c", pool->def->source.name,
+   pool->def->target.path,
+  

[libvirt] [PATCH v2 2/5] storage: vstorage empty backend

[Olga Krishtal]

Added general defenitions for vstorage pool backend

Signed-off-by: Olga Krishtal 
---
 include/libvirt/libvirt-storage.h  |  1 +
 po/POTFILES.in |  1 +
 src/Makefile.am|  9 +
 src/conf/storage_conf.c| 17 -
 src/conf/storage_conf.h|  1 +
 src/storage/storage_backend.c  |  6 ++
 src/storage/storage_backend_vstorage.c | 16 
 src/storage/storage_backend_vstorage.h | 28 
 src/storage/storage_driver.c   |  2 ++
 tools/virsh-pool.c |  3 +++
 tools/virsh.c  |  3 +++
 11 files changed, 86 insertions(+), 1 deletion(-)
 create mode 100644 src/storage/storage_backend_vstorage.c
 create mode 100644 src/storage/storage_backend_vstorage.h

diff --git a/include/libvirt/libvirt-storage.h 
b/include/libvirt/libvirt-storage.h
index 8a861e4..45ec720 100644
--- a/include/libvirt/libvirt-storage.h
+++ b/include/libvirt/libvirt-storage.h
@@ -240,6 +240,7 @@ typedef enum {
 VIR_CONNECT_LIST_STORAGE_POOLS_SHEEPDOG  = 1 << 15,
 VIR_CONNECT_LIST_STORAGE_POOLS_GLUSTER   = 1 << 16,
 VIR_CONNECT_LIST_STORAGE_POOLS_ZFS   = 1 << 17,
+VIR_CONNECT_LIST_STORAGE_POOLS_VSTORAGE  = 1 << 18,
 } virConnectListAllStoragePoolsFlags;
 
 int virConnectListAllStoragePools(virConnectPtr conn,
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 59efd91..b4fac0e 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -175,6 +175,7 @@ src/storage/storage_backend_mpath.c
 src/storage/storage_backend_rbd.c
 src/storage/storage_backend_scsi.c
 src/storage/storage_backend_sheepdog.c
+src/storage/storage_backend_vstorage.c
 src/storage/storage_backend_zfs.c
 src/storage/storage_driver.c
 src/test/test_driver.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 21a78e0..78e64f2 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1005,6 +1005,10 @@ STORAGE_DRIVER_GLUSTER_SOURCES = 
\
 STORAGE_DRIVER_ZFS_SOURCES =   \
 storage/storage_backend_zfs.h storage/storage_backend_zfs.c
 
+STORAGE_DRIVER_VSTORAGE_SOURCES =  \
+storage/storage_backend_vstorage.h \
+storage/storage_backend_vstorage.c
+
 STORAGE_HELPER_DISK_SOURCES =  \
storage/parthelper.c
 
@@ -1712,6 +1716,10 @@ if WITH_STORAGE_ZFS
 libvirt_driver_storage_impl_la_SOURCES += $(STORAGE_DRIVER_ZFS_SOURCES)
 endif WITH_STORAGE_ZFS
 
+if WITH_STORAGE_VSTORAGE
+libvirt_driver_storage_impl_la_SOURCES += $(STORAGE_DRIVER_VSTORAGE_SOURCES)
+endif WITH_STORAGE_VSTORAGE
+
 if WITH_NODE_DEVICES
 # Needed to keep automake quiet about conditionals
 if WITH_DRIVER_MODULES
@@ -1923,6 +1931,7 @@ EXTRA_DIST += 
\
$(STORAGE_DRIVER_SHEEPDOG_SOURCES)  \
$(STORAGE_DRIVER_GLUSTER_SOURCES)   \
$(STORAGE_DRIVER_ZFS_SOURCES)   \
+$(STORAGE_DRIVER_VSTORAGE_SOURCES)  \
$(NODE_DEVICE_DRIVER_SOURCES)   \
$(NODE_DEVICE_DRIVER_HAL_SOURCES)   \
$(NODE_DEVICE_DRIVER_UDEV_SOURCES)  \
diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
index c53f080..c9b93aa 100644
--- a/src/conf/storage_conf.c
+++ b/src/conf/storage_conf.c
@@ -60,7 +60,8 @@ VIR_ENUM_IMPL(virStoragePool,
   "dir", "fs", "netfs",
   "logical", "disk", "iscsi",
   "scsi", "mpath", "rbd",
-  "sheepdog", "gluster", "zfs")
+  "sheepdog", "gluster", "zfs",
+  "vstorage")
 
 VIR_ENUM_IMPL(virStoragePoolFormatFileSystem,
   VIR_STORAGE_POOL_FS_LAST,
@@ -274,6 +275,16 @@ static virStoragePoolTypeInfo poolTypeInfo[] = {
  .defaultFormat = VIR_STORAGE_FILE_RAW,
  },
 },
+{.poolType = VIR_STORAGE_POOL_VSTORAGE,
+ .poolOptions = {
+.flags = VIR_STORAGE_POOL_SOURCE_NAME,
+ },
+ .volOptions = {
+.defaultFormat = VIR_STORAGE_FILE_RAW,
+.formatFromString = virStorageVolumeFormatFromString,
+.formatToString = virStorageFileFormatTypeToString,
+ },
+},
 };
 
 
@@ -2611,6 +2622,10 @@ virStoragePoolSourceFindDuplicate(virConnectPtr conn,
 /* Only one mpath pool is valid per host */
 matchpool = pool;
 break;
+case VIR_STORAGE_POOL_VSTORAGE:
+if (STREQ(pool->def->source.name, def->source.name))
+matchpool = pool;
+break;
 case VIR_STORAGE_POOL_RBD:
 case VIR_STORAGE_POOL_LAST:
 break;
diff --git a/src/conf/storage_conf.h b/src/conf/storage_conf.h
index b35471d..e952f5f 100644
--- a/src/conf/storage_conf.h
+++ b/src/conf/storage_conf.h
@@ -95,6 +95,7 @@ type

[libvirt] [PATCH v2 1/5] storage: adds with_storage_vstorage buils option

[Olga Krishtal]

This patch only adds  --with-storage-vstorage build option.
In order to use vstorage as a backend for storage pool
vstorage tools should be installed.

Signed-off-by: Olga Krishtal 
---
 configure.ac|  4 +++
 m4/virt-storage-vstorage.m4 | 73 +
 2 files changed, 77 insertions(+)
 create mode 100644 m4/virt-storage-vstorage.m4

diff --git a/configure.ac b/configure.ac
index c67ba79..2cc378d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -570,6 +570,7 @@ LIBVIRT_STORAGE_ARG_RBD
 LIBVIRT_STORAGE_ARG_SHEEPDOG
 LIBVIRT_STORAGE_ARG_GLUSTER
 LIBVIRT_STORAGE_ARG_ZFS
+LIBVIRT_STORAGE_ARG_VSTORAGE
 
 if test "$with_libvirtd" = "no"; then
   with_storage_dir=no
@@ -583,6 +584,7 @@ if test "$with_libvirtd" = "no"; then
   with_storage_sheepdog=no
   with_storage_gluster=no
   with_storage_zfs=no
+  with_storage_vstorage=no
 fi
 
 dnl storage-fs does not work on MacOS X
@@ -602,6 +604,7 @@ LIBVIRT_STORAGE_CHECK_RBD
 LIBVIRT_STORAGE_CHECK_SHEEPDOG
 LIBVIRT_STORAGE_CHECK_GLUSTER
 LIBVIRT_STORAGE_CHECK_ZFS
+LIBVIRT_STORAGE_CHECK_VSTORAGE
 
 if test "$with_storage_fs" = "yes" ||
test "$with_storage_gluster" = "yes"; then
@@ -944,6 +947,7 @@ LIBVIRT_STORAGE_RESULT_RBD
 LIBVIRT_STORAGE_RESULT_SHEEPDOG
 LIBVIRT_STORAGE_RESULT_GLUSTER
 LIBVIRT_STORAGE_RESULT_ZFS
+LIBVIRT_STORAGE_RESULT_VSTORAGE
 AC_MSG_NOTICE([])
 AC_MSG_NOTICE([Security Drivers])
 AC_MSG_NOTICE([])
diff --git a/m4/virt-storage-vstorage.m4 b/m4/virt-storage-vstorage.m4
new file mode 100644
index 000..8a926c8
--- /dev/null
+++ b/m4/virt-storage-vstorage.m4
@@ -0,0 +1,73 @@
+dnl The storage vstorage check
+dnl
+dnl Copyright (C) 2016  Parallels IP Holdings GmbH, Inc.
+dnl
+dnl This library is free software; you can redistribute it and/or
+dnl modify it under the terms of the GNU Lesser General Public
+dnl License as published by the Free Software Foundation; either
+dnl version 2.1 of the License, or (at your option) any later version.
+dnl
+dnl This library is distributed in the hope that it will be useful,
+dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+dnl Lesser General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU Lesser General Public
+dnl License along with this library.  If not, see
+dnl .
+dnl
+
+
+AC_DEFUN([LIBVIRT_STORAGE_ARG_VSTORAGE], [
+  LIBVIRT_ARG_WITH_FEATURE([STORAGE_VSTORAGE],
+   [Virtuozzo Storage backend for the storage driver],
+   [check])
+])
+
+AC_DEFUN([LIBVIRT_STORAGE_CHECK_VSTORAGE], [
+  if test "$with_storage_vstorage" = "yes" ||
+ test "$with_storage_vstorage" = "check"; then
+AC_PATH_PROG([VSTORAGE], [vstorage], [], [$LIBVIRT_SBIN_PATH])
+AC_PATH_PROG([VSTORAGE_MOUNT], [vstorage-mount], [], [$LIBVIRT_SBIN_PATH])
+AC_PATH_PROG([UMOUNT], [umount], [], [$LIBVIRT_SBIN_PATH])
+
+if test "$with_storage_vstorage" = "yes"; then
+  if test -z "$VSTORAGE" || test -z "$VSTORAGE_MOUNT"; then
+AC_MSG_ERROR([We need vstorage and vstorage-mount tool for Vstorage 
storage driver]);
+  fi
+  if test -z "$UMOUNT" ; then
+AC_MSG_ERROR([We need umount for Vstorage storage driver]);
+  fi
+else
+  if test -z "$VSTORAGE" ; then
+with_storage_vstorage=no
+  fi
+  if test -z "$VSTORAGE_MOUNT" ; then
+with_storage_vstorage=no
+  fi
+  if test -z "$UMOUNT" ; then
+with_storage_vstorage=no
+  fi
+
+  if test "$with_storage_fs" = "check" ; then
+with_storage_vstorage=yes
+  fi
+fi
+
+if test "$with_storage_vstorage" = "yes" ; then
+  AC_DEFINE_UNQUOTED([WITH_STORAGE_VSTORAGE], 1,
+ [whether Vstorage backend for storage driver is 
enabled])
+  AC_DEFINE_UNQUOTED([VSTORAGE], ["$VSTORAGE"],
+ [Location or name of the vstorage client tool])
+  AC_DEFINE_UNQUOTED([VSTORAGE_MOUNT], ["$VSTORAGE_MOUNT"],
+ [Location or name of the vstorage mount tool])
+  AC_DEFINE_UNQUOTED([UMOUNT], ["$UMOUNT"],
+ [Location or name of the umount programm])
+fi
+  fi
+  AM_CONDITIONAL([WITH_STORAGE_VSTORAGE], [test "$with_storage_vstorage" = 
"yes"])
+])
+
+AC_DEFUN([LIBVIRT_STORAGE_RESULT_VSTORAGE], [
+  LIBVIRT_RESULT([Virtuozzo storage], [$with_storage_vstorage])
+])
-- 
1.8.3.1

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

[libvirt] [PATCH v2 0/5] storage: Virtuozzo storage backend for storage pool

[Olga Krishtal]

This series of patches support pool and volume management within Virtuozzo 
Storage.
Virtuozzo Storage is a highly-available distributed software defined storage
with built-in replication and disaster recovery.
More information about vzstorage can be found here: 
https://openvz.org/Virtuozzo_Storage

>From client's point of view it looks like network attached storage (NFS or 
>GlusterFS).
It supports the same volume formats as directory, nfs. Default format ifor 
volume is raw.
Because of such similarities all a lot of functions from storage backend fs
can be used with no change: all functions that deals with volumes and pool
refresh function.

>From the other hand, Virtuozzo storage demands special packages like 
>vstorage-client
to be installed. So all functions that work with it are in separate file.

v2:
- resplitted patches
- all functions to work with Virtuozzo storage are in separate file
- added possibility to mout cluster for pool for ures/with specific perms.
- added documetation

Olga Krishtal (5):
  storage: adds with_storage_vstorage buils option
  storage: vstorage empty backend
  storage: vstorage pool operations
  storage: added vstorage pool backend volume functions
  storage: vstorage pool documentation and simple test

 configure.ac  |   5 +
 docs/formatstorage.html.in|   7 +-
 docs/schemas/storagepool.rng  |  21 +
 docs/storage.html.in  |  28 +-
 include/libvirt/libvirt-storage.h |   1 +
 m4/virt-storage-vstorage.m4   |  73 +++
 po/POTFILES.in|   1 +
 src/Makefile.am   |   9 +
 src/conf/storage_conf.c   |  17 +-
 src/conf/storage_conf.h   |   1 +
 src/storage/storage_backend.c |   6 +
 src/storage/storage_backend_vstorage.c| 888 ++
 src/storage/storage_backend_vstorage.h|  27 +
 src/storage/storage_driver.c  |   2 +
 tests/storagepoolxml2xmlin/pool-vstorage.xml  |  10 +
 tests/storagepoolxml2xmlout/pool-vstorage.xml |  18 +
 tests/storagepoolxml2xmltest.c|   3 +
 tools/virsh-pool.c|   3 +
 tools/virsh.c |   3 +
 19 files changed, 1118 insertions(+), 5 deletions(-)
 create mode 100644 m4/virt-storage-vstorage.m4
 create mode 100644 src/storage/storage_backend_vstorage.c
 create mode 100644 src/storage/storage_backend_vstorage.h
 create mode 100644 tests/storagepoolxml2xmlin/pool-vstorage.xml
 create mode 100644 tests/storagepoolxml2xmlout/pool-vstorage.xml

-- 
1.8.3.1

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

[libvirt] [PATCH v2 5/5] storage: vstorage pool documentation and simple test

[Olga Krishtal]

Signed-off-by: Olga Krishtal 
---
 docs/formatstorage.html.in|  7 ---
 docs/schemas/storagepool.rng  | 21 
 docs/storage.html.in  | 28 ++-
 tests/storagepoolxml2xmlin/pool-vstorage.xml  | 10 ++
 tests/storagepoolxml2xmlout/pool-vstorage.xml | 18 +
 tests/storagepoolxml2xmltest.c|  3 +++
 6 files changed, 83 insertions(+), 4 deletions(-)
 create mode 100644 tests/storagepoolxml2xmlin/pool-vstorage.xml
 create mode 100644 tests/storagepoolxml2xmlout/pool-vstorage.xml

diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in
index f6887ae..3c39266 100644
--- a/docs/formatstorage.html.in
+++ b/docs/formatstorage.html.in
@@ -24,8 +24,9 @@
   (since 0.9.13), sheepdog
   (since 0.10.0),
   gluster (since
-  1.2.0) or zfs (since
-  1.2.8). This corresponds to the
+  1.2.0),  zfs (since
+  1.2.8) or vstorage (since
+  3.0.0). This corresponds to the
   storage backend drivers listed further along in this document.
 
 General metadata
@@ -124,7 +125,7 @@
   device
   Provides the source for pools backed by physical devices
 (pool types fs, logical, disk,
-iscsi, zfs).
+iscsi, zfs, vstorage).
 May be repeated multiple times depending on backend driver. Contains
 a required attribute path which is either the fully
 qualified path to the block device node or for iscsi
diff --git a/docs/schemas/storagepool.rng b/docs/schemas/storagepool.rng
index 49d212f..c5d13a8 100644
--- a/docs/schemas/storagepool.rng
+++ b/docs/schemas/storagepool.rng
@@ -24,6 +24,7 @@
 
 
 
+
   
 
   
@@ -173,6 +174,18 @@
 
   
 
+  
+
+  vstorage
+
+
+  
+  
+  
+  
+
+  
+
   
 
   
@@ -373,6 +386,14 @@
 
   
 
+  
+
+  
+
+  
+
+  
+
   
 
   
diff --git a/docs/storage.html.in b/docs/storage.html.in
index 2e5b65e..26d21df 100644
--- a/docs/storage.html.in
+++ b/docs/storage.html.in
@@ -120,6 +120,9 @@
   
 ZFS backend
   
+  
+Virtuozzo storage backend
+  
 
 
 Directory pool
@@ -791,6 +794,29 @@
 
   The ZFS volume pool does not use the volume format type element.
 
-
+Vstorage pools
+
+  This provides a pool based on Virtuozzo storage. Virtuozzo Storage is 
highly-avaliable
+  distributed software-defined storage with build-in replication and 
disaster recovery.
+  (More detailed information about storage and its managment can be found 
here:
+  https://openvz.org/Virtuozzo_Storage";>Virtuozzo Storage).
+
+Please refer to the Virtuozzo Storage documentation for details on a 
storage managment
+   and usage.
+Example pool input
+In order to create storage pool with Virtuozzo Storage bakend you have 
to provide
+cluster name and be authorized within this cluster.
+ 
+
+  myvstoragepool
+  
+clustername
+  
+  
+/mnt/clustername
+  
+
+Valid volume format types
+The valid volume types are the same as for the directory pool type.
   
 
diff --git a/tests/storagepoolxml2xmlin/pool-vstorage.xml 
b/tests/storagepoolxml2xmlin/pool-vstorage.xml
new file mode 100644
index 000..31e36a2
--- /dev/null
+++ b/tests/storagepoolxml2xmlin/pool-vstorage.xml
@@ -0,0 +1,10 @@
+
+  vstorage
+  cfd270f9-acc7-4394-8685-4977eb318171
+  
+vzstorage-cluster
+  
+  
+/mnt/vstorage_cluster
+  
+
diff --git a/tests/storagepoolxml2xmlout/pool-vstorage.xml 
b/tests/storagepoolxml2xmlout/pool-vstorage.xml
new file mode 100644
index 000..8b2aecb
--- /dev/null
+++ b/tests/storagepoolxml2xmlout/pool-vstorage.xml
@@ -0,0 +1,18 @@
+
+  vstorage
+  cfd270f9-acc7-4394-8685-4977eb318171
+  0
+  0
+  0
+  
+vstorage-cluster
+  
+  
+/mnt/vstorage-cluster
+
+  0755
+  -1
+  -1
+
+  
+
diff --git a/tests/storagepoolxml2xmltest.c b/tests/storagepoolxml2xmltest.c
index 2e1e811..98a8449 100644
--- a/tests/storagepoolxml2xmltest.c
+++ b/tests/storagepoolxml2xmltest.c
@@ -104,6 +104,9 @@ mymain(void)
 #ifdef WITH_STORAGE_RBD
 DO_TEST("pool-rbd");
 #endif
+#ifdef WITH_STORAGE_VSTORAGE
+DO_TEST("pool-vstorage");
+#endif
 
 return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
 }
-- 
1.8.3.1

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

[libvirt] [PATCH] util: disallow resetting a pci-bridge device

[Shivaprasad G Bhat]

It is distructive to attempt a reset on pci-bridge, the host can crash.
The bridges won't contain any guest data and neither they can be
passed through using vfio/stub. So, no point in allowing a reset for them.

Signed-off-by: Shivaprasad G Bhat 
---
 src/util/virpci.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/util/virpci.c b/src/util/virpci.c
index 0601f49..860f7aa 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -933,6 +933,16 @@ virPCIDeviceReset(virPCIDevicePtr dev,
 char *drvName = NULL;
 int ret = -1;
 int fd = -1;
+int hdrType = -1;
+
+if (virPCIGetHeaderType(dev, &hdrType) < 0)
+return -1;
+
+if (hdrType == VIR_PCI_HEADER_PCI_BRIDGE) {
+virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+   _("Resetting a pci-bridge device is not allowed"));
+return -1;
+}
 
 if (activeDevs && virPCIDeviceListFind(activeDevs, dev)) {
 virReportError(VIR_ERR_INTERNAL_ERROR,

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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Michal Privoznik]

[Dropping libvirt-announce]

On 01/17/2017 02:51 PM, Boris Fiuczynski wrote:
> On 01/17/2017 02:21 PM, Michal Privoznik wrote:
   
 
 

 With v2.5.0 everything has worked. I'll take a closer look to it today.
>> You can try and see if this is a namespace caused issue. Just disable
>> the namespaces and retry. If it succeeds with namespaces disabled, the
>> bug indeed is in my namespaces patches.
>>
>> btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf
>>
>> Michal
> 
> With disabled namespaces the problem does NOT occur.
> 
> 

Okay, can you share the debug logs then please? Both daemon and domain logs.

Michal

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

Re: [libvirt] [PATCH 2/2] security: SELinux: fix the transaction model's list append

[Michal Privoznik]

On 01/17/2017 02:56 PM, Erik Skultety wrote:
> The problem is in the way how the list item is created prior to
> appending it to the transaction list - the @path argument is just a
> shallow copy instead of deep copy of the hostdev device's path.
> Unfortunately, the hostdev devices from which the @path is extracted, in
> order to add them into the transaction list, are only temporary and
> freed before the buildup of the qemu namespace, thus making the @path
> attribute in the transaction list NULL, causing 'permission denied' or
> 'double free' or 'unknown cause' errors.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1413773
> 
> Signed-off-by: Erik Skultety 
> ---
>  src/security/security_selinux.c | 30 +-
>  1 file changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
> index f229b51..c799056 100644
> --- a/src/security/security_selinux.c
> +++ b/src/security/security_selinux.c
> @@ -81,7 +81,7 @@ struct _virSecuritySELinuxCallbackData {
>  typedef struct _virSecuritySELinuxContextItem virSecuritySELinuxContextItem;
>  typedef virSecuritySELinuxContextItem *virSecuritySELinuxContextItemPtr;
>  struct _virSecuritySELinuxContextItem {
> -const char *path;
> +char *path;
>  const char *tcon;
>  bool optional;
>  };
> @@ -111,21 +111,31 @@ 
> virSecuritySELinuxContextListAppend(virSecuritySELinuxContextListPtr list,
>  const char *tcon,
>  bool optional)
>  {
> -virSecuritySELinuxContextItemPtr item;
> +int ret = -1;
> +char *tmp = NULL;
> +virSecuritySELinuxContextItemPtr item = NULL;
>  
>  if (VIR_ALLOC(item) < 0)
>  return -1;
>  
> -item->path = path;
> +if (VIR_STRDUP(tmp, path) < 0)
> +goto cleanup;
> +
> +item->path = tmp;
>  item->tcon = tcon;

Unfortunately, while this was enough in the DAC driver, it is not enough
here. @tcon may be dynamically allocated just for this call:

virSecuritySELinuxRestoreFileLabel ->
virSecuritySELinuxSetFilecon ->
virSecuritySELinuxSetFileconHelper ->
virSecuritySELinuxTransactionAppend ->
virSecuritySELinuxContextListAppend

However, I guess fixing that is trivial. ACK if you do so and safe for
the freeze.

Michal

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

Re: [libvirt] [PATCH 1/2] security: DAC: fix the transaction model's list append

[Michal Privoznik]

On 01/17/2017 02:56 PM, Erik Skultety wrote:
> The problem is in the way how the list item is created prior to
> appending it to the transaction list - the @path attribute is just a
> shallow copy instead of deep copy of the hostdev device's path.
> Unfortunately, the hostdev devices from which the @path is extracted, in
> order to add them into the transaction list, are only temporary and
> freed before the buildup of the qemu namespace, thus making the @path
> attribute in the transaction list NULL, causing 'permission denied' or
> 'double free' or 'unknown cause' errors.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1413773
> 
> Signed-off-by: Erik Skultety 
> ---
>  src/security/security_dac.c | 30 +-
>  1 file changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/src/security/security_dac.c b/src/security/security_dac.c
> index d457e6a..d7a2de4 100644
> --- a/src/security/security_dac.c
> +++ b/src/security/security_dac.c
> @@ -71,7 +71,7 @@ struct _virSecurityDACCallbackData {
>  typedef struct _virSecurityDACChownItem virSecurityDACChownItem;
>  typedef virSecurityDACChownItem *virSecurityDACChownItemPtr;
>  struct _virSecurityDACChownItem {
> -const char *path;
> +char *path;
>  const virStorageSource *src;
>  uid_t uid;
>  gid_t gid;
> @@ -95,22 +95,32 @@ virSecurityDACChownListAppend(virSecurityDACChownListPtr 
> list,
>uid_t uid,
>gid_t gid)
>  {
> -virSecurityDACChownItemPtr item;
> +int ret = -1;
> +char *tmp = NULL;
> +virSecurityDACChownItemPtr item = NULL;
>  
>  if (VIR_ALLOC(item) < 0)
>  return -1;
>  
> -item->path = path;
> +if (VIR_STRDUP(tmp, path) < 0)
> +goto cleanup;
> +
> +item->path = tmp;
>  item->src = src;
>  item->uid = uid;
>  item->gid = gid;
>  
> -if (VIR_APPEND_ELEMENT(list->items, list->nItems, item) < 0) {
> -VIR_FREE(item);
> -return -1;
> -}
> +if (VIR_APPEND_ELEMENT(list->items, list->nItems, item) < 0)
> +goto cleanup;
>  
> -return 0;
> +tmp = NULL;
> +item = NULL;

This 'item = NULL' is not needed. VIR_APPEND_ELEMENT sets @item to NULL
upon successful return. But I agree that it is hard to spot.

> +
> +ret = 0;
> + cleanup:
> +VIR_FREE(tmp);
> +VIR_FREE(item);
> +return ret;
>  }
>  
>  static void
> @@ -122,8 +132,10 @@ virSecurityDACChownListFree(void *opaque)
>  if (!list)
>  return;
>  
> -for (i = 0; i < list->nItems; i++)
> +for (i = 0; i < list->nItems; i++) {
> +VIR_FREE(list->items[i]->path);
>  VIR_FREE(list->items[i]);
> +}
>  VIR_FREE(list);
>  }
>  
> 

ACK and safe for the freeze.

Michal

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

Re: [libvirt] [PATCH] qemu: Don't leak hostCPUModelInfo in virQEMUCaps

[Jiri Denemark]

On Tue, Jan 17, 2017 at 14:57:09 +0100, Peter Krempa wrote:
> On Tue, Jan 17, 2017 at 14:40:21 +0100, Jiri Denemark wrote:
> > Signed-off-by: Jiri Denemark 
> > ---
> >  src/qemu/qemu_capabilities.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> ACK, safe.

Safely pushed. Thanks.

Jirka

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

[libvirt] [PATCH 2/2] security: SELinux: fix the transaction model's list append

[Erik Skultety]

The problem is in the way how the list item is created prior to
appending it to the transaction list - the @path argument is just a
shallow copy instead of deep copy of the hostdev device's path.
Unfortunately, the hostdev devices from which the @path is extracted, in
order to add them into the transaction list, are only temporary and
freed before the buildup of the qemu namespace, thus making the @path
attribute in the transaction list NULL, causing 'permission denied' or
'double free' or 'unknown cause' errors.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1413773

Signed-off-by: Erik Skultety 
---
 src/security/security_selinux.c | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
index f229b51..c799056 100644
--- a/src/security/security_selinux.c
+++ b/src/security/security_selinux.c
@@ -81,7 +81,7 @@ struct _virSecuritySELinuxCallbackData {
 typedef struct _virSecuritySELinuxContextItem virSecuritySELinuxContextItem;
 typedef virSecuritySELinuxContextItem *virSecuritySELinuxContextItemPtr;
 struct _virSecuritySELinuxContextItem {
-const char *path;
+char *path;
 const char *tcon;
 bool optional;
 };
@@ -111,21 +111,31 @@ 
virSecuritySELinuxContextListAppend(virSecuritySELinuxContextListPtr list,
 const char *tcon,
 bool optional)
 {
-virSecuritySELinuxContextItemPtr item;
+int ret = -1;
+char *tmp = NULL;
+virSecuritySELinuxContextItemPtr item = NULL;
 
 if (VIR_ALLOC(item) < 0)
 return -1;
 
-item->path = path;
+if (VIR_STRDUP(tmp, path) < 0)
+goto cleanup;
+
+item->path = tmp;
 item->tcon = tcon;
 item->optional = optional;
 
-if (VIR_APPEND_ELEMENT(list->items, list->nItems, item) < 0) {
-VIR_FREE(item);
-return -1;
-}
+if (VIR_APPEND_ELEMENT(list->items, list->nItems, item) < 0)
+goto cleanup;
 
-return 0;
+tmp = NULL;
+item = NULL;
+
+ret = 0;
+ cleanup:
+VIR_FREE(tmp);
+VIR_FREE(item);
+return ret;
 }
 
 static void
@@ -137,8 +147,10 @@ virSecuritySELinuxContextListFree(void *opaque)
 if (!list)
 return;
 
-for (i = 0; i < list->nItems; i++)
+for (i = 0; i < list->nItems; i++) {
+VIR_FREE(list->items[i]->path);
 VIR_FREE(list->items[i]);
+}
 VIR_FREE(list);
 }
 
-- 
2.10.2

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

Re: [libvirt] [PATCH] qemu: Don't leak hostCPUModelInfo in virQEMUCaps

[Peter Krempa]

On Tue, Jan 17, 2017 at 14:40:21 +0100, Jiri Denemark wrote:
> Signed-off-by: Jiri Denemark 
> ---
>  src/qemu/qemu_capabilities.c | 1 +
>  1 file changed, 1 insertion(+)

ACK, safe.


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

[libvirt] [PATCH 1/2] security: DAC: fix the transaction model's list append

[Erik Skultety]

The problem is in the way how the list item is created prior to
appending it to the transaction list - the @path attribute is just a
shallow copy instead of deep copy of the hostdev device's path.
Unfortunately, the hostdev devices from which the @path is extracted, in
order to add them into the transaction list, are only temporary and
freed before the buildup of the qemu namespace, thus making the @path
attribute in the transaction list NULL, causing 'permission denied' or
'double free' or 'unknown cause' errors.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1413773

Signed-off-by: Erik Skultety 
---
 src/security/security_dac.c | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/src/security/security_dac.c b/src/security/security_dac.c
index d457e6a..d7a2de4 100644
--- a/src/security/security_dac.c
+++ b/src/security/security_dac.c
@@ -71,7 +71,7 @@ struct _virSecurityDACCallbackData {
 typedef struct _virSecurityDACChownItem virSecurityDACChownItem;
 typedef virSecurityDACChownItem *virSecurityDACChownItemPtr;
 struct _virSecurityDACChownItem {
-const char *path;
+char *path;
 const virStorageSource *src;
 uid_t uid;
 gid_t gid;
@@ -95,22 +95,32 @@ virSecurityDACChownListAppend(virSecurityDACChownListPtr 
list,
   uid_t uid,
   gid_t gid)
 {
-virSecurityDACChownItemPtr item;
+int ret = -1;
+char *tmp = NULL;
+virSecurityDACChownItemPtr item = NULL;
 
 if (VIR_ALLOC(item) < 0)
 return -1;
 
-item->path = path;
+if (VIR_STRDUP(tmp, path) < 0)
+goto cleanup;
+
+item->path = tmp;
 item->src = src;
 item->uid = uid;
 item->gid = gid;
 
-if (VIR_APPEND_ELEMENT(list->items, list->nItems, item) < 0) {
-VIR_FREE(item);
-return -1;
-}
+if (VIR_APPEND_ELEMENT(list->items, list->nItems, item) < 0)
+goto cleanup;
 
-return 0;
+tmp = NULL;
+item = NULL;
+
+ret = 0;
+ cleanup:
+VIR_FREE(tmp);
+VIR_FREE(item);
+return ret;
 }
 
 static void
@@ -122,8 +132,10 @@ virSecurityDACChownListFree(void *opaque)
 if (!list)
 return;
 
-for (i = 0; i < list->nItems; i++)
+for (i = 0; i < list->nItems; i++) {
+VIR_FREE(list->items[i]->path);
 VIR_FREE(list->items[i]);
+}
 VIR_FREE(list);
 }
 
-- 
2.10.2

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

[libvirt] [PATCH 0/2] security: Fix the transaction model's list appending

[Erik Skultety]

The problem lies in how elements are appended into the transaction list -
instead of making a deep copy of a string we were doing a shallow copy only.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1413773

Erik Skultety (2):
  security: DAC: fix the transaction model's list append
  security: SELinux: fix the transaction model's list append

 src/security/security_dac.c | 30 +-
 src/security/security_selinux.c | 30 +-
 2 files changed, 42 insertions(+), 18 deletions(-)

-- 
2.10.2

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

Re: [libvirt] [PATCH 4/4] spec: Depend on the gluster command line tool

[Ján Tomko]

On Tue, Jan 10, 2017 at 07:44:59PM +0100, Peter Krempa wrote:

The gluster command line tool that is used to lookup storage pool
sources moved from the gluster-client package to gluster-cli.

Unfortunately the location differs between fedora and rhel so depend
on the package rather than binary.


How so?

All the packages I've looked at had it at /usr/sbin/gluster.

ACK if you make it depend on the path instead.

Jan



Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1349441
---
libvirt.spec.in | 4 
1 file changed, 4 insertions(+)


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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Boris Fiuczynski]

On 01/17/2017 02:21 PM, Michal Privoznik wrote:

  



With v2.5.0 everything has worked. I'll take a closer look to it today.

You can try and see if this is a namespace caused issue. Just disable
the namespaces and retry. If it succeeds with namespaces disabled, the
bug indeed is in my namespaces patches.

btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf

Michal


With disabled namespaces the problem does NOT occur.



--
Mit freundlichen Grüßen/Kind regards
   Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

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

[libvirt] [PATCH] qemu: Don't leak hostCPUModelInfo in virQEMUCaps

[Jiri Denemark]

Signed-off-by: Jiri Denemark 
---
 src/qemu/qemu_capabilities.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 2512e4838..89e9dd471 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2215,6 +2215,7 @@ void virQEMUCapsDispose(void *obj)
 
 VIR_FREE(qemuCaps->gicCapabilities);
 
+qemuMonitorCPUModelInfoFree(qemuCaps->hostCPUModelInfo);
 virCPUDefFree(qemuCaps->hostCPUModel);
 }
 
-- 
2.11.0

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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Michal Privoznik]

On 01/17/2017 02:13 PM, Marc Hartmayer wrote:
> Update:
> It's a SELinux labeling problem and seems to be introduced by the
> QEMU namespace patches.
> 

I wouldn't guess from the error message that qemu is getting EPERM.

Anyway, the SELinux issue is fixed in -rc2:

commit 93a062c3b293685024d60e841a37e93e303f4943
Author: Michal Privoznik 
AuthorDate: Fri Jan 13 10:03:23 2017 +0100
Commit: Michal Privoznik 
CommitDate: Fri Jan 13 14:45:52 2017 +0100

qemu: Copy SELinux labels for namespace too

When creating new /dev/* for qemu, we do chown() and copy ACLs to
create the exact copy from the original /dev. I though that
copying SELinux labels is not necessary as SELinux will chose the
sane defaults. Surprisingly, it does not leaving namespace with
the following labels:

crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 random
crw---. root root system_u:object_r:tmpfs_t:s0 rtc0
drwxrwxrwt. root root system_u:object_r:tmpfs_t:s0 shm
crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0 urandom

As a result, domain is unable to start:

error: internal error: process exited while connecting to monitor:
Error in GnuTLS initialization: Failed to acquire random data.
qemu-kvm: cannot initialize crypto: Unable to initialize GNUTLS
library: Failed to acquire random data.

The solution is to copy the SELinux labels as well.

Reported-by: Andrea Bolognani 
Signed-off-by: Michal Privoznik 


> On Tue, Jan 17, 2017 at 11:18 AM +0100, Marc Hartmayer 
>  wrote:
>> Hey,
>>
>> I have tried to live hot plug a disk backed on a qcow2 disk (see XML
>> snippet below) on a s390 system and I've got the following error
>> message:
>>
>> 
>> internal error: unable to execute QEMU command 'device_add': Property
>> 'scsi-hd.drive' can't find value 'drive-scsi0-0-0-0'
>> 
>>
>> 
>> 
>>   
>>   

My namespace patches should not clash with this as this isn't a device
from /dev/*. In the namespace, it's just /dev that is different to the
parent namespace. So anything else (e.g. under /tmp) is "shared" with
the parent namespace (it is the same mount in fact).

>>   
>> 
>> 
>>
>> With v2.5.0 everything has worked. I'll take a closer look to it today.

You can try and see if this is a namespace caused issue. Just disable
the namespaces and retry. If it succeeds with namespaces disabled, the
bug indeed is in my namespaces patches.

btw: to disable namespaces set: namespaces=[] in /etc/libvirt/qemu.conf

Michal

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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Marc Hartmayer]

Update:
It's a SELinux labeling problem and seems to be introduced by the
QEMU namespace patches.

On Tue, Jan 17, 2017 at 11:18 AM +0100, Marc Hartmayer 
 wrote:
> Hey,
>
> I have tried to live hot plug a disk backed on a qcow2 disk (see XML
> snippet below) on a s390 system and I've got the following error
> message:
>
> 
> internal error: unable to execute QEMU command 'device_add': Property
> 'scsi-hd.drive' can't find value 'drive-scsi0-0-0-0'
> 
>
> 
> 
>   
>   
>   
> 
> 
>
> With v2.5.0 everything has worked. I'll take a closer look to it today.
>
> Thanks,
>  Marc
>
>
>
> On Sat, Jan 14, 2017 at 11:02 PM +0100, Daniel Veillard  
> wrote:
>>   I missed the Friday deadline ot push it, so did it today. It's now tagged
>> in git, signed tarball and rpms are at the usual place:
>>ftp://libvirt.org/libvirt/
>>
>>  As a result I think GA should happen on Tuesday to give at least one
>> working day to raise critical issues. Nothing seems to have been reported
>> on rc1 neither positive nor negative, so please give it some testing.
>>
>>   thanks in advance,
>>
>> Daniel
>>
>> --
>> Daniel Veillard  | Open Source and Standards, Red Hat
>> veill...@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
>> http://veillard.com/ | virtualization library  http://libvirt.org/
>>
>> --
>> libvir-list mailing list
>> libvir-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list

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

Re: [libvirt] [PATCH 2/4] storage: gluster: Report error if no volumes were found in pool lookup

[Ján Tomko]

On Tue, Jan 10, 2017 at 07:44:57PM +0100, Peter Krempa wrote:

Similarly to the 'netfs' pool, return an error if the host does not have
any volumes.
---
src/storage/storage_backend_gluster.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)



ACK

Jan


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

Re: [libvirt] [PATCH 3/4] storage: gluster: Remove build-time dependency on the 'gluster' cli tool

[Ján Tomko]

On Tue, Jan 10, 2017 at 07:44:58PM +0100, Peter Krempa wrote:

The tool is used for pool discovery. Since we call an external binary we
don't really need to compile out the code that uses it. We can check
whether it exists at runtime.
---
configure.ac  |  2 +-
src/storage/storage_backend.c | 29 -
src/storage/storage_backend.h |  3 ++-
src/storage/storage_backend_fs.c  |  4 +---
src/storage/storage_backend_gluster.c |  2 +-
5 files changed, 21 insertions(+), 19 deletions(-)



ACK

Jan


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

Re: [libvirt] [PATCH 1/4] storage: Fix error reporting when looking up storage pool sources

[Ján Tomko]

On Tue, Jan 10, 2017 at 07:44:56PM +0100, Peter Krempa wrote:

In commit 4090e15399 we went back from reporting no errors if no storage
pools were found on a given host to reporting a bad error. And only in
cases when gluster was not installed.

Report a less bad error in case there are no volumes. Also report the
error when gluster is installed but no volumes were found, since
virStorageBackendFindGlusterPoolSources would return success in that
case.
---
src/storage/storage_backend.c| 19 ---
src/storage/storage_backend_fs.c | 20 ++--
2 files changed, 26 insertions(+), 13 deletions(-)



ACK

Jan


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

Re: [libvirt] [PATCH] qemu: Actually unshare() iff running as root

[Richard W.M. Jones]

On Tue, Jan 17, 2017 at 12:32:16PM +0100, Michal Privoznik wrote:
> While all the code that deals with qemu namespaces correctly
> detects whether we are running as root (and turn into NO-OP for
> qemu:///session) the actual unshare() call is not guarded with
> such check. Therefore any attempt to start a domain under
> qemu:///session shall fail as unshare() is reserved for root.
> 
> The fix consists of moving unshare() call (for which we have a
> wrapper called virProcessSetupPrivateMountNS) into
> qemuDomainBuildNamespace() where the proper check is performed.
> 
> Signed-off-by: Michal Privoznik 
> ---
>  src/qemu/qemu_domain.c  | 3 +++
>  src/qemu/qemu_process.c | 3 ---
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 35baffb51..c67604222 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -7400,6 +7400,9 @@ qemuDomainBuildNamespace(virQEMUDriverPtr driver,
>  goto cleanup;
>  }
>  
> +if (virProcessSetupPrivateMountNS() < 0)
> +goto cleanup;
> +
>  if (qemuDomainSetupDev(driver, vm, devPath) < 0)
>  goto cleanup;
>  
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index a980f5a9e..184440dc1 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -2663,9 +2663,6 @@ static int qemuProcessHook(void *data)
>  if (virSecurityManagerClearSocketLabel(h->driver->securityManager, 
> h->vm->def) < 0)
>  goto cleanup;
>  
> -if (virProcessSetupPrivateMountNS() < 0)
> -goto cleanup;
> -
>  if (qemuDomainBuildNamespace(h->driver, h->vm) < 0)
>  goto cleanup;

Tested-by: Richard W.M. Jones 

The commit message should also refer to the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1413922

Please make sure this bug blocks the release of 3.0.0.

Thanks,
Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

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

Re: [libvirt] How to generate better API documentation?

[Christophe Fergeau]

On Mon, Jan 16, 2017 at 09:17:03AM +, Daniel P. Berrange wrote:
> 
> To me the key factor is what the end result looks like, how easy it is to
> navigate & find stuff. From that POV doxygen is ruled out as the HTML it
> generates is just awful - I despair every time i find a project which has
> use doxygen for its API docs :-(
> 
> gtk-doc is pretty good in this respect, but the limitation is that they do
> not try to support every possible C style - they expect you to write code
> in a gobject like style. I can't tell offhand if libvirt is close enough
> to work with gtk-doc or not - I do know that QEMU failed. It is something
> you'd just have to try and see if it works, and also see if the result is
> better than what we have of course.

kernel people have been experimenting with Sphinx for both
linux/Documentation file, and inline source file documentation,
https://lwn.net/Articles/692704/

Christophe


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

Re: [libvirt] [PATCH] tests: fix QED disk test in xlconfigtest

[Joao Martins]

On 01/16/2017 06:45 PM, Jim Fehlig wrote:
> When LIBXL_HAVE_QED is defined, xlconfigtest fails
> 
>  9) Xen XL-2-XML Format disk-qed  ... command line: config parsing error
>  in disk specification: no vdev specified in
>  
> `target=/var/lib/libvirt/images/XenGuest2,format=qed,backendtype=qdisk,vdev=hda,access=rw'
> FAILED
> 
> As per the xl-disk-configuration(5) man page, target= must come
> last in the disk specification when specified by name:
> 
> When this parameter is specified by name, ie with the target=
> syntax in the configuration file, it consumes the whole rest of the
> DISKSPEC including trailing whitespaces.  Therefore in that case
> it must come last.
> 
> Change tests/xlconfigdata/test-disk-qed.cfg to adhere to this
> restriction.
> 
> Signed-off-by: Jim Fehlig 
Looks like Xen's osstest job doesn't run "make check" on the libvirt test case.
FWIW:

Acked-by: Joao Martins 

> ---
>  tests/xlconfigdata/test-disk-qed.cfg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/xlconfigdata/test-disk-qed.cfg 
> b/tests/xlconfigdata/test-disk-qed.cfg
> index ee904e0..7842176 100644
> --- a/tests/xlconfigdata/test-disk-qed.cfg
> +++ b/tests/xlconfigdata/test-disk-qed.cfg
> @@ -22,4 +22,4 @@ parallel = "none"
>  serial = "none"
>  builder = "hvm"
>  boot = "d"
> -disk = [ 
> "target=/var/lib/libvirt/images/XenGuest2,format=qed,backendtype=qdisk,vdev=hda,access=rw"
>  ]
> +disk = [ 
> "format=qed,backendtype=qdisk,vdev=hda,access=rw,target=/var/lib/libvirt/images/XenGuest2"
>  ]
> 

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

[libvirt] [PATCH] qemu: Actually unshare() iff running as root

[Michal Privoznik]

While all the code that deals with qemu namespaces correctly
detects whether we are running as root (and turn into NO-OP for
qemu:///session) the actual unshare() call is not guarded with
such check. Therefore any attempt to start a domain under
qemu:///session shall fail as unshare() is reserved for root.

The fix consists of moving unshare() call (for which we have a
wrapper called virProcessSetupPrivateMountNS) into
qemuDomainBuildNamespace() where the proper check is performed.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_domain.c  | 3 +++
 src/qemu/qemu_process.c | 3 ---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 35baffb51..c67604222 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -7400,6 +7400,9 @@ qemuDomainBuildNamespace(virQEMUDriverPtr driver,
 goto cleanup;
 }
 
+if (virProcessSetupPrivateMountNS() < 0)
+goto cleanup;
+
 if (qemuDomainSetupDev(driver, vm, devPath) < 0)
 goto cleanup;
 
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index a980f5a9e..184440dc1 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -2663,9 +2663,6 @@ static int qemuProcessHook(void *data)
 if (virSecurityManagerClearSocketLabel(h->driver->securityManager, 
h->vm->def) < 0)
 goto cleanup;
 
-if (virProcessSetupPrivateMountNS() < 0)
-goto cleanup;
-
 if (qemuDomainBuildNamespace(h->driver, h->vm) < 0)
 goto cleanup;
 
-- 
2.11.0

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

Re: [libvirt] Availability of libvirt-3.0.0 release candidate 2

[Marc Hartmayer]

Hey,

I have tried to live hot plug a disk backed on a qcow2 disk (see XML
snippet below) on a s390 system and I've got the following error
message:


internal error: unable to execute QEMU command 'device_add': Property
'scsi-hd.drive' can't find value 'drive-scsi0-0-0-0'




  
  
  



With v2.5.0 everything has worked. I'll take a closer look to it today.

Thanks,
 Marc



On Sat, Jan 14, 2017 at 11:02 PM +0100, Daniel Veillard  
wrote:
>   I missed the Friday deadline ot push it, so did it today. It's now tagged
> in git, signed tarball and rpms are at the usual place:
>ftp://libvirt.org/libvirt/
>
>  As a result I think GA should happen on Tuesday to give at least one
> working day to raise critical issues. Nothing seems to have been reported
> on rc1 neither positive nor negative, so please give it some testing.
>
>   thanks in advance,
>
> Daniel
>
> --
> Daniel Veillard  | Open Source and Standards, Red Hat
> veill...@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | virtualization library  http://libvirt.org/
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

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

Re: [libvirt] [PATCH] tests: fix compilation of shunloadtest

[Pavel Hrdina]

On Mon, Jan 16, 2017 at 11:06:17AM -0700, Jim Fehlig wrote:
> While local builds succeed fine, a build worker building in a
> chroot environment is encountering the following error with
> libvirt 3.0.0 release candidates
> 
> [  162s] shunloadtest.o: In function `main':
> [  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:110: 
> undefined reference to `dlopen'
> [  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:114: 
> undefined reference to `dlsym'
> [  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:133: 
> undefined reference to `dlclose'
> [  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:111: 
> undefined reference to `dlerror'
> [  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:115: 
> undefined reference to `dlerror'
> [  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:116: 
> undefined reference to `dlclose'
> 
> Fix by appending LDADDS to shunloadtest_LDADD.
> 
> Signed-off-by: Jim Fehlig 
> ---
>  tests/Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index c7d4748..112396f 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -1348,7 +1348,7 @@ libshunload_la_LDFLAGS = $(MOCKLIBS_LDFLAGS)
>  
>  shunloadtest_SOURCES = \
>   shunloadtest.c
> -shunloadtest_LDADD = $(LIB_PTHREAD)
> +shunloadtest_LDADD = $(LIB_PTHREAD) $(LDADDS)

I don't thing that this is a correct fix.  Some of the libs from LDADDS may
include the dlopen libs but you cannot count on that.  It should be enough to
add $(DLOPEN_LIBS).

Pavel

>  shunloadtest_DEPENDENCIES = libshunload.la
>  
>  sysinfotest_SOURCES = \
> -- 
> 2.9.2
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list


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

Re: [libvirt] [PATCH v2 0/4] Virtio-crypto device support

[Longpeng (Mike)]

Hi,

Ping... :)

Regards,
Longpeng(Mike)

On 2017/1/11 16:28, Longpeng(Mike) wrote:

> As virtio-crypto has been supported in QEMU 2.8 and the frontend
> driver has been merged in linux 4.10, so it's necessary to support
> virtio-crypto in libvirt.
> 
> ---
> Changes since v1:
>   - split patch [Martin]
>   - rebase on master [Martin]
>   - add docs/tests/schema [Martin]
>   - fix typos [Gonglei]
> 
> ---
> Longpeng(Mike) (4):
>   docs: schema: Add basic documentation for the virtual crypto device
> support
>   conf: Parse virtio-crypto in the domain XML
>   qemu: Implement support for 'builtin' backend for virtio-crypto
>   tests: Add testcase for virtio-crypto XML parsing
> 
>  docs/formatdomain.html.in  |  60 ++
>  docs/schemas/domaincommon.rng  |  27 +++
>  src/conf/domain_conf.c | 213 
> -
>  src/conf/domain_conf.h |  32 
>  src/libvirt_private.syms   |   2 +
>  src/qemu/qemu_alias.c  |  20 ++
>  src/qemu/qemu_alias.h  |   3 +
>  src/qemu/qemu_capabilities.c   |   4 +
>  src/qemu/qemu_capabilities.h   |   2 +
>  src/qemu/qemu_command.c| 132 +
>  src/qemu/qemu_command.h|   3 +
>  src/qemu/qemu_domain.c |   2 +
>  src/qemu/qemu_domain_address.c |  25 +++
>  src/qemu/qemu_driver.c |   6 +
>  src/qemu/qemu_hotplug.c|   1 +
>  tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml|   2 +
>  tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml   |   2 +
>  .../qemuxml2argv-virtio-crypto-builtin.xml |  26 +++
>  .../qemuxml2argv-virtio-crypto.args|  22 +++
>  .../qemuxml2xmlout-virtio-crypto-builtin.xml   |  31 +++
>  tests/qemuxml2xmltest.c|   2 +
>  21 files changed, 616 insertions(+), 1 deletion(-)
>  create mode 100644 
> tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-builtin.xml
>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto.args
>  create mode 100644 
> tests/qemuxml2xmloutdata/qemuxml2xmlout-virtio-crypto-builtin.xml
> 


-- 
Regards,
Longpeng(Mike)

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