On 11/29/2010 06:23 PM, Stefan Hajnoczi wrote:
On Mon, Nov 29, 2010 at 3:00 PM, Yoshiaki Tamura
<tamura.yoshiaki@xxxxxxxxxxxxx> wrote:
2010/11/29 Paul Brook<paul@xxxxxxxxxxxxxxxx>:
If devices incorrectly claim support for live migration, then that should
also be fixed, either by removing the broken code or by making it work.
I totally agree with you.
AFAICT your current proposal is just feeding back the results of some
fairly specific QA testing. I'd rather not get into that game. The
correct response in the context of upstream development is to file a bug
and/or fix the code. We already have config files that allow third party
packagers to remove devices they don't want to support.
Sorry, I didn't get what you're trying to tell me. My plan would
be to initially start from a subset of devices, and gradually
grow the number of devices that Kemari works with. While this
process, it'll include what you said above, file a but and/or fix
the code. Am I missing what you're saying?
My point is that the whitelist shouldn't exist at all. Devices either support
migration or they don't. Having some sort of separate whitelist is the wrong
way to determine which devices support migration.
Alright!
Then if a user encounters a problem with Kemari, we'll fix Kemari
or the devices or both. Correct?
Is this a fair summary: any device that supports live migration workw
under Kemari?
It might be fair summary but practically we barely have live migration
working w/o Kemari. In addition, last I checked Kemari needs additional
hooks and it will be too hard to keep that out of tree until all devices
get it.
(If such a device does not work under Kemari then this is a bug that
needs to be fixed in live migration, Kemari, or the device.)
Stefan
--
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
