[libvirt] RFC: turn cpu 'host-model' into 'custom' for active config on domain start

Hi, everyone. Cpu mode 'host-model' is not convinient for migration in current form. Consider migration from less capable host to more capable one - it is possible. But then migration backwards is impossible despite the fact that qemu process on destination is running with the same model and features as on source because migration does not update 'host-model' cpu upon migration on destination. The problem is that on migrating back instead of taking current cpu config 'host-model' is expanded again and gain extra features of destination and migration failed by source (new destination) side. What if we change cpu for active config from 'host-model' into 'custom' in the starting process? Then this issue will be fixed. It is quite reasonable from my POV - 'host-model' is effectively about taking active domain cpu from host on start, after that active domain cpu is on its own. Persistent config stays 'host-model' so migrating of active domain and restarting it gains extra features of new host as before. Nikolay

On 06/01/2016 07:23 AM, Nikolay Shirokovskiy wrote:
Hi, everyone.
Cpu mode 'host-model' is not convinient for migration in current form. Consider migration from less capable host to more capable one - it is possible. But then migration backwards is impossible despite the fact that qemu process on destination is running with the same model and features as on source because migration does not update 'host-model' cpu upon migration on destination. The problem is that on migrating back instead of taking current cpu config 'host-model' is expanded again and gain extra features of destination and migration failed by source (new destination) side.
What if we change cpu for active config from 'host-model' into 'custom' in the starting process? Then this issue will be fixed. It is quite reasonable from my POV - 'host-model' is effectively about taking active domain cpu from host on start, after that active domain cpu is on its own. Persistent config stays 'host-model' so migrating of active domain and restarting it gains extra features of new host as before.
FWIW I filed a similar bug about this a while back: https://bugzilla.redhat.com/show_bug.cgi?id=1054935 - Cole

On Wed, Jun 01, 2016 at 14:23:54 +0300, Nikolay Shirokovskiy wrote:
Hi, everyone.
Cpu mode 'host-model' is not convinient for migration in current form. Consider migration from less capable host to more capable one - it is possible. But then migration backwards is impossible despite the fact that qemu process on destination is running with the same model and features as on source because migration does not update 'host-model' cpu upon migration on destination. The problem is that on migrating back instead of taking current cpu config 'host-model' is expanded again and gain extra features of destination and migration failed by source (new destination) side.
What if we change cpu for active config from 'host-model' into 'custom' in the starting process? Then this issue will be fixed. It is quite reasonable from my POV - 'host-model' is effectively about taking active domain cpu from host on start, after that active domain cpu is on its own. Persistent config stays 'host-model' so migrating of active domain and restarting it gains extra features of new host as before.
Yeah, your thoughts go in the right direction, although it's not enough. We also need to start creating better CPU specifications for host-model and we need to start checking QEMU gives us what we asked for. For all these reasons host-model is currently completely broken, although it usually just works (until you start looking closer at it) :-) Anyway, I'm working on all these (and other) issues with our CPU configuration code and you can expect patches coming to libvirt-list this month. Jirka
participants (3)
-
Cole Robinson
-
Jiri Denemark
-
Nikolay Shirokovskiy