December 10, 2015
We are happy to announce the December update of Cisco Metacloud™.
New Kernel for UCS Customers
Customers leveraging UCS boxes for their Compute resources can now upgrade to a new Kernel. This Kernel addresses the Kernel panics some customers were seeing due to certain networking conditions. It is recommended that all customers running UCS boxes upgrade to this Kernel before upgrading to Neutron. Please work with the Metacloud Operations team to schedule your upgrade.
Live Migrations via the Dashboard
Cloud Admins can now migrate instances via the Dashboard. While this functionality has been available via the CLI and API it was not available via the Dashboard. Cloud Admins can now move instances from one hypervisor to another without interrupting the VM. There are two different methods of Live Migration. True Live Migration requires that VM ephemeral disks and root disks are located on shared storage (Ceph for example). In this case only VM memory has to be copied from one hypervisor to another and can happen almost instantaneously depending on the utilization of the VM being migrated. Live Block Migration is invoked when the VMs ephemeral and root disks are located on the hypervisor itself. This requires copying both the VM memory and disks to the new hypervisor. The time required to do this depends on disk size, network throughput and VM utilization.
There are two scheduling methods users can leverage when migrating a VM. The first and preferred method is to allow the Nova Scheduler to select the target Hypervisor for the migration. This allows the Nova Scheduler to pick the target hypervisor using normal VM scheduling methods and scheduling filters. The second method is for the end user to select the target Hypervisor. Only hypervisors with sufficient resources will be displayed in the dropdown list. If a Hypervisor is chosen that violates an affinity/anti-affinity rule a warning will be displayed but Admins can choose to override the warning.
Currently instances with volumes attached that are backed by NFS are not allowed to be migrated. This is because of the risk of data corruption in the volume. In order to migrate an instance with a volume backed by NFS, that volume must first be detached, then the instance can be migrated and then the volume can be reattached.
Neutron Router Detail Page
Cloud Admins can now set the gateway of a Neutron Router and delete the Router via the Router detail panel. Previously Admins could only set the Router gateway or delete the Router via Neutron Router panel.
Default Quotas Page Has Moved
In order to better align with upstream OpenStack dashboard the default quotas panel has moved. Previously it could be found under Admin -> System Info -> Default Quotas. It can now be found under Admin -> Defaults. Some default project quotas can now be set via this panel.
virtio-scsi Disk Services and Trim Support for SolidFire backed Storage
Customers leveraging a SolidFire device can now activate virtio-scsi disk services. In order to leverage virtio-scsi disk services two properties must be set on the appropriate Glance images. These properties are
glance image-update –property hw_scsi_model=virtio-scsi –property hw_disk_bus=scsi
After these properties are set all new instances booted from images with these properties will leverage virtio-scsi disk services.
Trim on SolidFire devices is now available for all instances leveraging virtio-scsi services.
Image Caching with SolidFire Cinder Driver
The Icehouse version of the SolidFire driver has to download and copy an image on a volume every single time a volume is created from an image. At best this causes instance launches to make several minutes minimum, at worse it can cause performance impacts to all MCPs and the cloud as a whole when 100s of instances are launched from a volume at the same time due to network saturation and disk IO limitations.
When performing boot from Volume on SolidFire based devices or devices that aren’t also acting as Glance Image stores, the current process is:
- Fetch the image from Glance Store to a temp file on the Cinder Node
- Perform a qemu-img convert on that file (convert to raw)
- Transfer the contents of that file to the newly created Volume using dd
When enabled this option will use the existing Cinder clone_image method, and will create a “Template Volume” of minimum required size on the SolidFire backend. This Volume will be created with a backend SolidFire account that can be shared among OpenStack Tenants.
When a request is received we first do a number of checks before proceeding:
- Is Image/Template caching enabled
- Inspect the image-metadata and verify that the image is public, or that the tenant making the request is the owner
- Verify that the image-metadata includes the properties[‘virtual_size’] parameter
If the preconditions are met, create a minimal sized Volume with the requested image; then use SolidFire’s clone operation to create the requested bootable Volume. During the process check and make sure that the image hasn’t been updated since our cached copy was created, if it has then delete the copy that is on the system and create a new one. With image caching turned on in addition to the clone operation on SolidFire customers can now spawn much larger numbers of instances at once without impacting Metacloud services or already running instances. In testing we have observed the ability to spawn over 100 instances in less than 5 minutes when leveraging boot from volume, image caching and volume cloning.
- Improved Neutron DHCP HA
- Improved Keystone token management and monitoring
- Host aggregates panel in Dashboard now handles empty availability zones
- Delete Interface button on Network Topology panel does not work
- Excessive Delete Interface buttons on the Neutron Router detail page
- Volumes table doesn’t show all volumes after one is deleted
- Storage panel data sometimes does not load correctly
- Flavor extra specs cannot be deleted via the Dashboard
- Booting from Volume via the Dashboard results in an error
- Cannot update default project quotas
- Improved revert instance resize workflow to make more reliable
- Multiple subnet checking is too restrictive
Supported API Versions
Supported OpenStack Projects and Versions