6.5.1
Table Of Contents
- vSphere Storage
- Contents
- About vSphere Storage
- Updated Information
- Introduction to Storage
- Getting Started with a Traditional Storage Model
- Overview of Using ESXi with a SAN
- Using ESXi with Fibre Channel SAN
- Configuring Fibre Channel Storage
- Configuring Fibre Channel over Ethernet
- Booting ESXi from Fibre Channel SAN
- Booting ESXi with Software FCoE
- Best Practices for Fibre Channel Storage
- Using ESXi with iSCSI SAN
- Configuring iSCSI Adapters and Storage
- ESXi iSCSI SAN Requirements
- ESXi iSCSI SAN Restrictions
- Setting LUN Allocations for iSCSI
- Network Configuration and Authentication
- Set Up Independent Hardware iSCSI Adapters
- About Dependent Hardware iSCSI Adapters
- About the Software iSCSI Adapter
- Modify General Properties for iSCSI Adapters
- Setting Up iSCSI Network
- Using Jumbo Frames with iSCSI
- Configuring Discovery Addresses for iSCSI Adapters
- Configuring CHAP Parameters for iSCSI Adapters
- Configuring Advanced Parameters for iSCSI
- iSCSI Session Management
- Booting from iSCSI SAN
- Best Practices for iSCSI Storage
- Managing Storage Devices
- Storage Device Characteristics
- Understanding Storage Device Naming
- Storage Rescan Operations
- Identifying Device Connectivity Problems
- Edit Configuration File Parameters
- Enable or Disable the Locator LED on Storage Devices
- Erase Storage Devices
- Working with Flash Devices
- About VMware vSphere Flash Read Cache
- Working with Datastores
- Types of Datastores
- Understanding VMFS Datastores
- Understanding Network File System Datastores
- Creating Datastores
- Managing Duplicate VMFS Datastores
- Increasing VMFS Datastore Capacity
- Administrative Operations for Datastores
- Set Up Dynamic Disk Mirroring
- Collecting Diagnostic Information for ESXi Hosts on a Storage Device
- Checking Metadata Consistency with VOMA
- Configuring VMFS Pointer Block Cache
- Understanding Multipathing and Failover
- Raw Device Mapping
- Software-Defined Storage and Storage Policy Based Management
- About Storage Policy Based Management
- Virtual Machine Storage Policies
- Working with Virtual Machine Storage Policies
- Populating the VM Storage Policies Interface
- Default Storage Policies
- Creating and Managing VM Storage Policies
- Storage Policies and Virtual Machines
- Assign Storage Policies to Virtual Machines
- Change Storage Policy Assignment for Virtual Machine Files and Disks
- Monitor Storage Compliance for Virtual Machines
- Check Compliance for a VM Storage Policy
- Find Compatible Storage Resource for Noncompliant Virtual Machine
- Reapply Virtual Machine Storage Policy
- Using Storage Providers
- Working with Virtual Volumes
- About Virtual Volumes
- Virtual Volumes Concepts
- Virtual Volumes and Storage Protocols
- Virtual Volumes Architecture
- Virtual Volumes and VMware Certificate Authority
- Snapshots and Virtual Volumes
- Before You Enable Virtual Volumes
- Configure Virtual Volumes
- Provision Virtual Machines on Virtual Volumes Datastores
- Virtual Volumes and Replication
- Best Practices for Working with vSphere Virtual Volumes
- Filtering Virtual Machine I/O
- Storage Hardware Acceleration
- Hardware Acceleration Benefits
- Hardware Acceleration Requirements
- Hardware Acceleration Support Status
- Hardware Acceleration for Block Storage Devices
- Hardware Acceleration on NAS Devices
- Hardware Acceleration Considerations
- Thin Provisioning and Space Reclamation
- Using vmkfstools
- vmkfstools Command Syntax
- The vmkfstools Command Options
- -v Suboption
- File System Options
- Virtual Disk Options
- Supported Disk Formats
- Creating a Virtual Disk
- Initializing a Virtual Disk
- Inflating a Thin Virtual Disk
- Converting a Zeroedthick Virtual Disk to an Eagerzeroedthick Disk
- Removing Zeroed Blocks
- Deleting a Virtual Disk
- Renaming a Virtual Disk
- Cloning or Converting a Virtual Disk or RDM
- Extending a Virtual Disk
- Upgrading Virtual Disks
- Creating a Virtual Compatibility Mode Raw Device Mapping
- Creating a Physical Compatibility Mode Raw Device Mapping
- Listing Attributes of an RDM
- Displaying Virtual Disk Geometry
- Checking and Repairing Virtual Disks
- Checking Disk Chain for Consistency
- Storage Device Options
The ESXi hosts have no direct access to the virtual volumes storage. Instead, the hosts access the virtual
volumes through an intermediate point in the data path, called the protocol endpoint. The protocol
endpoints establish a data path on demand from the virtual machines to their respective virtual volumes.
The protocol endpoints serve as a gateway for direct in-band I/O between ESXi hosts and the storage
system. ESXi can use Fibre Channel, FCoE, iSCSI, and NFS protocols for in-band communication.
The virtual volumes reside inside storage containers that logically represent a pool of physical disks on
the storage system. On the vCenter Server and ESXi side, storage containers are presented as Virtual
Volumes datastores. A single storage container can export multiple storage capability sets and provide
different levels of service to different virtual volumes.
Watch the video for information about Virtual Volumes architecture.
Virtual Volumes Part 2: Architecture
(http://link.brightcove.com/services/player/bcpid2296383276001?
bctid=ref:video_vvols_part2_architecture)
Virtual Volumes and VMware Certificate Authority
vSphere includes the VMware Certificate Authority (VMCA). By default, the VMCA creates all internal
certificates used in vSphere environment. It generates certificates for newly added ESXi hosts and
storage VASA providers that manage or represent Virtual Volumes storage systems.
Communication with the VASA provider is protected by SSL certificates. These certificates can come from
the VASA provider or from the VMCA.
n
Certificates can be directly provided by the VASA provider for long-term use. They can be either self-
generated and self-signed, or derived from an external Certificate Authority.
n
Certificates can be generated by the VMCA for use by the VASA provider.
When a host or VASA provider is registered, VMCA follows these steps automatically, without
involvement from the vSphere administrator.
1 When a VASA provider is first added to the vCenter Server storage management service (SMS), it
produces a self‐signed certificate.
2 After verifying the certificate, the SMS requests a Certificate Signing Request (CSR) from the VASA
provider.
3 After receiving and validating the CSR, the SMS presents it to the VMCA on behalf of the VASA
provider, requesting a CA signed certificate.
The VMCA can be configured to function as a standalone CA, or as a subordinate to an enterprise
CA. If you set up the VMCA as a subordinate CA, the VMCA signs the CSR with the full chain.
4 The signed certificate with the root certificate is passed to the VASA provider. The VASA provider can
authenticate all future secure connections originating from the SMS on vCenter Server and on ESXi
hosts.
vSphere Storage
VMware, Inc. 275