You make a good point Terry. One of the reasons we did this way in this case is because there was a requirement from the business to NOT distinguish between virtual servers and physical servers in the product categorization.... So that's why the differentiation happen on the product name and manufacturer in this case.
As far as what the user sees when they hit <Enter> on the product name field, it all depends on your data catalalog -Guillaume -----Original Message----- From: Action Request System discussion list(ARSList) on behalf of Terry Bootsma Sent: Mon 01/19/09 7:41 PM To: arslist@ARSLIST.ORG Subject: Re: Accounting for Virtual Servers in the CMDB RE: Accounting for Virtual Servers in the CMDBI agree with Guillaume's approach on storing both the physical and virtual servers in the same place. It makes searching/finding configuration items a lot easier for someone who is using Incident or Change Management when they are stored in the same class, not to mention Configuration Management. However, something to consider, by using a different 'Product Name' (like Guillaume suggests), the Incident/Change user has to know the product name when searching from the Incident/Change window in the 'Product Name' field to autopopulate fields on the Classification tab. (such as Product categorization, make/model and version) So, if they know that it is a virtual server, they would need to specify "VMWARE Virtual Platform" to search the full list of virtual servers from the Incident Management window (where the user should be relating the incident to the CI). I don't know if this is very practical from an Incident/Change perspective. For this reason, I tend to use more logical product names and differentiate physical/virtual servers either in Categorization of the server or via special attributes added to the class. This is one of the pitfalls I commonly see where the Product Name definitions suit the needs of the CMDB, but do not make it practical from an Incident and Change Management perspective. If you are unsure of what I am talking about, Open an Incident Management window, go to the classification tab, and type a product name in the product name field and hit <CR>. See what the CMDB returns in the resultant window. Good luck. Terry -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Guillaume Rheault Sent: Monday, January 19, 2009 10:41 AM To: arslist@ARSLIST.ORG Subject: Re: Accounting for Virtual Servers in the CMDB ** We have the virtual servers in the computer system class, just like physical servers. To identify whether it is a physical server or a virtual server, we use the product name and the manufacturer. For instance, for VMWare, the manufacturer is "VMWare Inc", and the product name is "VMWare Virtual Platform". We could have created a new attribute, a radio button, to specify physical or virtual server, but in the end, we felt it was not needed because the manufacturer and the product name are sufficient to distinguish the type of server. The advantage of having physical and virtual servers in the computer system class is ease of use: you don't have to know in advance whether it is a physical or virtual server when querying the entries. This is solution is very usable and keeps things simple. If you use the virtual system class to store the virtual servers and the computer system class to store the physical servers, then this means that the user (system administrator, DBA, app developer, etc) would need to know to query the virtual system class for virtual servers and the computer system class for physical servers... not very usable, they probably will not like that. The relationship of the virtual server to the physical server is desirable to have. In both scenarios (VM in virtual system class or computer system class), you can create a relationship to the parent physical server computer system entry. So no impediment there either way. As background information, in the CMDB 1.x, when the user queried the entries for a class, with an unqualified search, the entries for subclasses were also displayed. This changed in CMDB 2.x: if you query a class, you will not see the entries for the sub-classes. The Virtual System class is a sub-class of computer system, so you have to query that form/class specifically to display the entries. All this is "thanks" to the new class stub OBJSTR:CatClassStub. I guess BMC considered the CMDB 1.x behavior a bug, or at least unexpected behavior, which in a sense it was. However, it also makes the new structure a bit less usable in a way. -Guillaume Rheault -----Original Message----- From: Action Request System discussion list(ARSList) on behalf of SCOTT PHILBEN Sent: Fri 01/16/09 11:02 AM To: arslist@ARSLIST.ORG Subject: Accounting for Virtual Servers in the CMDB Is anyone using the CMDB (2.1 patch 004) and Asset application (7.0.3 patch 008) to account for virtual servers? Does anyone have a white paper with some best practices that I could steal? There seems to be classes that are related to Virtual servers (System-->Virtual System for example) but how are they best used? Standalone? Related to a Computer System? If anyone is doing it or has information, please pass it along. Thanks. Scott Philben CSC Remedy Developer __________________________________________________________________________ _____ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
