Rather than expecting callers to pass a virConnectPtr into the
virDomainDiskTranslateSourcePool() method, just acquire a connection
to the storage driver when needed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
src/conf/domain_conf.c | 10 +++++++---
src/conf/domain_conf.h | 3 +--
src/qemu/qemu_conf.c | 3 +--
src/qemu/qemu_conf.h | 3 +--
src/qemu/qemu_driver.c | 39 ++++++++++++++++-----------------------
src/qemu/qemu_hotplug.c | 2 +-
src/qemu/qemu_process.c | 4 ++--
tests/qemuxml2argvtest.c | 5 +++++
8 files changed, 34 insertions(+), 35 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 4f50547580..613e34f8c4 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -29068,9 +29068,9 @@ virDomainDiskTranslateSourcePoolAuth(virDomainDiskDefPtr def,
int
-virDomainDiskTranslateSourcePool(virConnectPtr conn,
- virDomainDiskDefPtr def)
+virDomainDiskTranslateSourcePool(virDomainDiskDefPtr def)
{
+ virConnectPtr conn = NULL;
virStoragePoolDefPtr pooldef = NULL;
virStoragePoolPtr pool = NULL;
virStorageVolPtr vol = NULL;
@@ -29084,9 +29084,12 @@ virDomainDiskTranslateSourcePool(virConnectPtr conn,
if (!def->src->srcpool)
return 0;
- if (!(pool = virStoragePoolLookupByName(conn, def->src->srcpool->pool)))
+ if (!(conn = virGetConnectStorage()))
return -1;
+ if (!(pool = virStoragePoolLookupByName(conn, def->src->srcpool->pool)))
+ goto cleanup;
+
if (virStoragePoolIsActive(pool) != 1) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("storage pool '%s' containing volume '%s' "
@@ -29230,6 +29233,7 @@ virDomainDiskTranslateSourcePool(virConnectPtr conn,
ret = 0;
cleanup:
+ virObjectUnref(conn);
virObjectUnref(pool);
virObjectUnref(vol);
VIR_FREE(poolxml);
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 7b450ce8f1..8be08bc9b3 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -3514,8 +3514,7 @@ virDomainNetResolveActualType(virDomainNetDefPtr iface)
ATTRIBUTE_NONNULL(1);
-int virDomainDiskTranslateSourcePool(virConnectPtr conn,
- virDomainDiskDefPtr def);
+int virDomainDiskTranslateSourcePool(virDomainDiskDefPtr def);
#endif /* __DOMAIN_CONF_H */
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index af503d31cb..36cf3a281c 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1631,8 +1631,7 @@ int qemuDriverAllocateID(virQEMUDriverPtr driver)
int
-qemuTranslateSnapshotDiskSourcePool(virConnectPtr conn ATTRIBUTE_UNUSED,
- virDomainSnapshotDiskDefPtr def)
+qemuTranslateSnapshotDiskSourcePool(virDomainSnapshotDiskDefPtr def)
{
if (def->src->type != VIR_STORAGE_TYPE_VOLUME)
return 0;
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index a553e30e2e..83fd452827 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -349,8 +349,7 @@ int qemuSetUnprivSGIO(virDomainDeviceDefPtr dev);
int qemuDriverAllocateID(virQEMUDriverPtr driver);
virDomainXMLOptionPtr virQEMUDriverCreateXMLConf(virQEMUDriverPtr driver);
-int qemuTranslateSnapshotDiskSourcePool(virConnectPtr conn,
- virDomainSnapshotDiskDefPtr def);
+int qemuTranslateSnapshotDiskSourcePool(virDomainSnapshotDiskDefPtr def);
char * qemuGetBaseHugepagePath(virHugeTLBFSPtr hugepage);
char * qemuGetDomainHugepagePath(const virDomainDef *def,
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 134deb05a0..031bdeb5f6 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7871,8 +7871,7 @@ qemuDomainDetachDeviceLive(virDomainObjPtr vm,
}
static int
-qemuDomainChangeDiskLive(virConnectPtr conn,
- virDomainObjPtr vm,
+qemuDomainChangeDiskLive(virDomainObjPtr vm,
virDomainDeviceDefPtr dev,
virQEMUDriverPtr driver,
bool force)
@@ -7881,7 +7880,7 @@ qemuDomainChangeDiskLive(virConnectPtr conn,
virDomainDiskDefPtr orig_disk = NULL;
int ret = -1;
- if (virDomainDiskTranslateSourcePool(conn, disk) < 0)
+ if (virDomainDiskTranslateSourcePool(disk) < 0)
goto cleanup;
if (qemuDomainDetermineDiskChain(driver, vm, disk, false, true) < 0)
@@ -7932,8 +7931,7 @@ qemuDomainChangeDiskLive(virConnectPtr conn,
}
static int
-qemuDomainUpdateDeviceLive(virConnectPtr conn,
- virDomainObjPtr vm,
+qemuDomainUpdateDeviceLive(virDomainObjPtr vm,
virDomainDeviceDefPtr dev,
virDomainPtr dom,
bool force)
@@ -7944,7 +7942,7 @@ qemuDomainUpdateDeviceLive(virConnectPtr conn,
switch ((virDomainDeviceType) dev->type) {
case VIR_DOMAIN_DEVICE_DISK:
qemuDomainObjCheckDiskTaint(driver, vm, dev->data.disk, NULL);
- ret = qemuDomainChangeDiskLive(conn, vm, dev, driver, force);
+ ret = qemuDomainChangeDiskLive(vm, dev, driver, force);
break;
case VIR_DOMAIN_DEVICE_GRAPHICS:
ret = qemuDomainChangeGraphics(driver, vm, dev->data.graphics);
@@ -7986,7 +7984,6 @@ qemuDomainUpdateDeviceLive(virConnectPtr conn,
static int
qemuDomainAttachDeviceConfig(virDomainDefPtr vmdef,
virDomainDeviceDefPtr dev,
- virConnectPtr conn,
virCapsPtr caps,
unsigned int parse_flags,
virDomainXMLOptionPtr xmlopt)
@@ -8008,7 +8005,7 @@ qemuDomainAttachDeviceConfig(virDomainDefPtr vmdef,
_("target %s already exists"), disk->dst);
return -1;
}
- if (virDomainDiskTranslateSourcePool(conn, disk) < 0)
+ if (virDomainDiskTranslateSourcePool(disk) < 0)
return -1;
if (qemuCheckDiskConfig(disk, NULL) < 0)
return -1;
@@ -8494,7 +8491,7 @@ qemuDomainAttachDeviceLiveAndConfig(virConnectPtr conn,
if (virDomainDefCompatibleDevice(vmdef, dev) < 0)
goto cleanup;
- if ((ret = qemuDomainAttachDeviceConfig(vmdef, dev, conn, caps,
+ if ((ret = qemuDomainAttachDeviceConfig(vmdef, dev, caps,
parse_flags,
driver->xmlopt)) < 0)
goto cleanup;
@@ -8654,7 +8651,7 @@ static int qemuDomainUpdateDeviceFlags(virDomainPtr dom,
if (virDomainDefCompatibleDevice(vm->def, dev_copy) < 0)
goto endjob;
- if ((ret = qemuDomainUpdateDeviceLive(dom->conn, vm, dev_copy, dom, force)) < 0)
+ if ((ret = qemuDomainUpdateDeviceLive(vm, dev_copy, dom, force)) < 0)
goto endjob;
/*
* update domain status forcibly because the domain status may be
@@ -14229,8 +14226,7 @@ qemuDomainSnapshotPrepareDiskExternalActive(virDomainSnapshotDiskDefPtr snapdisk
static int
-qemuDomainSnapshotPrepareDiskExternal(virConnectPtr conn,
- virDomainDiskDefPtr disk,
+qemuDomainSnapshotPrepareDiskExternal(virDomainDiskDefPtr disk,
virDomainSnapshotDiskDefPtr snapdisk,
bool active,
bool reuse)
@@ -14238,11 +14234,11 @@ qemuDomainSnapshotPrepareDiskExternal(virConnectPtr conn,
int ret = -1;
struct stat st;
- if (qemuTranslateSnapshotDiskSourcePool(conn, snapdisk) < 0)
+ if (qemuTranslateSnapshotDiskSourcePool(snapdisk) < 0)
return -1;
if (!active) {
- if (virDomainDiskTranslateSourcePool(conn, disk) < 0)
+ if (virDomainDiskTranslateSourcePool(disk) < 0)
return -1;
if (qemuDomainSnapshotPrepareDiskExternalInactive(snapdisk, disk) < 0)
@@ -14284,8 +14280,7 @@ qemuDomainSnapshotPrepareDiskExternal(virConnectPtr conn,
static int
-qemuDomainSnapshotPrepareDiskInternal(virConnectPtr conn,
- virDomainDiskDefPtr disk,
+qemuDomainSnapshotPrepareDiskInternal(virDomainDiskDefPtr disk,
bool active)
{
int actualType;
@@ -14294,7 +14289,7 @@ qemuDomainSnapshotPrepareDiskInternal(virConnectPtr conn,
if (active)
return 0;
- if (virDomainDiskTranslateSourcePool(conn, disk) < 0)
+ if (virDomainDiskTranslateSourcePool(disk) < 0)
return -1;
actualType = virStorageSourceGetActualType(disk->src);
@@ -14343,8 +14338,7 @@ qemuDomainSnapshotPrepareDiskInternal(virConnectPtr conn,
static int
-qemuDomainSnapshotPrepare(virConnectPtr conn,
- virDomainObjPtr vm,
+qemuDomainSnapshotPrepare(virDomainObjPtr vm,
virDomainSnapshotDefPtr def,
unsigned int *flags)
{
@@ -14385,7 +14379,7 @@ qemuDomainSnapshotPrepare(virConnectPtr conn,
goto cleanup;
}
- if (qemuDomainSnapshotPrepareDiskInternal(conn, dom_disk,
+ if (qemuDomainSnapshotPrepareDiskInternal(dom_disk,
active) < 0)
goto cleanup;
@@ -14414,7 +14408,7 @@ qemuDomainSnapshotPrepare(virConnectPtr conn,
goto cleanup;
}
- if (qemuDomainSnapshotPrepareDiskExternal(conn, dom_disk, disk,
+ if (qemuDomainSnapshotPrepareDiskExternal(dom_disk, disk,
active, reuse) < 0)
goto cleanup;
@@ -15062,7 +15056,6 @@ qemuDomainSnapshotCreateXML(virDomainPtr domain,
const char *xmlDesc,
unsigned int flags)
{
- virConnectPtr conn = domain->conn;
virQEMUDriverPtr driver = domain->conn->privateData;
virDomainObjPtr vm = NULL;
char *xml = NULL;
@@ -15241,7 +15234,7 @@ qemuDomainSnapshotCreateXML(virDomainPtr domain,
}
if (virDomainSnapshotAlignDisks(def, align_location,
align_match) < 0 ||
- qemuDomainSnapshotPrepare(conn, vm, def, &flags) < 0)
+ qemuDomainSnapshotPrepare(vm, def, &flags) < 0)
goto endjob;
}
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index c9868de778..ee8b53b719 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -713,7 +713,7 @@ qemuDomainAttachDeviceDiskLive(virConnectPtr conn,
goto cleanup;
}
- if (virDomainDiskTranslateSourcePool(conn, disk) < 0)
+ if (virDomainDiskTranslateSourcePool(disk) < 0)
goto cleanup;
if (qemuAddSharedDevice(driver, dev, vm->def->name) < 0)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index d0a25cecb9..586d11bba3 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -5603,7 +5603,7 @@ qemuProcessPrepareDomainStorage(virConnectPtr conn,
size_t idx = i - 1;
virDomainDiskDefPtr disk = vm->def->disks[idx];
- if (virDomainDiskTranslateSourcePool(conn, disk) < 0) {
+ if (virDomainDiskTranslateSourcePool(disk) < 0) {
if (qemuDomainCheckDiskStartupPolicy(driver, vm, idx, cold_boot) < 0)
return -1;
@@ -7362,7 +7362,7 @@ qemuProcessReconnect(void *opaque)
virDomainDiskDefPtr disk = obj->def->disks[i];
virDomainDeviceDef dev;
- if (virDomainDiskTranslateSourcePool(conn, disk) < 0)
+ if (virDomainDiskTranslateSourcePool(disk) < 0)
goto error;
/* backing chains need to be refreshed only if they could change */
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index b341467143..fa261fc805 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -429,6 +429,9 @@ testCompareXMLToArgv(const void *data)
conn->secretDriver = &fakeSecretDriver;
conn->storageDriver = &fakeStorageDriver;
+ virSetConnectSecret(conn);
+ virSetConnectStorage(conn);
+
if (virQEMUCapsGet(info->qemuCaps, QEMU_CAPS_MONITOR_JSON))
flags |= FLAG_JSON;
@@ -536,6 +539,8 @@ testCompareXMLToArgv(const void *data)
virDomainChrSourceDefClear(&monitor_chr);
virCommandFree(cmd);
virObjectUnref(vm);
+ virSetConnectSecret(NULL);
+ virSetConnectStorage(NULL);
virObjectUnref(conn);
VIR_FREE(migrateURI);
VIR_FREE(xml);
--
2.14.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 02/15/2018 11:50 AM, Daniel P. Berrangé wrote:
> Rather than expecting callers to pass a virConnectPtr into the
> virDomainDiskTranslateSourcePool() method, just acquire a connection
> to the storage driver when needed.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
> src/conf/domain_conf.c | 10 +++++++---
> src/conf/domain_conf.h | 3 +--
> src/qemu/qemu_conf.c | 3 +--
> src/qemu/qemu_conf.h | 3 +--
> src/qemu/qemu_driver.c | 39 ++++++++++++++++-----------------------
> src/qemu/qemu_hotplug.c | 2 +-
> src/qemu/qemu_process.c | 4 ++--
> tests/qemuxml2argvtest.c | 5 +++++
> 8 files changed, 34 insertions(+), 35 deletions(-)
>
Reviewed-by: John Ferlan <jferlan@redhat.com>
John
FWIW:
I've been trying to run the avocado tests as an "extra" way to ensure
nothing has been messed up, but something (before this series) has
caused my virt-install to be less than happy <sigh> - I'm sure some of
it is self inflicted, but the error is making me wonder:
2018-02-16 02:07:55.517+0000: 31492: error :
qemuProcessReportLogError:1928 : internal error: qemu unexpectedly
closed the monitor: 2018-02-16T02:07:55.479523Z qemu-system-x86_64:
can't apply global Haswell-noTSX-x86_64-cpu.spec-ctrl=on: Property
'.spec-ctrl' not found
I also tried running the virt-manager tests, but running from top of
tree fails with the urllib.parse failure:
...
File "/home/jferlan/github/virt-manager/tests/__init__.py", line 33,
in <module>
from tests import utils
File "/home/jferlan/github/virt-manager/tests/utils.py", line 21, in
<module>
import virtinst
File "/home/jferlan/github/virt-manager/virtinst/__init__.py", line
41, in <module>
from virtinst.uri import URI
File "/home/jferlan/github/virt-manager/virtinst/uri.py", line 22, in
<module>
import urllib.parse
ImportError: No module named parse
I narrowed it down to commit '3086c7fd' via git bisect and sent an email
to Cole. <sigh>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Feb 15, 2018 at 21:59:45 -0500, John Ferlan wrote: > > > On 02/15/2018 11:50 AM, Daniel P. Berrangé wrote: > > Rather than expecting callers to pass a virConnectPtr into the > > virDomainDiskTranslateSourcePool() method, just acquire a connection > > to the storage driver when needed. > > > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > > --- > > src/conf/domain_conf.c | 10 +++++++--- > > src/conf/domain_conf.h | 3 +-- > > src/qemu/qemu_conf.c | 3 +-- > > src/qemu/qemu_conf.h | 3 +-- > > src/qemu/qemu_driver.c | 39 ++++++++++++++++----------------------- > > src/qemu/qemu_hotplug.c | 2 +- > > src/qemu/qemu_process.c | 4 ++-- > > tests/qemuxml2argvtest.c | 5 +++++ > > 8 files changed, 34 insertions(+), 35 deletions(-) > > > > Reviewed-by: John Ferlan <jferlan@redhat.com> > > John > > FWIW: > > I've been trying to run the avocado tests as an "extra" way to ensure > nothing has been messed up, but something (before this series) has > caused my virt-install to be less than happy <sigh> - I'm sure some of > it is self inflicted, but the error is making me wonder: > > 2018-02-16 02:07:55.517+0000: 31492: error : > qemuProcessReportLogError:1928 : internal error: qemu unexpectedly > closed the monitor: 2018-02-16T02:07:55.479523Z qemu-system-x86_64: > can't apply global Haswell-noTSX-x86_64-cpu.spec-ctrl=on: Property > '.spec-ctrl' not found Most likely virt-install is selecting incorrect CPU model, i.e., the one from host capabilities. The CPU definition from host capabilities contains all features supported by the CPU (and known to libvirt) even if a particular QEMU binary does not support them. Try running virt-install with "--cpu host-model". This should work as long as QEMU is new enough (>= 2.10 IIRC). Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 02/16/2018 08:48 AM, Jiri Denemark wrote: > On Thu, Feb 15, 2018 at 21:59:45 -0500, John Ferlan wrote: >> >> >> On 02/15/2018 11:50 AM, Daniel P. Berrangé wrote: >>> Rather than expecting callers to pass a virConnectPtr into the >>> virDomainDiskTranslateSourcePool() method, just acquire a connection >>> to the storage driver when needed. >>> >>> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> >>> --- >>> src/conf/domain_conf.c | 10 +++++++--- >>> src/conf/domain_conf.h | 3 +-- >>> src/qemu/qemu_conf.c | 3 +-- >>> src/qemu/qemu_conf.h | 3 +-- >>> src/qemu/qemu_driver.c | 39 ++++++++++++++++----------------------- >>> src/qemu/qemu_hotplug.c | 2 +- >>> src/qemu/qemu_process.c | 4 ++-- >>> tests/qemuxml2argvtest.c | 5 +++++ >>> 8 files changed, 34 insertions(+), 35 deletions(-) >>> >> >> Reviewed-by: John Ferlan <jferlan@redhat.com> >> >> John >> >> FWIW: >> >> I've been trying to run the avocado tests as an "extra" way to ensure >> nothing has been messed up, but something (before this series) has >> caused my virt-install to be less than happy <sigh> - I'm sure some of >> it is self inflicted, but the error is making me wonder: >> >> 2018-02-16 02:07:55.517+0000: 31492: error : >> qemuProcessReportLogError:1928 : internal error: qemu unexpectedly >> closed the monitor: 2018-02-16T02:07:55.479523Z qemu-system-x86_64: >> can't apply global Haswell-noTSX-x86_64-cpu.spec-ctrl=on: Property >> '.spec-ctrl' not found > > Most likely virt-install is selecting incorrect CPU model, i.e., the one > from host capabilities. The CPU definition from host capabilities > contains all features supported by the CPU (and known to libvirt) even > if a particular QEMU binary does not support them. Try running > virt-install with "--cpu host-model". This should work as long as QEMU > is new enough (>= 2.10 IIRC). > It's Avocado - the virt-install command is "part" of the processing, but I can work around it. Here's the command it uses: /usr/bin/virt-install --hvm --accelerate --name 'avocado-vt-vm1' \ --memory=1024 --vcpu=2 --import --vnc --os-variant fedora25 \ --serial pty --memballoon model=virtio --disk \ path=/var/lib/avocado/data/avocado-vt/images/jeos-25-64.qcow2,bus=virtio,size=10,format=qcow2 \ --network=bridge=virbr0,model=virtio,mac=52:54:00:f9:fa:fb \ --noautoconsole Adding the --cpu host-model does allow the creation to complete. I haven't gone to check if there's any avocado-vt updates recently. And yes, I have a partially completed spectre/meltdown mitigation effort. I recall starting, but finding that not everything was ready yet and never got back to it <sigh> John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Feb 16, 2018 at 09:39:17 -0500, John Ferlan wrote: ... > Here's the command it uses: > > /usr/bin/virt-install --hvm --accelerate --name 'avocado-vt-vm1' \ > --memory=1024 --vcpu=2 --import --vnc --os-variant fedora25 \ > --serial pty --memballoon model=virtio --disk \ > path=/var/lib/avocado/data/avocado-vt/images/jeos-25-64.qcow2,bus=virtio,size=10,format=qcow2 > \ > --network=bridge=virbr0,model=virtio,mac=52:54:00:f9:fa:fb \ > --noautoconsole > > Adding the --cpu host-model does allow the creation to complete. Yeah, virt-install/virt-manager defaults for guest CPU configuration are completely wrong (and some other CPU options too). I discussed it with Pavel Hrdina. He knew about the issue and said he'd work on fixing it. Is there a bugzilla for this, Pavel? Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Feb 16, 2018 at 04:28:05PM +0100, Jiri Denemark wrote: > On Fri, Feb 16, 2018 at 09:39:17 -0500, John Ferlan wrote: > ... > > Here's the command it uses: > > > > /usr/bin/virt-install --hvm --accelerate --name 'avocado-vt-vm1' \ > > --memory=1024 --vcpu=2 --import --vnc --os-variant fedora25 \ > > --serial pty --memballoon model=virtio --disk \ > > path=/var/lib/avocado/data/avocado-vt/images/jeos-25-64.qcow2,bus=virtio,size=10,format=qcow2 > > \ > > --network=bridge=virbr0,model=virtio,mac=52:54:00:f9:fa:fb \ > > --noautoconsole > > > > Adding the --cpu host-model does allow the creation to complete. > > Yeah, virt-install/virt-manager defaults for guest CPU configuration are > completely wrong (and some other CPU options too). I discussed it with > Pavel Hrdina. He knew about the issue and said he'd work on fixing it. > Is there a bugzilla for this, Pavel? There is a bugzilla to track the CPU issue: <https://bugzilla.redhat.com/show_bug.cgi?id=1055002>. Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Feb 15, 2018 at 09:59:45PM -0500, John Ferlan wrote: > > > On 02/15/2018 11:50 AM, Daniel P. Berrangé wrote: > > Rather than expecting callers to pass a virConnectPtr into the > > virDomainDiskTranslateSourcePool() method, just acquire a connection > > to the storage driver when needed. > > > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > > --- > > src/conf/domain_conf.c | 10 +++++++--- > > src/conf/domain_conf.h | 3 +-- > > src/qemu/qemu_conf.c | 3 +-- > > src/qemu/qemu_conf.h | 3 +-- > > src/qemu/qemu_driver.c | 39 ++++++++++++++++----------------------- > > src/qemu/qemu_hotplug.c | 2 +- > > src/qemu/qemu_process.c | 4 ++-- > > tests/qemuxml2argvtest.c | 5 +++++ > > 8 files changed, 34 insertions(+), 35 deletions(-) > > > > Reviewed-by: John Ferlan <jferlan@redhat.com> > > John > > FWIW: > > I've been trying to run the avocado tests as an "extra" way to ensure > nothing has been messed up, but something (before this series) has > caused my virt-install to be less than happy <sigh> - I'm sure some of > it is self inflicted, but the error is making me wonder: > > 2018-02-16 02:07:55.517+0000: 31492: error : > qemuProcessReportLogError:1928 : internal error: qemu unexpectedly > closed the monitor: 2018-02-16T02:07:55.479523Z qemu-system-x86_64: > can't apply global Haswell-noTSX-x86_64-cpu.spec-ctrl=on: Property > '.spec-ctrl' not found Hmm, that's a problem - libvirt seems to have detected availablility of Spectre fixes (presumably you have microcode installed ?) and thus tried to use the new features, but QEMU isn't supporting those features. Smells like a libvirt bug, but also possibly out of date QEMU exposing the bug. > > I also tried running the virt-manager tests, but running from top of > tree fails with the urllib.parse failure: > > ... > File "/home/jferlan/github/virt-manager/tests/__init__.py", line 33, > in <module> > from tests import utils > File "/home/jferlan/github/virt-manager/tests/utils.py", line 21, in > <module> > import virtinst > File "/home/jferlan/github/virt-manager/virtinst/__init__.py", line > 41, in <module> > from virtinst.uri import URI > File "/home/jferlan/github/virt-manager/virtinst/uri.py", line 22, in > <module> > import urllib.parse > ImportError: No module named parse > > I narrowed it down to commit '3086c7fd' via git bisect and sent an email > to Cole. <sigh> Is this git master ? If so you need to use python3 now, not python2 Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.