Using Scriptable vMedia with UCS Manager

Document created by jesilber on Aug 21, 2014
Version 1Show Document
  • View in full screen mode

Introduction

Until recently, mapping and using external media within UCS was a manual process that typically required launching the Java-based KVM and mapping an external ISO image file as a CD. With the release of UCS Manager version 2.2(2c) and above, the new “vMedia” features allow for programmatic mapping/unmapping of external image files.

 

Requirements

Taking advantage of vMedia features requires a minimum version of UCSM 2.2(2c).  In addition, the BIOS and CIMC versions of any target hardware must also be upgraded to their corresponding 2.2(2c) images. (You cannot rely on Host Firmware Packages alone, which may result in config warnings/errors).   vMedia can also be used with C-series standalone servers running version 1.5 or greater, documented here.

 

Use Cases

vMedia allows for an external image file to be dynamically (or programmatically) mapped to the server’s CIMC (a.k.a. baseboard controller or BMC).   If a vMedia file is mapped as a CDD, then the image file presents itself as a CDROM image.  Below are some of the common use cases for using scriptable/programmable vMedia:

  • OS provisioning without requiring a PXE or network installation server
  • Updating device drivers on one or more servers
  • Creating or updating antivirus definitions to one or more servers

 

Relationships

vMedia policies are bound to Service Profiles (SPs).   Any given SP can have only one vMedia policy active at any given time.   vMedia can be referenced as a device in a Boot Policy, from which a server should attempt to boot.

 

vMedia policies include one or more vMedia Mounts, which are used to reference the source image file to be mapped, along with the protocol used for accessing the file.   In most cases, there will be one vMedia Mount per vMedia Policy.

 

Referencing within a Boot Policy is not the only way to use vMedia.   A vMedia Policy can be bound to a SP (initially or dynamically), without being referenced in a Boot Policy.   In this case, adding a vMedia Policy to an active SP would correspond to inserting a CD into a running server.

 

Changing the vMedia Policy for a SP does not cause an SP reconfiguration, reboot or service interruption.   vMedia Policies can be changed as easily as changing a CD in a server.

 

 

Create vMedia Policy

The vMedia Policy itself will typically correspond to the name of the image file to be mapped. Examples:   “CentOS6.4”, “Window-7-Enterprise”, “C-Series-drivers-1.5.7a”.   The main body of the vMedia Policy will be the vMedia Mount that is created, as below:

create-vmedia-mount.jpg

 

Take note that the “Create vMedia Policy” window in the GUI window may be undersized and need to be enlarged before the green ‘+’ action item is visible to create the vMedia Mount.

When specifying access via CIFS, be sure to use forward slashes in path, rather than Windows ‘\’ backslash characters. (e.g.  "/isos/Windows/W2012R2.iso")

 

Protocols

vMedia supports 4 network access protocols :  NFS, CIFS, HTTP and HTTPS.    Depending on the source file server, credentials may be required to access the remote file.

 

Naming Conventions

The easiest naming convention would be for the vMedia Policy to easily reflect the name of the image being mapped or mounted, as described earlier.   Examples include:   “CentOS6.4”, “Window-7-Enterprise”, “C-Series-drivers-1.5.7a”.    For simplicity, the name of the vMedia Mounts could assume the same name as the vMedia Policy.   Optionally, the vMedia Mount name could reflect either the source file server and/or access method.   Examples: “ESX5.5”, “W2012-FAS03”, “CentOS6.4-WEB04-HTTP”

 

Using vMedia in Boot Policies

vMedia can be used within a Boot Policy as shown below.

vmedia-boot-policy.jpg

 

There are two scenarios to consider, with respect to mounted vMedia boot order:

  1. 1) In a typical boot/install scenario on an uninitialized disk, having the disk (local, iSCSI or SAN) precede mounted vMedia in the boot order would result in a “first-time-only” use of the mounted vMedia.  Once the OS is installed on the disk, the vMedia mount would not be used.
  2. 2) For “rescue-mode” scenarios, then the vMedia mount would precede the disk, allowing boot from vMedia if the vMedia policy is active.   This would allow for recovery or rescue mode of a damaged boot disk.

 

Verify vMedia Mounts

Successful vMedia mounting can be verified through the GUI via

Equipment->Server->Inventory->CIMC as shown below:

