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(a)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(a)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