As the requirements for the "High Performance" VM Profile will prevent this VM from being Live migrated, this RFE is for adding this ability back to this type of VMs. Needs for this: - Orchestration for doing unpinning - migration - pinning - Some prechecks that the host CPUs are the same (as hostpassthrough is used) Maybe in case we do not have a host with the same NUMA topology, pinning won't be re-enabled until the VM is migrated back to its originating host (or a host with the same topology). This would of course have some performance impact, but might be acceptable. Ideally in these cases a Warning should be displayed, so that the administrator is aware of the possible performance loss.
Options: - require same hardware ==> This would simplify the pinning - requires "comptible" hardware ==> repinning would need to follow a logic or be a manual step. Just unpin, live migrate, and leave it unpinned. From a usability point of view, we should require the same hardware or have "multihost pinning" in RHV for "compatible" hardware. As it is also hard to identify the hosts the initial pinning is for, it maybe that multihost pinning is the best approach here. With that aproach you could use slightly different hardware, but the key-settings (CPUs, NUMA zones) need to be the same.
Hi Jarda, some questions to this feature: Is there a way of changing the pinning/vNUMA pining during the live migration in libvirt? How would you migrate a pinned VM between two hosts that are not 100% identical in libvirt?
(In reply to Martin Tessun from comment #2) > Hi Jarda, > > some questions to this feature: > > Is there a way of changing the pinning/vNUMA pining during the live > migration in libvirt? > > How would you migrate a pinned VM between two hosts that are not 100% > identical in libvirt? Yes this is possible. Either there is a migration API which accepts target domain XML which can be different to source. Or you can use post-migration hooks where you can modify the destination guest definition. More info can provide Jiri Denemark, or virt-devel. Btw. why are comments 1, 2, 3 private? ;)
now they're not:) Thanks, we would initially try not to change any pinning Regarding multi-host pinning, it's problematic from UX point of view. We basically have a configuration screen for a single host and mapping for a single host. It would be possible to filter unsuitable hosts in scheduling, that way you could see the list of compatible hosts (with similar-enough layout) in the list of available hosts for migration. If we keep the single host pinning it would only start on the original host when you shut it down (or you have to reconfigure it). But it simplifies the UX aspects a lot (basically no change is needed) and backend changes are simple. Plus the scheduling side which we need anyway, to decide which hosts are "similar enough".
I have 2 "what if" questions: 1 - what if this was part of the "resource reservation" feature? If the HPVM had the resource reservation checked, then it would look for the same NUMA availability in the cluster... this leads me to the next question.. 2 - what if from a UX standpoint (looking at Comment #4) the configuration screen included 2 hosts? the one host would be the initial host that the VM starts on, the 2nd (or additional hosts) would be hosts that have the NUMA capabilities already mapped out in preparation, even if it's just stored in a config file to be used at live migration/HA restart time.. This would likely also involve affinity rules... these are just thoughts..
allow manual migration only in 4.2.z
- tested on upstream (ovirt-release42-snapshot-4.2.6-0.3.rc3.20180826015005.git2aa33d5.el7.noarch) that High-Performance VM has two options - "manual migration only" (default) and don't allow migration. - tested migration (only allowed for the specifically chosen host) - tested that the feature works for the VM created from templateHP and from VM Pool - tested migration failure if the HP VM was running on Numa supporting host with NUMA pinning and was migrated to the host not support NUMA.