Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: MWaldock
New Today: 55
New Yesterday: 76
Overall: 142350

People Online:
Visitors: 47
Members: 2
Total: 49 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ź ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Virtual machines and cmdb
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Virtual machines and cmdb
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
vking
Newbie
Newbie


Joined: Nov 05, 2007
Posts: 3
Location: UK, W Mids

PostPosted: Tue Nov 06, 2007 11:23 pm    Post subject: Virtual machines and cmdb Reply with quote

Would anyone have any ideas/tips on how to use the cmdb with virtual machines.

I ask as i'm wondering where to start with say the following

Relating to physical servers
Dealing with ci numbers, whether to go for say VI instead of CI
Dealing with movement of VM's between physical server
Naming conventions

Any pointers would be appreciatted
Back to top
View user's profile
mulvihillm
Newbie
Newbie


Joined: Jul 25, 2007
Posts: 1

PostPosted: Wed Nov 07, 2007 3:20 am    Post subject: Reply with quote

I define partitions to be a hardware CI. Then I associate it to the physical CI such ar mainframe. then I assign other CIs to the partition such as software, location, contact, etc.
Back to top
View user's profile Send e-mail
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Wed Nov 07, 2007 3:26 am    Post subject: Reply with quote

A VM would be a great use of the Configuration Management's Variants as described in Service Support section 7.11.2.
Back to top
View user's profile
rpmason
Senior Itiler


Joined: May 25, 2007
Posts: 105
Location: USA

PostPosted: Thu Nov 08, 2007 1:17 am    Post subject: Reply with quote

We have a homegrown CMDB whose data will eventually be ported to the ever-being-pushed-out "real" Service Management tool.

In any case, we have a CI category of virtual server (VS), be it LPAR, Linux Guest, MS Virtual Machine, or whatever. Currently we have Linux Guests residing within LPARs. The VS CI has a physical relationship to the physical machine or LPAR within which it resides.

Our VSs don't move around too often (yet), but you might consider the creation of a CI category to comprise the physical servers between which a VS might move (similar to a CI category of Cluster) and associate the VS to that CI category.
Back to top
View user's profile
vking
Newbie
Newbie


Joined: Nov 05, 2007
Posts: 3
Location: UK, W Mids

PostPosted: Thu Nov 08, 2007 11:46 pm    Post subject: Reply with quote

Thank you all for your advice.

Just one more question, how do you deal with the asset number, say for a VS.

ie I attach a physical asset tag to physical servers.

Would you just assign a physical tag number to a VS
Back to top
View user's profile
poloneck1
Newbie
Newbie


Joined: Sep 21, 2005
Posts: 3
Location: Uk, North West

PostPosted: Mon Nov 26, 2007 11:24 pm    Post subject: Virtual machines and cmdb Reply with quote

Hi vking,

When my most recent client embarked upon a server virtualisation project, we decided to keep it simple with respects to how these CIs were tagged.

From a CI perspective both the physical server and virtual servers were represented by CIs within the CMDB. A relationship was then built between the physical box CI and the virtual server CI.

Clearly, you cannot attach a physical tag to a virtual entity, so we used a modifed version of the physical asset tag to tag the virtual box.

We did this because the most pragmatic way to identify a virtual box for us was by it's hostname. However, we had business rules in place that stated that every CI must have a tag number. We also had another business rule that stated that every CI name in the CMDB should be unique, so a modifed version of the physical CI tag seemed the way to go.

Here is an example of what we did:

Physical box - tag number 123456
Virtual server #1 - tag number 123456A
Virtual server #2 - tag number 123456B
Virtual server #3 - tag number 123456C
and so on...

I'm sure that this approach won't suit everyone, but it worked for us.

Hope this helps
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
vking
Newbie
Newbie


Joined: Nov 05, 2007
Posts: 3
Location: UK, W Mids

PostPosted: Mon Dec 03, 2007 8:36 pm    Post subject: Reply with quote

Hi Poloneck1,

That sounds like a really good suggestion

Thanks
Back to top
View user's profile
sseliquini
Newbie
Newbie


Joined: Feb 29, 2008
Posts: 11

PostPosted: Sat Mar 01, 2008 5:11 am    Post subject: Reply with quote

Hi vking,

Just my 2 cents. We are using VMWare for our virtualization of servers so we decided on the following:

The physical servers are each their own CI
The VMWare clusters are each their own CI
The virtual servers are each their own CI

We created a relationship between the physical servers in a particular VMWare cluster to that cluster.

We created a relationship between the virtual servers and the VMWare clusters they run on.

With this solution, if a virtual server moved from one physical server within the same cluster, we still had a correct relationship.

If a virtual server moved from one cluster to another, we would change the relationship for that virtual server from the original VMWare cluster to its new VMWare cluster.

Cheer,

SS
Back to top
View user's profile
mnp123
Itiler


