Virtual machines and cmdb

[vking]

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

[mulvihillm]

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.

[dboylan]

A VM would be a great use of the Configuration Management's Variants as described in Service Support section 7.11.2.

[rpmason]

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.

[vking]

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

[poloneck1]

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

[vking]

Hi Poloneck1,

That sounds like a really good suggestion

Thanks

[sseliquini]

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

[mnp123]

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.

[Fabien]

[mnp123]

Do you immediately purge/delete a CI from CMDB once the status of virtual server is no longer in use/disposed?

[jc3275]

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

[Bluesman]

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

[kevo]

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.

[UKVIKING]

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