Useful to have for any drawings or diagrams
Archive for May 2012
What is an ODBC Connection?
ODBC stands for Open Data Base Connectivity. It is a connection that is created to define a connection between a computer and a database stored on another system. The ODBC connection contains information needed to allow a computer user to access the information stored in a database that is not local to that computer. You need to define the type of the database application – like Microsoft SQL or Oracle or FoxPro or mySQL. Once you have defined the type of database you need to select or supply the appropriate driver for a connection (Windows already contains many of these) and then supply the name of the database file and the credentials needed to access the database.
Once the ODBC connection is created, you can tell specific programs to use that ODBC connection to access information in that database.
It was developed by the SQL Access Group in 1992 to standardize the use of a DBMS by an application. ODBC provides a universal middlewarelayer between the application and DBMS, allowing the application developer to use a single interface. If changes are made to the DBMS specification, only the driver needs updating. An ODBC driver can be thought of as analogous to a printer or other driver, providing a standard set of functions for the application to use, and implementing DBMS-specific functionality.
An application that can use ODBC is referred to as “ODBC-compliant”. Any ODBC-compliant application can access any DBMS for which a driver is installed. Drivers exist for all major DBMSs and even for text or CSV files.
VMware ODBC Connection Example
The database used for vCenter can be installed on a dedicated host, or the same host depending on the size of your environment. For scalability, I recommend installing vCenter and SQL Server on separate hosts unless your running a very small environment and know that it will never grow
Instructions
- Note SQL Server must be installed and a DB created for vCenter
- Note: The ODBC source vCenter uses must be created with the SQL Native Client driver (the SQL driver provided with Windows will not work.) The SQL Native Client driver can be found on the SQL Server 2005 installation media. Install this first
- Open Control Panel on your vCenter Server followed by Administrative Tools
- Open the ODBC Connection icon
- Click the System DSN tab and click the “Add” button
- Choose SQL Native Client
- Provide a Name for the driver (you will reference this name during the vCenter install) and provide the Hostname/IP of the SQL Server instance you created when you installed SQL Server
- Click Next and Select the “SQL Server authentication” type and provide the Login and password created from installing SQL Server – You will have logged into SQL Management Studio and created a new user (SQL Server Authentication)
- Click Next and Change the default database to the name of your previously created vCenter database
- Click Next and keep the following settings
- Click Finish
- Test Data Source. It should show the below
Deleting a VM with Raw Disk Mappings
How do you delete a VM with Raw Disk Mappings?
To the best of my knowledge, if you delete the VM it will only delete the pointer file and you would have to delete the RDM on the SAN.
Before deleting the VM, you could always click on Edit Settings and select the RDM and Remove Disk – Delete from disk. This should delete both the pointer file and the RDM.
Should you put Antivirus on your VMware Hosts?
Installing Antivirus software on the service console its like choosing between security and performance for ESX(i) host. It will impact your performance dramatically since it will use RAM/CPU and potentially causes performance degradation. ESX(i) is very secure platform and if you can lock-down your SC than you’re pretty safe. I wouldn’t recommend deploying any antivirus to ESX(i) service console at all. To maximize security on ESX(i)/SC, you can apply Tripwire Checkconfig tool, CIS security guide or even DoD UNIX SRR scripts that scan and remediate in depth with security world.
VMKernel Security
The below security features are inbuilt into VMware ESXi which indicate that VMware have already thought the security aspect through very well and should be an indication as to why adding Antivirus to these systems may not be absolutely necessary
- Memory Hardening
The ESX/ESXi kernel, user-mode applications, and executable components such as drivers and libraries are located at random, non-predictable memory addresses. Combined with the nonexecutable memory protections made available by microprocessors, this provides protection that makes it difficult for malicious code to use memory exploits to take advantage of vulnerabilities.
- Kernel Module Integrity
Digital signing ensures the integrity and authenticity of modules, drivers and applications as they are loaded by the VMkernel. Module signing allows ESXi to identify the providers of modules, drivers, or applications and whether they are VMware-certified. Trusted Platform Module (ESXi ONLY and BIOS enabled) – This module is a hardware element that represents the core of trust for a hardware platform and enables attestation of the boot process, as well as cryptographic key storage and protection. Each time ESXi boots, TPM measures the VMkernel with which ESXi booted in one of its Platform Configuration Registers (PCRs). TPM measurements are propagated to vCenter Server when the host is added to the vCenter Server system
Recommendations
- Lock down the service console to only those that require direct access to it.
- Don’t allow root logins, and use sudo instead, and integrate the logins into an LDAP or AD infrastructure.
- There are very few viruses that will affect a Linux system, and they require specialized privileges to infect, and then run on a *nix system.
- You want to minimize the agents running on an ESX(i) host, even though it has a service console that is Linux, you want to minimize any additional software that may interfere with the running of the VMkernel.
Robert Moog’s 78th birthday celebrated in Google doodle
Google has marked the birthday of music pioneer Robert Moog by creating a ‘Doodle’ in the form of an interactive electronic synthesiser which can be played by clicking on its keys using a cursor.
Although musical synthesisers already existed, Moog transformed pop music during the 1960s by producing and marketing a small keyboard synth which could be used with relative ease.
Bands including the Beatles and the Doors used the Moog synthesiser, while others later became fans of the Minimoog, a stripped-down version which followed it in the 1970s.
The New Yorker, who would have turned 78 on Wednesday, had been encouraged to dabble in electronics from an early age by his father and built his first electronic instrument, a theremin, at the age of 14
The pair started their own company in 1954 to sell theremin kits by mail order. After studying at the Bronx High School of Science, Moog attended Queens College before graduating in electrical engineering at Columbia University and earning a doctorate in engineering physics at Cornell.
Of the Moog synthesiser, which appeared in 1964, the inventor was to later recall: “I didn’t know what the hell I was doing. I was doing this thing to have a good time, then all of a sudden someone’s saying to me, ‘I’ll take one of those and two of that.’ That’s how I got into business.”
Moog died in 2005 at the age of 71, after being diagnosed with a brain tumour four months previously. However, the Moog sound has lived on, with musicians such as Fat Boy Slim choosing to continue to use it even in the digital era.
What is the /admin switch in Microsoft Terminal Services Client (MSTSC) for Windows 2008 and Vista?
Although the /console switch no longer has any effect on Server 2008 and Vista Terminal Server connections, a new switch called the /admin switch has a similar effect when you use it to connect to a Server 2008 server with the Terminal Services role. When you use this switch with MSTSC, connections don’t consume Terminal Services CALs.
The /admin switch involves elevated rights. If a user has the authority to use the /admin switch but has been marked with Deny Users Permissions To Log On To Terminal Server, he or she will be able to connect using mstsc /admin. Also, if a terminal server is in drain mode (no new sessions are accepted), an /admin session can still be created. The /admin sessions don’t count toward the session limit that may be configured on a terminal server to limit the number of session
VMware DB Scripts for Performance Stats
We reinstalled our SQL Server 2008 Database completely and restored the Virtual Center DB and the Virtual Update Manager DB mainly due to someone installing the SQL Server 2008 software in Evaluation Mode which then expired and caused us no end of problems!
What you need to remember if you rebuild and restore the databases is to add the performance scripts back into SQL Server Management Studio for Weekly, Monthly and Yearly
The Issue
Following a SQL DB re-installation and restore we were doing the following
- Click on Host
- Click on Performance Tab
- Click Advanced
- Click on Chart Options
- Choose Week, or Past Month
It comes up with “Performance Data is currently not available for this entity”
Instructions
- Depending on how you are setup. (We had a separate VM for our DB and vCenter Server)
- Log into SQL Management Studio on your Database Server
- On the DB Server, create a shortcut to your vCenter Server to the following path. (This contains the scripts you need and may be on the C or D Drive)
- D:\Program Files\VMware\Infrastructure\VirtualCenter Server
- Make sure you have the Virtual Center DB selected in SQL Management
Studio. Then just double click the file, it should open against the VCDB. - Check this link for the script names
- If you have problems with that for any reason you can create a new query
against the VCDB and then open up the SQL scripts in notepad and copy
across. - The scheduled jobs trigger the stored procedures which are already part of the DB. Amongst other things they clear out the raw data after it’s been processed and is no longer needed, they will also remove old tasks and events from the DB.
Scripts
This is what you should see in your SQL Server Management Studio Application
SQL Database Tables getting too big in VMware
Checking vCenter DB Table sizes
Sometimes you can experience issues with the vCenter Database getting too large. If you want to check the table sizes to confirm this, please do the following.
- Open SQL Management Studio
- Select vCenter DB name
- Execute the following query to get Table sizes
Create Table #Temp(Name sysname, rows int, reserved varchar(100), data varchar(100), index_size varchar(100), unused varchar(100))
exec sp_msforeachtable ‘Insert Into #Temp Exec sp_spaceused ”?”, ”true”’
Select * From #Temp
Drop Table #Temp
Purge Scripts
There are a set of purge scripts where you can set how much historical data you keep and it will remove everything else from the DB.
Take a look at this KB, it runs through the process and has a link to the scripts:
http://kb.vmware.com/kb/1025914
One thing I will say is that the scripts can take a long time to run, If the size of your DB is quite large, it could take quite a while to complete. I would kick it off and let it run over the weekend if it hasn’t completed by the end of the day. Also the scripts are perfectly safe but I would take a backup of the DB before doing anything just for peace of mind
DB Maintenance
You should run a shrink on the DB to remove empty space and a regular backup is a good idea as MS SQL uses this to do maintenance on the DB. If you check out the Microsoft documentation for your version of MS SQL there should be detail and recommendation for setting that up
Useful Links
Defragmenting VirtualCenter performance data indexes on a Microsoft SQL database:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003990
Unable to get an exclusive access to the vCenter Server repository:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006369
ESXi 4.1 Active Directory Integration
Although day-to-day vSphere management operations are usually done on vCenter Server logged in through the vSphere Client, there are instances when users must work with ESXi directly, such as with configuration backup and log file access. Then there are monitoring solutions, which sometimes require direct access to the ESXi host; these would typically be configured to use service accounts. Prior to ESXi 4.1, you could only create local users, which each had separate locally-stored passwords per host. Since this is cumbersome and doesn’t scale, VMware decided to address this in the vSphere 4.1 release.
With ESXi 4.1, you can configure the host to join an Active Directory domain, and any user trying to access the host will automatically be authenticated against the centralized user directory. Any time you are asked to provide credentials (e.g., logging in directly to the ESXi host using vSphere Client, or running a vCLI command or script), you can enter the username and password of a user in the domain to which the host is joined. The big advantage of this is that you can now continue to manage user accounts using Active Directory, which is significantly easier and more secure than trying to manage accounts independently on a per-host basis.
You can still have local users defined and managed on a host-by-host basis and configured using the vSphere client, vCLI or PowerCLI. This can be used in place of, or in addition to, the Active Directory integration. I’m not sure if there is really a good reason to do this if the host is already joined to an AD domain, but this capability is available.
If the host is integrated with Active Directory, local roles can also be granted to Active Directory users and groups. For example, an Active Directory group can be created to include users who should have an administrator role on a subset of ESXi servers. On those servers, the administrator role can be granted to that Active Directory group; for all other servers, those users would not have an administrator role. ESXi 4.1 also automatically grants administrator access to the Active Directory group named “ESX Admins,” which allows the creation of a global administrators group. (If you want to override this behavior, simply configure the roles on the ESXi host to give the “No Access” role to the “ESX Admins” group — this will override the default behavior).
Instructions
- Select a Host > Click Configuration > Click Authentication Services
- Click Properties and choose Active Directory from thr Drop Down Option and then type in the domain. In this example, it is domain.local
- Click Join Domain and Enter a username and password which has authority to join machines to the domain
- You have now joined the host to the AD Domain
- Log into Active Directory and you now need to create a new Global Security Group called ESX Admins. This is the default security group that the ESX host is going to be looking for
- Right Click Group and Add Members
- Now you can test this by opening up the vSphere client and test this
- If you then click on the Hosts and click on Permissions, you will see the ESX Admins Group Listed
- You can then add other Permissions by right clicking in the screen and selecting Add Permission
- Choose your AD user and then select the VMware Role you want this AD user to have
Memory Over Allocation for VM’s – What Happens?
ESX employs a share-based allocation algorithm to achieve efficient memory utilization for all virtual machines and to guarantee memory to those virtual machines which need it most
ESX provides three configurable parameters to control the host memory allocation for a virtual machine
- Shares
- Reservation
- Limit
Limit is the upper bound of the amount of host physical memory allocated for a virtual machine. By default, limit is set to unlimited, which means a virtual machine’s maximum allocated host physical memory is its specified virtual machine memory size
Reservation is a guaranteed lower bound on the amount of host physical memory the host reserves for a virtual machine even when host memory is overcommitted.
Memory Shares entitle a virtual machine to a fraction of available host physical memory, based on a proportional-share allocation policy. For example, a virtual machine with twice as many shares as another is generally entitled to consume twice as much memory, subject to its limit and reservation constraints.
Periodically, ESX computes a memory allocation target for each virtual machine based on its share-based entitlement, its estimated working set size, and its limit and reservation. Here, a virtual machine’s working set size is defined as the amount of guest physical memory that is actively being used. When host memory is undercommitted, a virtual machine’s memory allocation target is the virtual machine’s consumed host physical memory size with headroom