Add z/VM Support

Add z/VM support in nova tree.

z/VM provides a highly secure and scalable enterprise cloud infrastructure and an environment for efficiently running multiple diverse critical applications on IBM z Systems and IBM LinuxONE with support for more virtual servers than any other platform in a single footprint. These z/VM virtual servers can run Linux, z/OS and more. The detailed information can be found at

Problem description


The z/VM driver team has met the following requirements from the Nova core team by refer to previous virt driver integration.

  • CI running and publishing results against Nova and nova-zvm driver: Results are publicly available, as well as the configuration of the CI. Per guidance from the Nova core team, the CI runs against all Nova change sets but is not currently voting on patches as it is not an in-tree driver. The CI test logs is also publicly available.

  • External users beyond z/VM itself: Companies are actively using the z/VM driver to integrate into OpenStack clouds like SuSE; Canonical and RHEL are under discussion. Currently Openmainframe project is the major technical community and open project for mainframe enablement including openstack other open source projects.

  • Show commitment to the driver: Our first supported release was Icehouse and we continue to maintain, extend the driver with each subsequent release, following the stable branch support model. We are committed to developing the driver following the OpenStack way, with open source code, open design/development, and an open community. The z/VM driver fits the Nova compute driver design, and follows the community development direction. We also ensure that the development team is actively participating in upstream development - attending IRC meetings, mid-cycles, and summits.

Config Drive of z/VM driver

There are two ways to pass metadata from openstack (nova) to spawned server now, one is Metadata and the other is Config Drive.

For Now, z/VM driver only support Config Drive, which is, nova compute service packs an ISO9660 or vfat format generated by nova community’s configure drive build, and the server mounts the file before cloud Active engine (by default it’s cloud-init); When cloud-init startup, it checks the inputed metadata and update server’s ip, hostname and other items accordingly.

The metadata service is optional feature and expected by some features and some deployers don’t use it because of security concern, z/VM driver team will add the support of metadata service in the near future (possibily through another nova-spec).

Special active engine

Per above discussion, the cloud-init is the primary and mostly used active engine in the cloud now. The cloud-init has pre-requirements of config drive, but z/VM itself can’t simulate a iso9660 format disk in the definition of the virtual machine, because of that, z/VM driver team introduced a small Active engine which was called zvmguestconfigure.

zvmguestconfigure is part of z/VM Cloud Connector which is used by nova z/VM driver to manage z/VM. It is documented at z/VM Image build including why the active engine is needed and where it is located, also, in addition for user to create image, it provides a set of instructions on different distributions.

The basic workflow will be:

  • Nova boot an instance and metadata will be created through config drive

  • config drive (ISO9660) send from nova compute node to spawned instance

  • spawned instance already had zvmguestconfigure Active engine installed

  • during boot stage, zvmguestconfigure will get the config drive and mount it

  • cloud-init will look for config drive and handle the update

Neutron z/VM agent

z/VM nova driver need cooperate with neutron to add NIC. The agent is neutron zvm agent and currently it uses ML2 plugin.

Use Cases

  • A user should be able to deploy a glance-based image with basic networking on a system with the z/VM hypervisor. That image may be Linux (RHEL, SLES, Ubuntu, etc…).

Proposed change

The change proposed is to submit a series of patches building out enough basic function to support deployment of a glance-based virtual machine on z/VM. This subset of the driver code (and associated unit tests) would support features such as:

  • Basic VM lifecycle tasks (spawn, shutdown, reboot, snapshot, etc)

  • Instance status

  • console output

  • Flat/VLAN networking using the z/VM neutron agent

This phase of the driver is meant to get the net minimum of mandatory and choice options from the support matrix.

We see this as a long-term journey. We will continue to work to bring further functionality into the Nova tree over subsequent releases.

Some of the specific functions supported in out-of-tree driver now that would come as part of future blueprints that are not part of this one:

  • Resize

  • Cold Migrate


  1. Integrate the entire driver. That would be too unwieldy to do in one release and would require too much core reviewer time.

  2. Do not integrate the driver. As there are users of the driver, and the Nova direction is to have drivers in-tree, this is not an option.

Data model impact


REST API impact


Security impact


Notifications impact


Other end user impact


Performance Impact


Other deployer impact

Deployers who wish to use the z/VM driver will need to change the compute_driver in their conf to zvm.zVMDriver. The in-tree z/VM driver will initially have a very limited set of functionality. As noted above, they can install the nova-zvm out-of-tree driver to gain the additional functionality while the team works over multiple releases to integrate the driver.

For this first integration, there will be no required configuration from the deployer beyond setting the compute_driver type. The driver will be documented in the hypervisor support matrix (along with its capabilities in-tree).

Developer impact


Upgrade impact




Primary assignee:

jichenjc rhuang ychuang

Other contributors:

Work Items

  • Add support for basic life cycle tasks (Create, Power On/Off, Delete)

  • Add console output

  • Increase the scope of the existing z/VM CI to include the z/VM driver in-tree. Two jobs will need to be kicked off for each Nova change (one for out-of-tree, one for in-tree) during this transition period.




All code paths run through the standard Tempest tests as part of our CI. The code will also include significant unit test. This code will come from the out-of-tree nova-zvm driver. The CI infrastructure will also continue to support the automated testing of the out-of-tree nova-zvm driver.

Documentation Impact

As there is no ID team now, we will primary work on following documents and other doc that related to virt driver as well:



z/VM used to submit patches and has some discussions with nova community back to 2013/2014 time frame. At that time we are lack of CI so we followed guidelines in creating our CI and do more contributions to community.

And we had more effort in CI test and more cooperation with wider community like Open mainframe project talked above, we want to continue our effort to make z/VM accepted as in-tree plugin.


Release Name



Introduced, approved, implementation started