[libvirt] [PATCH] libvirt:spec: Require gcc for build

2018-03-11 Thread Michal Privoznik
According to latest discussion on fedora devel list [1] gcc will
be removed from default buildroot and packages requiring it must
have explicit build dependency,

1: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/IJFYI5Q2BYZKIGDFS2WLOBDUSEGWHIKV/

Signed-off-by: Michal Privoznik 
---
 libvirt.spec.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libvirt.spec.in b/libvirt.spec.in
index 8f46f58b5..5e05d706f 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -298,6 +298,7 @@ BuildRequires: gettext-devel
 BuildRequires: libtool
 BuildRequires: /usr/bin/pod2man
 %endif
+BuildRequires: gcc
 BuildRequires: git
 %if 0%{?fedora} >= 27 || 0%{?rhel} > 7
 BuildRequires: perl-interpreter
-- 
2.16.1

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


Re: [libvirt] libvirt-snmp status

2018-03-11 Thread Michal Privoznik
On 03/10/2018 04:19 AM, Michael Corcoran wrote:
> Hi All,

Hey,

> 
> I'd like to enquire about the status of libvirt-snmp. It hasn't had any
>  commits for a couple of years and no longer compiles against recent
> versions of net-snmp.

Yes, your observation is correct. libvirt-snmp is no longer maintained.
The build problem you ran into is just the tip of the iceberg. The
biggest problem IMO is that originally sources were generated using a
script from net-snmp package. While it did the trick back then it
rendered sources unmaintanable.

> As I understand it, upstream net-snmp deprecated
> and then removed the C type "U64" as it conflicts with Perl.
> Fortunately this is the only issue and the patch required to get
> libvirt-snmp building again simply replaces the C type "U64" with the
> type "struct counter64" in a few places. I tried to  submit a patch but
> was unable to configure authentication/encryption correctly for git
> send-email and I'm unwilling to spend more time on it. Is there any way
> to accept patches directly from Github (or anywhere else I can push a
> commit)?

Ah, let me see it that will fix the build. .. .. ..  And it does. So
another trick to send a patch is to attach it to an e-mail sent to the list.

> 
> My second enquiry relates to the org OID used in the LIBVIRT-MIB. It
> currently uses a (presumably) placeholder of 12345. I check the OID
> register[1] and found an entry for libvirt (see end of email). I am
> guessing that registration didn't go through until after libvirt-snmp
> maintenance stopped. I'd like to submit a patch to replace the
> placeholder with this org id also.

Yes, the registration did not go through. In fact it hadn't even
started. Again, any patch is more than welcome.

Michal

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


Re: [libvirt] [PATCH 04/20] libxl: Use virDomainObjListFindBy{UUID|ID}Ref

2018-03-11 Thread Jim Fehlig

On 03/09/2018 09:48 AM, John Ferlan wrote:

For libxlDomainLookupByID and libxlDomainLookupByUUID let's
return a locked and referenced @vm object so that callers can
then use the common and more consistent virDomainObjEndAPI in
order to handle cleanup rather than needing to know that the
returned object is locked and calling virObjectUnlock.

The LookupByName already returns the ref counted and locked object,
so this will make things more consistent.

Signed-off-by: John Ferlan 
---
  src/libxl/libxl_driver.c | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)


Reviewed-by: Jim Fehlig 

Regards,
Jim



diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 9aa4a293c..e78fe2d4b 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -1090,7 +1090,7 @@ libxlDomainLookupByID(virConnectPtr conn, int id)
  virDomainObjPtr vm;
  virDomainPtr dom = NULL;
  
-vm = virDomainObjListFindByID(driver->domains, id);

+vm = virDomainObjListFindByIDRef(driver->domains, id);
  if (!vm) {
  virReportError(VIR_ERR_NO_DOMAIN, NULL);
  goto cleanup;
@@ -1102,8 +1102,7 @@ libxlDomainLookupByID(virConnectPtr conn, int id)
  dom = virGetDomain(conn, vm->def->name, vm->def->uuid, vm->def->id);
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  return dom;
  }
  
