KVM call minutes for 2013-08-06

Hi

if you find that Today minutes are better than usual, I am learning to delegate and ask people for help. Thanks to:
- mst
- eduardo
- stephan

2013-08-06
----------

What libvirt needs/miss Today?
- how to handle machine types? creating them inside qemu?
- qemu --cpu help
only shows cpus, not what features qemu will use
- qemu -cpu host
what does this exactly means? kvm removes same flags.
- Important to know if migration would work.
- Machine types sometimes disable some feature, so cpu alone is not enough.

- if kvm initialization fails, we should fall back to tcg, depending of command line options.

- migration is not the only user case
openstack choose host depending on what features the hosts have.

- not easy shortcut that creating a guest with that options and query if features are there or not.

- this information is "static", but it depends on:
* configuration files
* machine type
* command line options
* ....

- So it is complicated to get it without launching a guest with the current command line.

- Libvirt wants it because it is slow to use it, so they cache the information.

- Libvirt creates a big table of supported options

- At this point, libvirt don't export this information to its users

- Anthony would send a qmp command proposal to qemu-devel@

- -cpu host "is not supported from cross-machine migration" you need to use -cpu host to check what features the host have.

- kernel removes some features because it knows it can't be virtualised
- qemu adds some others because it knows it don't need host support
- and then lots of features in the middle

Probing for host information ("-cpu host" details):
* Needed to find out if it's possible to create or migrate a VM, or to choose an appropriate host to migrate to
* Depends on host capabilities: CPU host capabilities, kernel capabilities (kernel version), QEMU capabilities (kernel version)
* Does not depend on machine-type
* libvirt will probably want to build a table beforehand, with information about all hosts
* Note that live-migration of "-cpu host" is not supported, but we use the "-cpu host" results as a way to find out about host capabilities
* Problem: allowing it to be probed using "-machine none"
* Needs KVM to be initialized
* Solution: add KVM to be requested with fallback to TCG (does it work today?)
* libvirt should be able to create a "-cpu host" CPU object, query for its information, and destroy it
Probing for the actual results of a given machine-type + CPU model combination:
* Depends on machine-type
* MUST NOT depend on host capabilities, otherwise migration would be already broken
* Probably no need to build a large table with all machine-type/CPU-models combinations beforehand. Just querying for the information on the VM before migrating it should be enough?
* Anyway, if libvirt needs to query for all combinations beforehand, we may provide a QMP command to apply compat properties from a machine-type (suggestion by Anthony)

* pvpanic
- was added by default in 1.5, this might have been too rash:
- might change guest behaviour if guest is set to reboot on panic
- might cause slightly annoying warnings/queries from device manager
- generally somewhat inelegant/non-symmetrical, libvirt developers prefer "no magic devices"
- conclusions:
- for -M 1.6, will change QEMU don't add by default, teach libvirt to add with -device pvpanic
- separately discuss doing same for 1.5 stable branch and -M 1.5 on mailing list

* reverse execution for qemu
caturing IO is complicated
determinising and the clocks
how it relates with kemari
you don't need to wait for two weeks.
they do a fork as an snapshot instead of getting the machine to snapshot itself.
merging forks and threads: enough said.
icount changes for reverse execution will probably conflict with qemu-timer.c changes for thread-safety and AioContext timers.

Interesting, but it looks like either a feature or a driver bug.

This just moves the problem to a layer where it's harder to fix it. It will just appear to work because no one will use pvpanic, which is not a solution.

Paolo

More like the device bug. The behaviour should be to notify management without stopping the VM. Management (if present and configured for do so) stops the VM.

--
Gleb.