A virtual server (commonly referred to as a "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 virtual machine, 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 virtual machine 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. ApplicationThis life cycle is typical for the following asset classes: - Virtual Machines used as servers of all classes
Typical Life Cycle for Virtual Servers Image Removed
Phase 1: VM 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. Phase 2: VM Configured & Tested
Once configured, the VM must be compared to the original specifications to confirm that it matches the original requirements. Any required configuration is done during this phase including 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 system test is performed on the VM to ensure it meets all client requirements. This phase ends when the VM is ready to be deployed into production. Phase 3: VM in Service & Maintained
This phase represents the useful production life of the VM. Throughout this phase, the VM will undergo periodic maintenance, upgrades, failures and fixes. At some point, the usefulness of the VM will come to an end and plans need to be made to take it out of service. (Normally, these plans are made well in advance of the decommissioning of the VM.) Phase 4: VM Decommissioned
When the VM is no longer needed, either because it is being replaced by a newer system or it no longer serves any useful function, it is decommissioned. Decommissioning is usually a fairly complex process when the VM is being replaced. If the services provided by the VM are no longer needed then decommissioning can be as simple as deinstalling the supporting configuration files. Plans for decommissioning are generally made well in advance of the actual deinstallation of the VMThe life cycle for virtual servers followsthe process defined for all types of VMs and can be reviewed Here. CI Ownership Matrix| Table plus |
|---|
| columnStyles | width:125px,width:175px,width:175px,width:175px,width:175px,width:175px,width:175px,width:250px |
|---|
| sortColumn | Priority |
|---|
| sortIcon | true |
|---|
|
CI Class |
Owner
|
Create CI |
Change CI |
Decommission CI | Maintain Relationships |
Auditing |
Comments |
|---|
| Virtual Server | - OIT group responsible for the installed OS
| - Server Owner
- Configuration Review Team
| - Server Owner
- Data Center Manager
- Configuration Review Team
| | - Server Owner
- Data Center Manager
- Application Owner
- Configuration Review Team
| - Server Owner
- Configuration Review Team
| A VM can be owned by a client when the VM is installed for a specific client or is used exclusively by one client. In most cases, however, the VM's owner is the OIT team responsible for managing the VM's OS. |
|
Audit & ValidationCIs will be periodically audited and information in the CI record will be validated against the actual asset. Wherever possible, auditing will be automated using a discovery process or some other method that does not require manual intervention. The result of the audit will be reviewed by the auditor who will also arrange for remediation of the differences. The audit process will be scheduled in such a way that every CI is audited at least once a year. Each time an audit is run, the following information will be maintained in a report that is stored with the CI class definition record in ServiceNow: - Date and time of the audit
- Auditor
- CI class
- Method of audit (i.e. based on automated tools or manual audit)
- Results of the audit
- Revealed differences between CMDB and actual CIs installed
- Effects of the deviations
- Corrections carried out to the CMDB
- Improvement potentials
- Reasons for the revealed differences between CMDB and actual CIs installed
- Measures for the future avoidance of the differences
Suggested RelationshipsConfiguration items falling into this group of asset classes typically have one or more of the following relationships with other CIs: Powered By | Circuit | Contained In | Equipment Rack | Runs | {operating_system} | Receives Data From | Mass Storage Device | Used By | Business Service | Hosts | Database |
|