KVM call minutes for 2013-08-06

[Juan Quintela <quintela@redhat.com>]

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.