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@xxxxxxxxxx> > > --- > > 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@xxxxxxxxxx> > > 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
