We have tried host-model – however virsh capabilities on the newer servers doesn’t even pick up the correct cpu map xml definition – the actual CPU is a AMD EPYC 7763 (codename Milan) and libvirt thinks it’s a ‘Rome’ cpu – a whole generation earlier !!!
Gary Dixon Senior Technical Consultant T: +44 161 537 4990 E: v...@quadris-support.com W: www.quadris.co.uk The information contained in this e-mail from Quadris may be confidential and privileged for the private use of the named recipient. The contents of this e-mail may not necessarily represent the official views of Quadris. If you have received this information in error you must not copy, distribute or take any action or reliance on its contents. Please destroy any hard copies and delete this message. From: Granwille Strauss <granwi...@namhost.com.INVALID> Sent: Tuesday, May 16, 2023 3:51 PM To: users@cloudstack.apache.org Cc: gary.di...@quadris.co.uk.INVALID Subject: Re: preventing VM Live migration between Pods Hi Gary I am still fairly new to ACS myself, but as far as I can recall, using the 'host-passthrough' option is prone to cause problems during migrations, this is also mentioned in the documentation: https://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kvm.html?highlight=host-passthrough#configure-cpu-model-for-kvm-guest-optional I suggest changing to 'host-model' instead: host-passthrough may lead to migration failure,if you have this problem, you should use host-model or custom. guest.cpu.features will force cpu features as a required policy so make sure to put only those features that are provided by the host CPU. As your kvm cluster needs to be made up of homogenous nodes anyway (see System Requirements), it might make most sense to use guest.cpu.mode=host-model or guest.cpu.mode=host-passthrough On 5/16/23 15:13, Gary Dixon wrote: Hi everyone Other than disabling a Pod – is there a way to prevent live migration of VM’s between Pods in ACS ? We are on version 4.15.2 with Ubuntu 20.04 KVM hosts. Each Pod contains a single cluster of Homogenous hosts – however there are only slight differences between the CPU’s on the physical hosts in each Cluster. We have the guest.cpu.mode set to host-passthrough but have noticed serious issues when a VM is live migrated between specific Pods (usually if a VM is started on a cluster with the slightly better CPU’s and then live migrated to an older Pod) We have tried setting the guest.cpu.mode to host-passthrough with specific CPU features using the “guest.cpu.features=” and then setting all of the host’s CPU flags shown from the output of the lscpu command in a space separated list as instructed from ACS documentation – but we then are unable to even start a VM – insufficient resources error, - if we remove the guest.cpu.features from the agent.properties – then we can start a VM again. It would be good if we had an option or a setting to just not allow live migration of VM’s between pods and therefore can only perform a ‘cold’ migration if we wish to move a VM to another Pod. Any thoughts on this ? BR Gary Gary Dixon Senior Technical Consultant T: +44 161 537 4990 E: v<tel:+44%207989717661>ms@quadris‑support.com W: www.quadris.co.uk<http://www.quadris.co.uk> [cid:image208890.png@3D7DB5EF.08AC05B1] The information contained in this e-mail from Quadris may be confidential and privileged for the private use of the named recipient. The contents of this e-mail may not necessarily represent the official views of Quadris. If you have received this information in error you must not copy, distribute or take any action or reliance on its contents. Please destroy any hard copies and delete this message. -- Regards / Groete [https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/logo/621b3fa39fb210001f975298/cd2904ba-304d-4a49-bf33-cbe9ac76d929_248x-.png]<https://www.namhost.com/> Granwille Strauss // Senior Systems Admin e: granwi...@namhost.com<mailto:granwi...@namhost.com> m: +264 81 323 1260<tel:+264813231260> w: www.namhost.com<https://www.namhost.com/> [https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/social_icon_01/621b3fa39fb210001f975298/9151954b-b298-41aa-89c8-1d68af075373_48x48.png]<https://www.facebook.com/namhost>[https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/social_icon_02/621b3fa39fb210001f975298/85a9dc7c-7bd1-4958-85a9-e6a25baeb028_48x48.png]<https://twitter.com/namhost>[https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/social_icon_03/621b3fa39fb210001f975298/c1c5386c-914c-43cf-9d37-5b4aa8e317ab_48x48.png]<https://www.instagram.com/namhostinternetservices/>[https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/social_icon_04/621b3fa39fb210001f975298/3aaa7968-130e-48ec-821d-559a332cce47_48x48.png]<https://www.linkedin.com/company/namhos>[https://www.adsigner.com/v1/s/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/social_icon_05/621b3fa39fb210001f975298/3a8c09e6-588f-43a8-acfd-be4423fd3fb6_48x48.png]<https://www.youtube.com/channel/UCTd5v-kVPaic_dguGur15AA> [https://www.adsigner.com/v1/i/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/banner/940x300]<https://www.adsigner.com/v1/l/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/banner> Namhost Internet Services (Pty) Ltd, 24 Black Eagle Rd, Hermanus, 7210, RSA The content of this message is confidential. If you have received it by mistake, please inform us by email reply and then delete the message. It is forbidden to copy, forward, or in any way reveal the contents of this message to anyone without our explicit consent. The integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender will not be held liable for any damage caused by the message. For our full privacy policy and disclaimers, please go to https://www.namhost.com/privacy-policy <https://www.adsigner.com/v1/c/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818>
