Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Current »

A virtual server (or "virtual machine," or "VM") is a group of files and other resources residing on one or more physical hosts and managed by a virtual machine monitor control program to appear as a stand-alone physical computer. A VM, like a physical computer, runs an operating system and applications but unlike a physical computer, a VM only has access to a specific subset of the available physical resources. The VM is defined by a set of specification and configuration files and is backed by the physical resources of a host. VMs allow a single set of physical hosts to run multiple instances of an operating system with the separate VM instances preventing applications from interfering with each other. If one application crashes, it does not affect the programs running in the other VMs.

Like a physical server, a VM can be used for a number of applications, including databases, business applications, network management, email, directory services, etc. The life cycle outlined here applies to any virtual machine irrespective of its application or underlying control program.

CI Naming Convention

Host names for virtual servers are often specified by the client at the time the VM is requested. However, when this is not the case, server names should follow the form of:

      {assigned_to}-{environment}-{serviceID}nn

Where:

{assigned_to}

Identifier indicating the team, project, application, or other campus department associated with the server.

{environment}

Single-character identifier indicating the environment in which the server will be operating. See the Environment Classification Codes table below for a list of valid codes for this segment.

{serviceID}

Service identifier provided by the client using the server. This is usually something meaningful to the client to help identify the purpose of the server.

{nn}

Sequential two-digit number beginning with "00" to prevent duplication of names.

NOTE

  1. When a VM is retired, the server name must be modified in the CMDB to include a prefix of RETIRED to make it obvious in listings and searches that the server is no longer being used.
  2. For additional information on server host naming conventions used by OIT, see: OIT Host Name Guideline (EAID 19)

Environment Classification Codes

Only the following environment classification codes may be used in a server name:

CodeUsed For
PProduction
NNon-Production (AWS)
DDevelopment
QQuality Assurance testing
SStaging
TTesting

Examples

The following are examples of CI names using this standard:

  • mail-n-dev0 - The first general-purpose, non-production, development server for the MAIL service.
  • bus-s-bar0 - The first BUS application staging server for the BAR project.
  • bus-q-baz1 - The second BUS application QA server (the first ends in "0") for the BAZ project.
  • RETIRED - find-p-query1 - The second query server (the first ends in "0") for the production FIND application. This server has been retired from active use.

Typical Life Cycle

PhaseCI Activity

Phase 1: Server Requested & Approved
During this phase, a need for the server is determined and a decision is made to deploy a VM rather than a physical server. The specifications for the VM are determined, and a new VM is requested from the appropriate OIT team. This phase ends when all internal documentation is complete and a request for the new VM has been submitted and the new VM is ready to be configured.

If ServiceNow will be used to track incidents, changes, or task assignments during the initial steps then a CI will be required. Otherwise, a CI is not required until the VM is ready to be configured.

Phase 2: VM Configured & Tested
The server must be compared to the original specifications to confirm that it matches the original requirements. Any required configuration is done during this phase. This includes operating system software, application software and services, databases, network connections, user definition and security rules, and arrangements made for backups and disaster recovery. When all configuration steps are complete, a final system test is performed on the server in place to ensure it meets all client requirements. This phase ends when the server is ready to be used for its intended purpose.

Configuration Item Management Form is submitted by a member of the team supporting the VM and the new CI will be added to the CMDB by the CMDB Administration Team. The Status field should be set to Installed. Although the Status and State fields can be adjusted to indicate the actual current state of the server, the Status field is usually set to Installed throughout the configuration and testing phase.

Phase 3: VM in Service & Maintained
This phase represents the useful production life of the VM. Throughout this phase, the server will undergo periodic maintenance, upgrades, failures, and fixes. At some point, its usefulness will come to an end and plans need to be made to take it out of service. This phase ends when the VM is deactivated and is no longer being used, even for archive purposes, and is ready to be deinstalled.

Ongoing adjustments to the StatusState, and other fields in the CI record are made as needed by a member of the team supporting the VM.

Phase 5: VM Retired
When the server is no longer needed, either because it is being replaced by something newer or it no longer serves any useful function, it is retired.

The Status and State are updated by a member of the team supporting the VM to reflect the fact that it is no longer operational and has been retired. At the same time, the name of the VM in the CI is modified to include a prefix of RETIRED to make it obvious in listings and searches that it is no longer in use. Under no circumstances should a CI ever be deleted from the CMDB. Deleting a CI record will make it impossible to trace the history of the software and any activity documented by incidents and change requests.

Suggested Relationships

When mapping dependencies and relationships, the following are typical connections to other CI classes used by virtual servers:

RelationshipDependent Class 
DR provided byServer
Managed byESX Server
Mirrored toMirrors
Node ofCluster
Registered onESX Server
  • No labels