@@ -1114,7 +1113,7 @@ libxlDomainLookupByUUID(virConnectPtr conn, const unsigned char *uuid)

  virDomainObjPtr vm;
  virDomainPtr dom = NULL;
  
-vm = virDomainObjListFindByUUID(driver->domains, uuid);

+vm = virDomainObjListFindByUUIDRef(driver->domains, uuid);
  if (!vm) {
  virReportError(VIR_ERR_NO_DOMAIN, NULL);
  goto cleanup;
@@ -1126,8 +1125,7 @@ libxlDomainLookupByUUID(virConnectPtr conn, const 
unsigned char *uuid)
  dom = virGetDomain(conn, vm->def->name, vm->def->uuid, vm->def->id);
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  return dom;
  }
  



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


Re: [libvirt] [PATCH 03/20] libxl: Properly cleanup after libxlDomObjFromDomain

2018-03-11 Thread Jim Fehlig

On 03/09/2018 09:47 AM, John Ferlan wrote:

Commit id '9ac945078' altered libxlDomObjFromDomain to return
a locked *and* ref counted object for some specific purposes;
however, it neglected to alter all the consumers of the helper
to use virDomainObjEndAPI thus leaving many objects with extra
ref counts.

The two consumers for libxlDomainMigrationConfirm would also
originally use the libxlDomObjFromDomain API (either from
libxlDomainMigrateConfirm3Params or libxlDoMigrateP2P via
libxlDomainMigrationPerformP2P and libxlDomainMigratePerform3Params.

Signed-off-by: John Ferlan 
---
  src/libxl/libxl_driver.c| 86 -
  src/libxl/libxl_migration.c |  3 +-
  2 files changed, 31 insertions(+), 58 deletions(-)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index b5101626e..9aa4a293c 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -1322,8 +1322,7 @@ libxlDomainShutdownFlags(virDomainPtr dom, unsigned int 
flags)
  }
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  virObjectUnref(cfg);
  return ret;
  }
@@ -1373,8 +1372,7 @@ libxlDomainReboot(virDomainPtr dom, unsigned int flags)
  }
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  virObjectUnref(cfg);
  return ret;
  }
@@ -1459,8 +1457,7 @@ libxlDomainGetOSType(virDomainPtr dom)
  goto cleanup;
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  return type;
  }
  
@@ -1479,8 +1476,7 @@ libxlDomainGetMaxMemory(virDomainPtr dom)

  ret = virDomainDefGetMemoryTotal(vm->def);
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  return ret;
  }
  
@@ -1658,8 +1654,7 @@ libxlDomainGetInfo(virDomainPtr dom, virDomainInfoPtr info)

  ret = 0;
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  virObjectUnref(cfg);
  return ret;
  }
@@ -1685,8 +1680,7 @@ libxlDomainGetState(virDomainPtr dom,
  ret = 0;
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  return ret;
  }
  
@@ -2110,8 +2104,7 @@ libxlDomainHasManagedSaveImage(virDomainPtr dom, unsigned int flags)

  ret = vm->hasManagedSave;
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  return ret;
  }
  
@@ -2140,8 +2133,7 @@ libxlDomainManagedSaveRemove(virDomainPtr dom, unsigned int flags)
  
   cleanup:

  VIR_FREE(name);
-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  return ret;
  }
  
@@ -2352,8 +2344,7 @@ libxlDomainGetVcpusFlags(virDomainPtr dom, unsigned int flags)

  ret = virDomainDefGetVcpus(def);
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  return ret;
  }
  
@@ -2484,8 +2475,7 @@ libxlDomainGetVcpuPinInfo(virDomainPtr dom, int ncpumaps,

 libxl_get_max_cpus(cfg->ctx), 
NULL);
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  virObjectUnref(cfg);
  return ret;
  }
@@ -2548,8 +2538,7 @@ libxlDomainGetVcpus(virDomainPtr dom, virVcpuInfoPtr 
info, int maxinfo,
  ret = maxinfo;
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  virObjectUnref(cfg);
  return ret;
  }
