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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
