Il 25/04/2014 01:18, Eduardo Habkost ha scritto:
On Fri, Apr 25, 2014 at 12:57:48AM +0200, Paolo Bonzini wrote:
Il 24/04/2014 22:57, Eduardo Habkost ha scritto:
If that didn't break other use cases, I would agree.
But "-cpu host" today covers two use cases: 1) enabling everything that
can be enabled, even if it breaks migration; 2) enabling all stuff that
can be safely enabled without breaking migration.
What does it enable *now* that breaks migration?
Every single feature it enables can break it. It breaks if you upgrade
to a QEMU version with new feature words. It breaks if you upgrade to a
kernel which supports new features.
Yes, but it doesn't break it if you have the same processor, QEMU and
kernel versions; this is not the case for invtsc (at least without
improvements that aren't there yet).
A feature that doesn't let you upgrade the kernel isn't a feature I
expect users to be relying upon.
It lets you upgrade the kernel as long as you do it for all machines.
Whether this is acceptable depends on what you're using virt for.
It can be fine for "cattle" VMs that you can throw away at any time.
Though people who buy into the cattle vs. pet distinction will tell you
that you don't migrate cattle and this would make this discussion moot.
It can be fine for personal VMs (e.g. Windows VMs) that people use for
development and will likely throw away at the end of each working day.
Though for these VMs you also won't bother with migration, doing
maintenance at night is easier (and if you need "-cpu host" you're
probably doing other things such as GPU assignment that prevents migration).
So I couldn't indeed think of uses of "-cpu host" together with
migration. But if you're sure there is none, block it in QEMU. There's
no reason why this should be specific to libvirt.
Or if you plan ahead. With additional logic even invariant TSC in
principle can be made to work across migration if the host clocks are
synchronized well enough (PTP accuracy is in the 100-1000 TSC ticks
range).
Yes, it is possible in the future. But we never planned for it, so "-cpu
host" never supported migration.
If it wasn't blocked, it was supported. You can change this, but this
implies documenting it in release notes, and perhaps warning for a
couple of releases to give non-libvirt users a chance to tell us what
they're doing.
We may try to make a reliable implementation of use case (2) some day,
yes. But the choice I see right now is between trying not break a
feature that was never declared to exist, or breaking an existing
interface that is required to solve existing bugs between libvirt and
QEMU.
I'm not sure I follow, what existing interface would be broken and how?
Paolo
