On 10/17/17 17:35, Daniel P. Berrange wrote:
> On Tue, Oct 17, 2017 at 05:21:13PM +0200, Laszlo Ersek wrote:
>> On 10/17/17 16:48, Daniel P. Berrange wrote:
>>> On Mon, Oct 16, 2017 at 07:01:01PM +0200, Paolo Bonzini wrote:
>>>> On 16/10/2017 18:59, Eduardo Habkost wrote:
>>>>>> +DEF("paused", HAS_ARG, QEMU_OPTION_paused, \
>>>>>> + "-paused [state=]postconf|preconf\n"
>>>>>> + " postconf: pause QEMU after machine is
>>>>>> initialized\n"
>>>>>> + " preconf: pause QEMU before machine is
>>>>>> initialized\n",
>>>>>> + QEMU_ARCH_ALL)
>>>>> I would like to allow pausing before machine-type is selected, so
>>>>> management could run query-machines before choosing a
>>>>> machine-type. Would that need a third "-pause" mode, or will we
>>>>> be able to change "preconf" to pause before select_machine() is
>>>>> called?
>>>>>
>>>>> The same probably applies to other things initialized before
>>>>> machine_run_board_init() that could be configurable using QMP,
>>>>> including but not limited to:
>>>>> * Accelerator configuration
>>>>> * Registering global properties
>>>>> * RAM size
>>>>> * SMP/CPU configuration
>>>>
>>>> Should (or could) "-M none" be changed in a backwards-compatible way to
>>>> allow such preconfiguration? For example
>>>>
>>>> qemu -M none -monitor stdio
>>>> (qemu) machine-set-options pc,accel=kvm
>>>> (qemu) c
>>>
>>> Going down this route has pretty major implications for the way libvirt
>>> manages QEMU, and support / debugging of it. When you look at the QEMU
>>> command line libvirt uses it will be almost devoid of any useful info.
>>> So it will be more involved job to figure out just how QEMU is configured.
>>> This also means it is difficult to replicate the config that libvirt has
>>> used, outside of libvirt for sake of debugging.
>>>
>>> I also think it will have pretty significant performance implications
>>> for QEMU startup. To configure a guest via the monitor is going to
>>> require a huge number of monitor commands to be executed to replicate
>>> what we traditionally configured via ARGV. While each monitor command
>>> is not massively slow, the round-trip time of each command will quickly
>>> add up to several 100 milliseconds, perhaps even seconds in the the
>>> case of very large configs.
>>>
>>> Maybe we ultimately have no choice and this is inevitable, but I am
>>> pretty wary of going in the direction of launching bare QEMU and
>>> configuring everything via a huge number of monitor calls.
>>
>> Where's the sweet spot between
>> - configuring everything dynamically, over QMP,
>> - and invoking QEMU separately, for querying capabilities etc?
>
> The key with the way we currently invoke & query QEMU over QMP to detect
> capabilities is that this is not tied to a specific VM launch process.
> We can query capabilities and cache them until such time as we detect
> a QEMU binary change. So this never impacts on the startup performance
> of individual VMs. The caching is critical, because querying capabilities
> is actually quite time intensive already, taking many seconds to query
> capabilities on all the different target binaries we have.
(Sorry about hijacking the thread, but I can't stop asking :) )
This looks very smart -- for my own education, how does libvirtd detect
a QEMU binary change? Based on executable mtime, size, checksum? Are
perhaps the <emulator> elements of individual domains involved?
Thanks!
Laszlo
