Cloned from launchpad blueprint https://blueprints.launchpad.net/nova/+spec/hot-resize. Description: 'Cold-resize' had been implemented previously. But instance needs to be rebooted during the period. So this plan aims to add 'hot-resize'(or 'live-resize'?) function into Nova. This is useful and convenient for users. Specification URL (additional information): None
A strategic customer has requested that this bug be re-opened. It was "closed upstream", however it looks like upstream abandoned it last year (https://review.openstack.org/#/c/95054/). Could this be-reopened?
The customer's use case is to scale an instance running on KVM without downtime in the following dimensions: - An instance with N CPUs could have N+2 CPUs - An instance with N GB of RAM could have N*2 GB of RAM - An instance with / booted on a Cinder Volume with N GB of disk could have an N*2 GB of disk (the instance would then need to grow the FS into that space)
(In reply to John Fulton from comment #6) > The customer's use case is to scale an instance running on KVM without > downtime in the following dimensions: > > - An instance with N CPUs could have N+2 CPUs > - An instance with N GB of RAM could have N*2 GB of RAM Ok, so they do not require scale *down*? > - An instance with / booted on a Cinder Volume with N GB of disk could have > an N*2 GB of disk (the instance would then need to grow the FS into that > space) This is likely to be treated separately, it's outside the scope of the hot resize proposal as cold resize doesn't address this dimension either (extension of a volume is a cinder function, not nova).
*** Bug 1289173 has been marked as a duplicate of this bug. ***
*** Bug 1379539 has been marked as a duplicate of this bug. ***
[A quick update from my brief research on this.] This is the renewed, but not-yet-merged, specification: https://review.openstack.org/#/c/95054/ -- Adds spec for instance live resize I just learnt from upstream that at the Newton (OSP 10) mid-cycle meet-up [I wasn't there] of Nova contributors held some months ago, it was roughly agreed that it'd be nice to support (with some caveats) this in Ocata release. The caveats being, quoting verbatim from the upstream meeting notes: "We, we agreed it was something we should support (in Ocata) but it's dependent on the capabilities/policy exposure in the API. We also said that it would be restricted to live resize on the same host and with existing flavors, i.e. you can't pass random values like CPU/RAM/Disk for the resize - it has to be a flavor. And you can't resize down." --- Couple of quick notes after going through existing review comments: - Live resize can get quickly complicated escpecially with more advanced features like NUMA / Huge Pages / CPU pinning / PCI devices hotplug, etc. Thus, for the initial iteration, it is likely that guests configured with the above mentioned advanced features might not be supported. - Not to mention error handling scenarios in case of a live resize failure. And to determine whether a "rollback" (not even sure if 'atomicity' is possible at this stage), which means resizing the VM _down_, which is is not considered a design goal as of now. It involves working out how each hypervisor behaves. - Given various moving factors, it is likely that the live resize for initial iteration could even mean narrowing down the scope to a one resource type (CPU, RAM, storage, PCI, etc ) at a time, to ensure the operation is safe. As noted earlier, this is all not set in stone, but just pointing out the scope of complexity. The renewed spec for Ocata (OSP 11) is still in-progress, the design and related details still being worked out, while keeping in mind we ought to consider the behavior of other hypervisor drivers like Xen, VMWare, Hyper-V, along with KVM. Please adjust customer expectations accordingly.
Specification was not approved for Ocata upstream, moving to Pike.
Need to review whether this is achievable for Pike, it's been moving along slowly upstream just want to establish exactly how many patches are outstanding and what will be required from a Libvirt driver enablement perspective.
*** Bug 1302713 has been marked as a duplicate of this bug. ***
The upstream specification is at this point considered abandoned. Given the amount of work required on the external APIs, RPC changes, and potentially changes to all compute drivers we do not have capacity to pursue this in the foreseeable future.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days