Joined: Dec 26, 2007
Posts: 24

PostPosted: Wed Mar 12, 2008 1:06 am    Post subject: Reply with quote

Hello poloneck1

The workaround you have provided might work when their is no linkage between the discovery and CMDB. Once you get to the auditing of CI's in CMDB through discovery process you will have problem since these tags will not be used by discovery. We have found out through our extensive testing that each virtual instance has a serial number associated with it same as physical server. Use serial number as your primary key in CMDB so that once the discovery processes recognize that virtual machine it can automatically do the auditing based on serial number. Just my 2 cents.
Back to top
View user's profile
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Wed Jun 18, 2008 6:31 am    Post subject: Reply with quote

sseliquini wrote:
Hi vking,

Just my 2 cents. We are using VMWare for our virtualization of servers so we decided on the following:

The physical servers are each their own CI
The VMWare clusters are each their own CI
The virtual servers are each their own CI

We created a relationship between the physical servers in a particular VMWare cluster to that cluster.

We created a relationship between the virtual servers and the VMWare clusters they run on.

With this solution, if a virtual server moved from one physical server within the same cluster, we still had a correct relationship.

If a virtual server moved from one cluster to another, we would change the relationship for that virtual server from the original VMWare cluster to its new VMWare cluster.

Cheer,

SS


This is the way we are working as well. It is efficient and it allows for VMWare to manage partitions dynamically. I am currently planning the use of a report that identifies which VM runs on which host, and either file that report with the cluster on a daily basis, or use it as a feed to automate the management of "runs on" supplemental relationships between a VM and its host. We are sometimes experiencing issues due to conflicting demand levels between VMs and keeping close track of what runs where is helpful. but the solution above, for me, is a must.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
mnp123
Itiler


Joined: Dec 26, 2007
Posts: 24

PostPosted: Tue Jul 15, 2008 10:19 pm    Post subject: Reply with quote

Do you immediately purge/delete a CI from CMDB once the status of virtual server is no longer in use/disposed?
Back to top
View user's profile
jc3275
Newbie
Newbie


Joined: Dec 30, 2008
Posts: 2
Location: New Jersey, USA

PostPosted: Wed Dec 31, 2008 2:13 pm    Post subject: Reply with quote

We don't delete CIs in our implementation. The status of the CI is changed to retired or decommissioned. These CIs could also be moved to a separate dataset, but we don't do that.

JC
Back to top
View user's profile
Bluesman
Itiler


Joined: Mar 19, 2008
Posts: 29

PostPosted: Tue Apr 28, 2009 10:04 pm    Post subject: Reply with quote

Deleting any CI can (and will) make loads of related records into "orphans" and will destroy parts of your incident/service request/change history - which you need for trend analysis, amongst other things. Bad move, IMHO.

As to the original question, weŽre still fumbling in the dark there, too..those VM:s can be a headache in more than one way.

My original idea was like this: Make anything that can break or fail a CI first. Important details go into the CI as attributes.
DonŽt go over-granular. Make it easy to get a fast and correct helicopter view from different places/ITIL roles. So - use the KISS concept:

The services (from the catalogue) that are running on the virtual boxes are a CI. This helps the SD to tie incidents to services, not machines or infrastructure.

The virtual boxes are a CI, with attributes (service (from catalogue) running, OS, patch level, IP etc). They can move around, they can contain more than one service, hence = CI

The physical box is a CI with attributes (hardware, current virtual boxes onboard, storage area/SAN location/config, etc)

The storage area is a CI (with attributes - connected servers, firmware level etc)

Tie all these together with two-way relations in a sensible way to get the connections - physical and logical, and service-wise. Think "visual network diagram".

Doing this at the right granularity level will give you a clear view what goes on (down) when things break or changes are applied.

Still not done with the thinking, tho - this may or may not be our way to do it. And at the end of the day - can the toolset (to be used eventually) handle this way of thinking??



Cheers /Richard
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr
Back to top
View user's profile
kevo
Newbie
Newbie


Joined: May 29, 2011
Posts: 4

PostPosted: Mon May 30, 2011 7:12 am    Post subject: Reply with quote

I also have my doubts if we should include VM's on our CMDB. A lot of users will now have VMs (with a recent change) but I dont see the use of including them as CI's ...as of yet.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3299
Location: London, UK

PostPosted: Tue Jun 21, 2011 7:39 pm    Post subject: Reply with quote

A server is a CI whether it is a virtual server or a physical server

If you are using Virtualization for systesm that are part of a service then you need to have them in your asset register / cmdb

You need to have the physical device.
You need to have the software services and applications
You need to have the virtual servers

If the virtual server has an IP address, host name, performs a function, then it is as real as a real physicial server as far as providing service

You need to have the V-server in the system so that you can track faults with the service that is being provided
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.