Brand Claim Brand Claim
by Kurt Garloff

Relocating VMs from one pool to another in OTC

Scope

When you need to scale vertically, i.e. change the available vCPUs or RAM assigned to a VM in OTC, you can use the resize (change specifications) feature and change the flavor of an existing VM. You can do this via the web interface or the API -- when you then restart the VM, it will come up with the new flavor type.

In an ideal world, you never need this. In best case, you can scale horizontally. In the worst case, you need to ask your automation to deploy freshly into a new flavor. However, as the world is not ideal, resize is still very useful.

This feature is limited in scope. You can only do a resize within a resource pool. That means that you can change types within the s1,c1,c2,m1 pool, or within h1 or within s2, but you can not convert a VM of s1 flavor to one of s2 flavor. It's also not possible to use the resize feature to move from a shared pool to a dedicated host.

Nevertheless, there are ways to do these migrations by detaching the disk(s) and boot a new VM using the existing disks -- so the data and OS config remain intact. It's also possible to create an image and then boot from the private image, though the disk reassignment is much faster.

The VMs will be technically new VMs -- they have a new UUID and get a new SSH host key injected and will (without extra effort) have a different IP address. But the disks of the old VM get reused.

Prequisites

You have a Linux machine with the OpenStack client tools and otc-tools (otc.sh) installed and you have credentials configured in your environment (e.g. via sourcing ~/.ostackrc) that allow you to talk to the OTC OpenStack API.

If you don't have this available, create yourself a jumphost (smallest machine type s2.medium or computev1-1 will be perfectly sufficient for this) and create a VM with one of our _latest public images (openSUSE42_JeOS, SLES12SP3, CentOS7, ...), give it a public IP address and a security group that allows ssh. Connect to it via ssh (use putty if you have to use Windows) and fill in OS_USER_DOMAIN_NAME, OS_USERNAME and OS_PASSWORD into the ~/.ostackrc and source it. nova list or otc.sh vm list will now work.

It is very convenient to use a screen session in Linux, so you can have multiple windows. Use the mouse to do cut'n'paste for UUIDs, or create scripts that automate the relocation.

Steps

  1. Stop the VM you want to migrate with nova stop VMID. Wait until it's stopped. (You can check with nova show VMID.) Remember the VM properties in case you want to use same properties (security groups, SSH keys etc.)
  2. Identify the attached disks with nova show VMID and detach them with nova volume-detach VMID VOLID.
  3. Wait until the disks are shown as available with cinder show VOLID. You can now delete the old VM IF you want. (It can't be booted anymore anyway, since it has no root disk any more. Use nova delete VMID to do this.)
  4. Create new VMs in the same availability zone by using a command like nova boot --flavor FLAVOR --boot-volume VOLID --key-name SSHKEY --availability-zone AZ --security-groups SECGROUP --nic net-id=NETID VMNAME You need to replace the capitalized words with real parameters. Get values using the normal OpenStack list commands, i.e. nova flavor-list, nova keypair-list, otc.sh vm az-list, neutron security-group-list, neutron net-list.

Options and hints:

  • You can add additional volumes with --block-device device=sdX,id=VOLID,source=volume,dest=volume, though you can also always attach volumes after creating a new VM. (Replace X with the right letter to match the old mapping and VOLID with the volume ID.)
  • You can place the VM on a dedicated host of yours by using --hint tenancy=dedicated --hint dedicated_host_id=DEHID. You can query your dedicated hosts with otc.sh deh list.
  • You can manually create a port (with an IP address of your desire) using neutron port-create --fixed-ip subnet_id=SUBNET,ip_address=IP_ADDR NETID and can use --nic port-id=PORTID to pass it to nova if you want control IP assignment. This way you can also add custom dhcp options etc.
  • Use nova help boot to see more options.
  • Instead of nova boot, you can of course use openstack server create or otc.sh vm create. Parameter syntax is a bit different then.
  • If EIPs should be maintained, they should be disassociated before VM deletion, so they can be reassociated with the new VMs.
  • If you have tags or meta-data, you can recreate it with otc.sh vm update --tags and nova meta respectively. Note that old VMs generated by otc.sh and the GUI carried a standard tag with the value of the VPC ID. (This is no longer the case.)
  • The procedure described in this document also works when you migrate machines from Xen flavors to KVM flavors. However, there is one caveat: You need to make sure that all drivers are included, and that you access the disks by disk-label or by UUID, so they are still correctly found by the bootloader and the mount procedure (fstab). This is not a problem for our public Linux images (since summer 2017), as they all include both Xen/KVM drivers and use mount-by-label. But for private images (not based on our public images) and for Windows images this needs to be checked.

DISCLAIMER

Don't do this if you are new to OpenStack and it's CLI tools. You can lose information that you need if you are not careful and understand the process well. Neither the author nor his employer will take any responsibility for this.