@@ -2580,8 +2569,7 @@ libxlDomainGetXMLDesc(virDomainPtr dom, unsigned int 
flags)
   virDomainDefFormatConvertXMLFlags(flags));
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  virObjectUnref(cfg);
  return ret;
  }
@@ -2901,8 +2889,7 @@ libxlDomainUndefineFlags(virDomainPtr dom,
  
   cleanup:

  VIR_FREE(name);
-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  if (event)
  libxlDomainEventQueue(driver, event);
  virObjectUnref(cfg);
@@ -4261,8 +4248,7 @@ libxlDomainUpdateDeviceFlags(virDomainPtr dom, const char 
*xml,
   cleanup:
  virDomainDefFree(vmdef);
  virDomainDeviceDefFree(dev);
-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  virObjectUnref(cfg);
  return ret;
  }
@@ -4394,8 +4380,7 @@ libxlDomainGetAutostart(virDomainPtr dom, int *autostart)
  ret = 0;
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  return ret;
  }
  
@@ -4521,8 +4506,7 @@ libxlDomainGetSchedulerType(virDomainPtr dom, int *nparams)

  ignore_value(VIR_STRDUP(ret, name));
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  virObjectUnref(cfg);
  return ret;
  }
@@ -4587,8 +4571,7 @@ libxlDomainGetSchedulerParametersFlags(virDomainPtr dom,
  ret = 0;
  
   cleanup:

-if (vm)
-virObjectUnlock(vm);
+virDomainObjEndAPI();
  virObjectUnref(cfg);
 

[libvirt] [PATCH] bhyve: fix crash on missing interface model

2018-03-11 Thread Roman Bogorodskiy
The bhyve driver crashes in bhyveBuildNetArgStr() when
network interface model is not defined. As it has to be provided
explicitly, add a check to report an error if it's missing.
---
 src/bhyve/bhyve_command.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c
index ec5d24012..9413ae5c1 100644
--- a/src/bhyve/bhyve_command.c
+++ b/src/bhyve/bhyve_command.c
@@ -56,6 +56,12 @@ bhyveBuildNetArgStr(virConnectPtr conn,
 int ret = -1;
 virDomainNetType actualType = virDomainNetGetActualType(net);
 
+if (net->model == NULL) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+   _("NIC model must be specified"));
+return -1;
+}
+
 if (STREQ(net->model, "virtio")) {
 if (VIR_STRDUP(nic_model, "virtio-net") < 0)
 return -1;
-- 
2.16.2

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


[libvirt] [PATCH] Fix build with clang 6.0.0

2018-03-11 Thread Roman Bogorodskiy
Clang 6.0.0 complains when initializing structure with { NULL }:

conf/domain_addr.c:1494:38: error: missing field 'type' initializer 
[-Werror,-Wmissing-field-initializers]
virDomainDeviceInfo nfo = { NULL };

Use { 0 } instead to make it happy.
---
 src/conf/domain_addr.c | 2 +-
 tests/sysinfotest.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 5e875a3e6..0c914fe25 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -1491,7 +1491,7 @@ virDomainVirtioSerialAddrAssign(virDomainDefPtr def,
 bool portOnly)
 {
 int ret = -1;
-virDomainDeviceInfo nfo = { NULL };
+virDomainDeviceInfo nfo = { 0 };
 virDomainDeviceInfoPtr ptr = allowZero ?  : info;
 
 ptr->type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_SERIAL;
diff --git a/tests/sysinfotest.c b/tests/sysinfotest.c
index a61da017c..53d5725fd 100644
--- a/tests/sysinfotest.c
+++ b/tests/sysinfotest.c
@@ -91,7 +91,7 @@ sysinfotest_run(const char *test,
 const char *cpuinfo,
 const char *expected)
 {
-struct testSysinfoData testdata = { NULL };
+struct testSysinfoData testdata = { 0 };
 int ret = EXIT_FAILURE;
 
 testdata.func = func;
-- 
2.16.2

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