On Fri, Nov 11, 2011 at 10:38:20AM +0100, Kevin Wolf wrote:
Am 11.11.2011 01:11, schrieb Anthony Liguori:
I did a brain dump of my understanding of the various storage requirements for
live migration. I think it's accurate but I may have misunderstand some details
so I would appreciate review.
I think given sections (1) and (2), the only viable thing is to require
cache=none unless we get new interfaces to flush caches.
Yes, I think we should strongly recommend cache=none/directsync, but not
enforce it. As you said, for clustered filesystems other options should
work, so we should allow users to choose to make use of that.
WRT libvirt, we have a concept of 'tainting' for guests. We set taint
flags whenever the management application requests a config, or performs
an action that we know to be potentially dangerous. These end up as log
messages in the per-guest logfile, so when users report bugs we can see
from the log that something "bad" has been done to the guest.
At the very least, it sounds like we should make libvirt mark guests as
tainted, if they have been migrated with cache != none, so this is easily
identifiable by BZ support people.
We might also want to make a libvirt host level config option to allow
host admins forbid migration without cache=none.