[libvirt] [PATCH v2 04/10] conf: stop passing virConnectPtr into virDomainDiskTranslateSourcePool

[John Ferlan]

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 at 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 at 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