From Fedora Project Wiki
Line 76: Line 76:
== How To Test ==
== How To Test ==


# Use virsh to discover and configure SAN storage.
Use cases
# Use virsh to issue NPIV operations.
 
# Use virsh to configure multipath devices.
=== Discover SAN storage ===
# Assign SAN and multipath storage to VMs.
 
Provision a new logical unit on iSCSI or fibre channel storage.  Use virsh to trigger a scan for it, and confirm that it appears correctly.
 
TBD: Fill in how to configure & test this
 
=== Create a virtual HBA with NPIV ===
 
Issue an NPIV create call and confirm that the VM host has instantiated a new host adapter and that any storage zoned to it is usable.
 
TBD: Fill in how to configure & test this
 
=== Create all available multipath devices ===
 
Issue the call to create all available multipath devices and confirm that they are created and usable. 
 
TBD: Fill in how to configure & test this
 
<!--
A good Test Plan should answer these four questions:
 
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this feature? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the feature is
working like it's supposed to?
3. What are the expected results of those actions?
 
-->


== User Experience ==
== User Experience ==

Revision as of 21:27, 26 February 2009

Summary

Enable VM hosts to discover new SAN storage, issue NPIV operations and do basic configuration of multipath devices.

Owner

Current status

  • Targeted release: Fedora 11
  • Last updated: 2009-02-25
  • Percentage of completion: 5%

Detailed Description

Background

Guest virtual machines can currently use SAN storage and multipath devices, but administrators must do the storage configuration manually using separate tools from libvirt. This feature will permit administrators to discover storage and present it to virtual machines using libvirt.

Datacenter operations are usually split along functional lines: the facilities management team, the server administration team, the SAN administration team, and others (network, etc.) not relevant to this discussion. Within the server admin group, there are often sub-groups for each OS. When a new application is deployed the SAN admins provision the storage and notify whichever OS team is responsible for the server to proceed with the OS install.

There may be more or less information transmitted from the SAN admins to the server admins when the storage becomes available. The minimal message is something along the lines of, "I've provisioned the LUNs, and you should be able to see them now. I gave you LUNs 27, 28, 29 and 53." The server admin may not know what targets or hosts the new storage is accessible through, but a rescan of all host adapters will show up new logical units with numbers 27, 28, 29 and 53 on some target on some host, and the server admin assumes that's the new storage.

The functionality described here does not attempt to address the many possible failures that can result from the communication between the storage admins and the server admins described above. What we are doing is providing a framework to make the described process work within its limitations. Perhaps more importantly, we create a foundation for work that will make it possible for admins, using only libvirt's APIs, to identify storage precisely and validate that the storage intended is actually used.

While libvirt is currently capable of using SAN storage, it lacks the ability to trigger scans for new storage, create virtual host adapters using NPIV and manage multipath devices. The OS admin team that manages the VM host must get involved to get the VM host to recognize the new storage. Giving libvirt the ability to manage storage allows the OS admin team responsible for the guest OS to complete the VM build out itself.

Implementation

The libvirt APIs already permit storage discovery and pool creation. These functions will be extended to discover storage on a per-SCSI-host basis and multipath devices. The pool create and destroy functions will be extended to understand multipath and NPIV.

Benefit to Fedora

Administrators will be able to provision storage for VMs from the single set of tools that they are already using to manage the VMs.

Scope

As described above, changes are required in libvirt. Eventually the tools using libvirt will need to be updated to take advantage of the new features, but that is not within the scope of this work.

TODO

  • Implement storage discovery
  • Implement NPIV operations
  • Implement multipath configuration

Completed

  • none

How To Test

Use cases

Discover SAN storage

Provision a new logical unit on iSCSI or fibre channel storage. Use virsh to trigger a scan for it, and confirm that it appears correctly.

TBD: Fill in how to configure & test this

Create a virtual HBA with NPIV

Issue an NPIV create call and confirm that the VM host has instantiated a new host adapter and that any storage zoned to it is usable.

TBD: Fill in how to configure & test this

Create all available multipath devices

Issue the call to create all available multipath devices and confirm that they are created and usable.

TBD: Fill in how to configure & test this


User Experience

See the previous section.

Dependencies

None, outside of the implementation efforts detailed above.

Contingency Plan

This functionality is independent of all other features. If it is not ready, administrators can continue to configure storage manually.

Documentation

Release Notes

Fedora 11 adds the ability in libvirt to discover storage on a per-SCSI-host basis, issue NPIV operations and configure multipath devices. This enables administrators to discover, configure and provision storage for virtual machines without having to use multiple tools.

Comments and Discussion