On 24/10/2025 12:34, Dmitriy Rabotyagov wrote:
You need to allocate empty DIMM slots upfront to enable the hotplug. In general, this is a very complex feature to do correctly and it does not really fit with a cloud model where VMs are intended to be easily replaceable.
One very obvious side-effect if it's ever implemented, is that Nova does re-schedule VM to a more suitable host during resize. As it is really a frequent occasion, that hypervisor running the VM might not have enough capacity to allocate resources. So you pretty much would need to reserve a bunch of resources for each VM, and then have a lot of allocated, but unused capacity. Which might be never claimed. So this makes kinda little to no sense in practice. At least from my perspective (and public cloud standpoint). But again, I can be wrong and there could be some ways to solve this...
well resize is a move operation and staying on the same host is disabled by default. live resize would likely be no diffent so that not really a problem it woudl need ot live migrate to a host where it could fix if not local and then do the hotplug of memroy/cpus once there and free the previous resouces. so there isint an issue with haveing to reserve the space to expand up front but its very possible that there wotn be a host aviable to inflate the vm on. live reisze to a smaller isntance is also problematic. for example even if we have 2 dimm slots both with 8G of ram and you resize form a 16 to 8G flavor we cant simply pull one of the dimslot its similar for cpu. live resize down it very likely to crash the workload so this is really only a option to add resourse in teh majority of cases. you can inflate the mem ballon to free memory but that can cause OOM issue in the guest and its undefiend how that work with numa affined memory allcoations i.e. which numa ndoe will the ballon allocate form? similarly on teh cpu side you can lye toi the gust and back its 16 vcpu by 8 vhost kernel thread i think by adjusting the current allcaoted cpus down but in realisty live resize is effectivly 1 way.
пт, 24 окт. 2025 г. в 13:25, Dmitriy Rabotyagov <noonedeadpunk@gmail.com>:
AFAIK, Virtuozzo claimed to implement this functionality in their downstream OpenStack deployment. Have no idea about details though. And they are extremely unlikely to contribute anything back...
пт, 24 окт. 2025 г. в 11:40, Sean Mooney <smooney@redhat.com>:
there is currently no one activly working on this.
so its unlikely. not impossible but unless your perfonally intending to develop this i woudl not expect it to matiariase int eh short to medium term (1-2 years)
On 24/10/2025 03:16, Nguyễn Hữu Khôi wrote: > Yep, I get it, Would we have some plans for this in the future? > > Nguyen Huu Khoi > > > On Thu, Oct 23, 2025 at 6:32 PM Sean Mooney <smooney@redhat.com> wrote: > > > On 23/10/2025 08:44, Nguyễn Hữu Khôi wrote: > > Hello, > > > > This topic looks like it will be asked many times but I am > curious why > > it won't be implemented. Does it have impacts on the system? > > |It is not generally well supported in the hypervisors. For > example, in > Libvirt to do a live resize, you have to pre-allocate the CPUs and > DIMM > slots in the CPU topology in the initial VM. You can't simply add and > remove cores as you see fit while the VM is running. That would > mean you > would have to do something like adding hw:max_cpus=64 to the initial > flavor. Then you could resize to a flavor with up to 64 cores, but > only > if the NUMA and the virtual hardware topology of the VM did not > change. > The same is true for RAM. You need to allocate empty DIMM slots > upfront > to enable the hotplug. In general, this is a very complex feature > to do > correctly and it does not really fit with a cloud model where VMs are > intended to be easily replaceable. Nova is not a virtualization > platform > where this feature is more common. Even on such virt platforms, > This is > rarely done at runtime and still has the same requirement to > pre-configure the max CPUs and memory that would be allocated. so the > short verison is its hard and it does nto really fit with the > intended > usage model of nova. it could be done but its a very non trivial ask.| > > > > > > I see that will be an useful feature. > > > > Nguyen Huu Khoi >