Avi Kivity wrote: > > One of the uses of virtualization is to abstract the underlying > hardware, so that a VM image can run on any platform (live > migration is > an example of this use case). For that we must not let any detail of > the hardware be visible.
I doutb about the live migration cross different architecture. A VM using AMD 3DNow can't be migrated to Intel Box. Even within Intel processores, A VM using SSE2 can't be migrated to a platform w/o SSE2 support. Only if the VM is using the minimal instruction set, minimal features may be able to live migrate to other platforms. If this is the purpose, probably we can use an ancient processor model for the VM to achieve best migration capability in case hybrid processor is adopted. In that way we meet both requirement: live migration and app doesn't know it is a VM. Further more, there needs a capibility check for live migration to see if it can be migrated to a new platform. If we use host processor model, Qemu can simply check both new processor model and required one to see if migration can be done, if we use virtual processor model, say qemu processor, we have trouble: A vm using qemu processor compiled with SSE2 can't be migrated to a new platform w/o SSE2 though the capability check at migration decision make time says OK (both are qemu processoe). I think we need to revisit the policy here. Eddie ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel