As discussed at our nova meetings, reorganize the juno specs into three directories: - proposed: things proposed which weren't approved - approved: things we approved but didn't implement - implemented: things approved and implemented The first I suspect is the most controversial. I've done this because I worry about the case where a future developer wants to pick up something dropped by a previous developer, but has trouble finding previous proposed specifications on the topic. Note that the actual proposed specs for Juno are adding in a later commit. Change-Id: Idcf55ca37a83d7098dcb7c2971240c4e8fd23dc8
6.2 KiB
VMware: Support for vSAN Datastores
https://blueprints.launchpad.net/nova/+spec/vmware-vsan-support
Currently the vmwareapi compute driver only supports deploying instances to NFS and VMFS datastores. This blueprint proposes to add support for using vSAN storage as well.
Explanation of terminology used:
The term "datastore" as referred to in the spec and the driver refers to the vSphere concept a logical storage container, a place where VM data (among other things) is kept. The purpose of this abstraction is to provide a uniform way for vSphere clients to access said VM data regardless of what hardware, I/O protocols or transport protocols are used by the underlying storage.
All vSphere datastores until recently has been broadly divided into two types, VMFS and NFS. The vmwareapi driver has been supporting the use of both since its inception, without having to distinguish between either, largely because of this datastore abstraction.
vSAN storage is a third type of datastore introduced in vSphere. It is a software-defined distributed storage that aggregates disks (magnetic for capacity, SSD for cache/performance) attached to a group of hosts into a single storage pool. That pool is once again exposed as a single datastore.
Problem description
Currently datastores with type "vsan" is ignored by compute driver entirely. One obstacle to using this type of datastore is that virtual disk data files (the "-flat.vmdk" files) are not directly addressable as datastore paths. Since both the spawn and snapshot workflow in the vmware driver addresses the data files in some way, they will have to be changed to support vSAN datastores.
Proposed change
The change is divided into two areas:
- Recognize and use datastores of a new type ("vsan").
- Update existing code involved in exporting and importing Glance images to use alternate vSphere APIs that does not address disk data files directly.
The second area of change is mainly provided by the image-transfer functionality in the oslo.vmware library1. The proposal is to update the code to use said library.
However, the only disk format that these alternate APIs support is the 'streamOptimized' format. (The streamOptimized format is a sparse, compressed, and stream-friendly version of the VMDK disk that is well suited for import/export use cases, such as the glance<->hypervisor exchanges described above). This implies that only streamOptimized disk images are deployable on vSAN. The driver will be modified to recognize Glance vmdk images tagged with the property vmware_disktype='streamOptimized' as disks of such format, and only use the alternate APIs when handling disks of this format.
Alternatives
None.
Data model impact
None
REST API impact
None
Security impact
None
Notifications impact
None
Other end user impact
None
Performance Impact
None
Other deployer impact
The compute driver will require the oslo.vmware library. (See "Dependencies" section).
There is a new configuration option under the [vmware] section, "image_transfer_timeout_secs", which configures how long an image transfer can proceed before timing out.
In order to deploy existing VMDK images to vSAN, these images will have to be converted to streamOptimized and reimported to glance.
Developer impact
Minimal. The changes related to blueprint are mostly isolated in the areas of handling a new vmdk format type and add recognition and use of an additional datastore type called "vsan".
Implementation
Assignee(s)
- Primary assignee:
-
vui
Work Items
Much of the work was done and proposed in the Icehouse cycle, but did not make the release due to time constraints. That work should should continue to be considered for this blueprint. The work is broadly decomposed into:
- use oslo.vmware image_transfer module to handle download of images
- use oslo.vmware image_transfer module to handle upload of image snapshot
- update driver to allow the use of datastores of type vSAN.
- update driver to recognized a new vmdk format (streamOptimized)
Dependencies
- https://blueprints.launchpad.net/nova/+spec/use-oslo-vmware. The oslo.vmware library provides functionality not available in the current vmware nova driver that is required by this blueprint.
- https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor. Work related to this blueprint will likely cause non-trivial changes to the patches for this blueprint since several of them involve the spawn operation.
Testing
Since Tempest in general does not support driver-specific tests, the proposal is to update the MineSweeper CI (https://wiki.openstack.org/wiki/NovaVMware/Minesweeper), to provide vCenter with vSAN storage and additional tests to verify existing Tempest tests passes when invoked against compute nodes using it.
Documentation Impact
New information in the vmware driver section of the Nova documentation will have to be added to document:
- How to configure a compute node for vSAN use.
- The virtual disk format requirement ("streamOptimized" only) when using vSAN storage.
- The new "image_transfer_timeout_secs" configuration option.
- How to obtain a streamOptimized disk from a virtual machine or vmdk disk in a non-streamOptimized format.
References
- https://github.com/openstack/oslo.vmware
- https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor
- https://wiki.openstack.org/wiki/NovaVMware/Minesweeper
To import a disk image to a vSAN datastore, oslo.vmware uses the ImportVApp vSphere API is used to import the image as a shadow virtual machine (a VM container to hold a reference to the base disk disk, and is not meant to be powered on). Likewise, to export the disk image, the library uses the ExportVM vSphere API. These APIs do not reference the virtual disk data file paths directly and are hence compatible with vSAN storage.↩︎