m (fix f12 virt features category) |
|||
| Line 20: | Line 20: | ||
=== Background === | === 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. | 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 | Datacenter operations are usually split along functional lines: the | ||
server administration team, the SAN administration team, and others | |||
administration team, and others (network, etc.) not relevant to this | (network, etc.) not relevant to this discussion. Within the server | ||
discussion. Within the server admin group, there are often sub-groups | admin group, there are often sub-groups for each OS. When a new | ||
for each OS. When a new application is deployed the SAN | application is deployed the SAN admins provision the storage and | ||
admins provision the storage and notify whichever OS team is responsible for the server to | notify whichever OS team is responsible for the server to proceed with | ||
proceed with the OS install. | 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 | There may be more or less information transmitted from the SAN admins | ||
you should be able to see them now. | 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. The LUNs are 27, 28, 29 and | |||
53." The server admin may not know what targets or hosts the new | 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 | 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 | show up new logical units of the size requested with numbers 27, 28, | ||
target on some host, and the server admin assumes | 29 and 53 on some target on some host, and the server admin assumes, | ||
usually reasonably, that these logical units are the new storage. | |||
storage | |||
While libvirt is currently capable of using SAN storage, it lacks the | While libvirt is currently capable of using SAN storage, it lacks the | ||
ability to trigger scans for new storage, create virtual host adapters | ability to trigger scans for new storage, create virtual host adapters | ||
using NPIV and | using NPIV and discover multipath devices. The OS admin team that | ||
manages the VM host must get involved to get the VM host to recognize | 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 new storage. Giving libvirt the ability to manage storage allows | ||
| Line 57: | Line 54: | ||
=== Implementation === | === Implementation === | ||
The libvirt APIs already permit storage discovery and pool creation. | The libvirt APIs already permit storage discovery and pool creation. | ||
These functions will be extended to discover and rescan storage on a | |||
per-SCSI-host basis and discover multipath devices. The node device | |||
APIs will be extended to create and destroy vitrual adapters using | |||
NPIV. | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
Revision as of 16:50, 16 July 2009
Summary
Enable VM hosts to discover new SAN storage, issue NPIV operations and do basic configuration of multipath devices.
This functionality is currently a work in progress, and this page will be updated as it is developed.
Owner
- Name: Dave Allan
- Email: dallan at redhat dot com
Current status
- Targeted release: Fedora 12
- Last updated: 2009-03-02
- Percentage of completion: 20%
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 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. The LUNs are 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 of the size requested with numbers 27, 28, 29 and 53 on some target on some host, and the server admin assumes, usually reasonably, that these logical units are the new storage.
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 discover 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 and rescan storage on a per-SCSI-host basis and discover multipath devices. The node device APIs will be extended to create and destroy vitrual adapters using 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
- SCSI storage discovery is mostly complete.
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
This functionality 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.