vmedia-verify.jpg

 

 

OS Device Presentation.

On most Linux OS’s, the vMedia drive is presented as “/dev/cdrom1” or “/dev/dvd1”.  Devices that are mapped via the virtual KVM are presented as “/dev/cdrom” or “/dev/dvd”.

 

PowerTool Examples: Mapping and Verification

The true power in vMedia comes from its ability to be configured programmatically.  Below are some sample PowerTool commands that can be used in managing vMedia.

 

“What are the available vMedia Policy Names?”

Get-UcsVmediaPolicy | Select Name, Dn | Ft -auto

 

Name           Dn

----           --

CentOS6.4-cifs org-root/mnt-cfg-policy-CentOS6.4-cifs

CentOS6.4-nfs  org-root/mnt-cfg-policy-CentOS6.4-nfs

RedHat-5.6-NFS org-root/mnt-cfg-policy-RedHat-5.6-NFS

Win7 org-root/mnt-cfg-policy-Win7

 

“Which vMedia Mappings are available?”

Get-UcsVmediaMountEntry | Select MappingName, ImageFilename | Ft -auto

 

MappingName    ImageFileName

-----------    -------------

CentOS6.4-CIFS CentOS-6.4-x86_64-minimal.iso

CentOS6.4-nfs  CentOS-6.4-x86_64-minimal.iso

RedHat-5.6-NFS RHEL5.6-Server-20110106.0-x86_64-DVD.iso

Win7-NFS en_windows_7_professional_x86_dvd_x15-65804.iso

 

Get-UcsVmediaMountEntry | Select MappingName, Dn | Ft -auto

 

MappingName    Dn

-----------    --

CentOS6.4-CIFS org-root/mnt-cfg-policy-CentOS6.4-cifs/cfg-mnt-entry-CentOS6.4-CIFS

CentOS6.4-nfs org-root/mnt-cfg-policy-CentOS6.4-nfs/cfg-mnt-entry-CentOS6.4-nfs

RedHat-5.6-NFS org-root/mnt-cfg-policy-RedHat-5.6-NFS/cfg-mnt-entry-RedHat-5.6-NFS

Win7-NFS org-root/mnt-cfg-policy-Win7/cfg-mnt-entry-Win7-NFS

 

 

Note that for the above example, “Win7” is the vMedia Policy name, and “Win7-NFS” is a corresponding vMedia Mapping.

 

“How to Configure or Change a vMedia Policy for a Service Profile?”


Get-UcsServiceProfile –Name win7-1 | Set-UcsServiceProfile –VmediaPolicyName Win7 –force

 

“How to Verify a Successful vMedia Mount?”

$sp = Get-UcsServiceProfile –Name win7-1

Get-UcsBlade -dn $sp.PnDn | Get-UcsMgmtController -LimitScope | \

       Get-UcsCimcvmediaActualMountlist | Get-UcsCimcvmediaActualMountEntry

 

DeviceType      : cdd

EncPwd          :

ErrorType       : none

ImageFileName   : en_windows_7_professional_x86_dvd_x15-65804.iso

ImagePath       : /vol/isos/Windows/

MappingName     : Win7-NFS

MountProtocol   : nfs

OperMountStatus : mounted

Password        :

PwdSet          : no

RemoteHost      :

RemoteIpAddress : 172.22.250.21

RemotePort      : 2049

UserId          :

VirtualDiskId   : 1

Dn              : sys/chassis-2/blade-8/mgmt/actual-mount-list/actual-mount-entry-1

Rn              : actual-mount-entry-1

Status          :

XtraProperty    : {}

Ucs             : SJC18-L10-UCS1

 

[…]

 

“How to Unset or Unconfigure a vMedia Policy for a Service Profile?”


Get-UcsServiceProfile –Name win7-1 | Set-UcsServiceProfile –VmediaPolicyName “” –force

 

Best Practice for OS Installation

vMedia (like the virtual KVM) runs over the out-of-band (OOO) management interface, whose speed is 1Gb/sec. Therefore a best practice for Linux OS provisioning, if possible, would involve booting up a "minimal OS image" over the OOO interface, followed by network-based package installations, using utilities such as “yum” or “apt” to complete the installation over the 10Gb interfaces.

Attachments

    Outcomes