Virtual Machines, Virtual Servers and VMWare Server Farms
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-08-2016 08:21 AM
Hi community,
I must configure manually (from a file) a VMWare environment.
ServiceNow version is Helsinki.
Data provided are: ESX server names, Server Farm names, Virtual Server Names (with Operating System information and other).
I'm thinking to implement the following configuration:
This is not including all table and classes proposed for VMWare environment, but make sense to me and is in line with the information I've got.
1 ) Because I'm far to be "a champion", I would like to receive comments, indications or correction to the above schema.
2) Currently there are no plans for Discovery projects, but likely it will be discussed next year.
If you see any potential issues due to the adoption of the above schema, please let me know.
Thank you in advance for your attention,
Valter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-08-2016 08:36 AM
I think you layout makes logical sense given the usage of the OOB tables. Placement of the virtual servers inside the cmdb_ci_win_server would make the most sense to leverage the attributes and it would align with how discovery would do it in the future.
Pointing out future concerns would be the relationships and how discovery creates them vs your manual work. It sounds like you are making decent choices on the actual CI placement, but if possible make sure to bring over the UUID that VMware provides as we do use that for matching in our OOB scripts and Discovery. Luckily we have documented this well to show what relationships we would create in Discovery, and from your example it seems you may have found it. vCenter data collected. Hopefully referring back here will help with other items going forward.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-09-2016 01:09 AM
Hi Jake,
as first, thank you. I did not know the link you provided and I found it useful.
But the indicated relationship:
Computer [cmdb_ci_computer] --> Virtualized by::Virtualizes --> ESXi Server [cmdb_ci_ESXi_Server]
confuse me.
It might be a matter of definitions, but to me the ESXi Server is the hw used to build the Server Farm and it should not be directly related to the VM (hosting it's own OS, applications and so on).
However, I'll take care of your indication for further studies.
Thank you again,
Valter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-09-2016 05:12 AM
Discovery is able to keep that relationship fresh with the usage of querying vCenter and getting events from vCenter to know when a virtual machine moves between esx hosts. Depending on how your current manual integration goes that might be more of a challenge to manage and keep accurate. That type of relationship might be better to come back to or help drive adoption of Discovery in the future .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-09-2016 07:02 AM
Thank you Jake,
I understand that discovery is able to keep aligned VM and ESX, but the instructions that you provided refer to a (virtualize::virtualized by) relationship between a "Computer" to ESX, and not between a VM to ESX (that's sound understandable to me).
Now, the reason of my difficulties is that I'm trying to keep track of two kind of information, conceptually part of a Virtual Machine, like Lease start/end and OS/OS version.
In ServiceNow those information are store in two different tables: cmdb_ci_computer and cmdb_ci_vmware instance.
This is why I'm trying to keep the two tables toghether.
Of course I can use different methods, like adding fields to one table or another, but not yet.
I'll spend some other time studying and experimenting before to take the final decision.
In the meanwhile fill free to contact me or add your comments.
Thanks again,
Valter