Home > Blogs > OpenStack Blog for VMware


Best Practice Recommendations for Virtual Machine Live Resize

As computing demands increase, server resources must “grow” or “scale” to meet those requirements.   There are two basic ways to scale computing resources. The first is to add more VMs or “horizontally scale.” Say a web front end is using 90% of the allocated computing capacity. If traffic to the site increases, the current VM may not have enough CPU, memory, or disk available to keep up.  The site administrator could deploy an additional VM to support the growth in the workload.

 

 

 

 

 

 

 

Not all applications scale horizontally.  NFV workloads such as virtual routers or gateways may need to “vertically scale”.  For example, a virtual machine with 2 vCPU / 4 G memory may need to double it’s vCPU and memory rather than adding a second virtual machine.  While the OpenStack ecosystem offers many tools for horizontal scaling (Heat, Terraform, etc.), options for scaling up are much more limited.  The Nova project has a long-pending proposal for live resize (Hot Plug).  Unfortunately, this feature still hasn’t been implemented.  Without live-resize, to increase Memory/CPU/Disk of an instance, OpenStack must first power down the VM, migrate to a VM flavor that offers more CPU/Memory/Disk, finally power up the VM.   VM power down impacts SLA and can trigger cascading failure for NFV based workloads (route convergence, loops, etc.)

By leveraging the existing OpenStack resize API and recommendations introduced in the upstream live-resize specification, VMware Integrated OpenStack (VIO) 4.0 offers the ability to resize any machine, as long as the GuestOS supports it, without the need to power down the system. OpenStack users would issue the standard OpenStack resize request.  The VMDK driver examines the CPU/memory/disk changes specified by the flavor, and the setting of the virtual machine to determine whether the operation can be performed. If the guest OS supports live-resize, resources will be added without power down.  If guest OS cannot support live-resize, then traditional Nova instance resize operation takes place (which powers off the instance).

Best Practice Recommendations:

When implementing live-resize in your environment, be sure to follow the following recommendations:

  1. Cloud Admins or Application owners would need to indicate the GuestOS can handle live resize for a specific resource using image metadata “os_live_resize= <resource>.”  List of guest OS that supports hot plug / live-resize can be found here.  Available resource options are disk, memory or vCPU.   You can live-resize the VM based on any combination of the resource types.
    • Add CPU resources to the virtual machine
    • Add memory resource to the virtual machine.
    • Increase virtual disk size of the virtual machine
    • Add CPU and Memory, CPU and Disk, or Memory and Disk
    • Increase CPU, Memory, and Disk
    • Hot removal of CPU/Memory not supported
  2. If a resized VM exceeds the capacity of a host, VMware DRS can move the VM to another host within the cluster where resources are available.  DRS is simple to configure and extremely powerful.  My colleague Mathew Mayer wrote an excellent blog on Load balancing vSphere Clusters with DRS, be sure to take a look.
  3. Image Metadata updates for disk resize:
    • Linked clone must set to false.  This is because vCenter cannot live resize linked cloned disks
    • Disk adapter must be Non-IDE.  This is because IDE disks do not support hot-swap/add.

See diagram below:

 

 

 

 

 

 

 

 

 

 

4). VMware supports memory resize of 4G and above.  Resize below 4G should work in most cases, but not officially supported by VMware.

Live-resize Example Workflow:

Step 1). Upload image:

openstack image create –disk-format vmdk –container-format ova –property vmware_ostype=”ubuntu64Guest”  –property os_live_resize=vcpu,memory,disk –-property img_linked_clone=false –file ./xenial-server-cloudimg-amd64.ova <some name>

Step 2). Disable linked clone (if using default VIO 4.0 bundled in 16.0.4 cloud image):

openstack image set –property img_linked_clone=false <some name>

Step 3). Boot a VM:

openstack server create –flavor m1.medium –image <some name>  –nic net-id=net-uuid resize_vm

Step 4). Resize to the next flavor:

openstack server resize –flavor m1.large <resize_VM>

Step 5). Confirm resize:

openstack server resize –confirm <server>

Step 6). SSH to the VM and run the scripts below to bring the new resources online in the guest OS.

  • Memory online

“for i in `grep offline /sys/devices/system/memory/*/state | awk -F / ‘{print $6}’ | awk -F y ‘{print $2}’`; do echo “bring memory$i online”; echo online >/sys/devices/system/memory/memory$i/state; done”

  • CPU online:

https://communities.vmware.com/docs/DOC-10493

Simplify your NFV workloads by levering industry’s most stable and battle-tested OpenStack distribution.  Instead of re-architect your virtual network and security to enable horizontal scaling, live-resize it!  It’s simple and hitless.   Download 60-day evaluation now and get started, or try out VIO 4.0 based VMware Integrated OpenStack Hands-on Lab, no installation required.

This entry was posted in OpenStack on VMware, VMware Integrated OpenStack on by .

About Xiao Gao

Xiao Hu Gao is the Senior Technical Marketing Manager for OpenStack at VMware. He enjoys speaking to customers and partners about the benefits of using OpenStack with VMware technologies. Xiao has a background in DevOps, Data Center Design, and Software Defined Networking. Xiao holds CCIE certification #3000 and have filed several patents in the areas of Security and Cloud.

Leave a Reply

Your email address will not be published. Required fields are marked *

*