Posted by Brian on Nov 22, 2011 in Performance, vCenter Server, vCloud, vMA, VMware | 0 comments
I would like to start off by saying that it’s nice to see VMware starting to bundle up some of their offerings into more complete packages. Many of these tools were acquired recently and it takes time to integrate them with their own applications. I have not looked recently to see if there is any price advantage to buying the bundle versus the apps separately. The main thing is that they continue to add functionality by tightly integrating the apps to work together.
The new vCenter Operations Management Suite has 4 versions available for the package, you can view the table here to compare versions. The highest version available is the Enterprise Plus, it looks like maybe VMware is starting to standardize on their version naming to match what vSphere has been using for years. This version offers the performance monitoring of vCOPs, Infrastructure Navigator, Chargeback manager and Configuration Manager. Until recently you would normally have to purchase these all separately and the cost was per VM based and could be pretty expensive for large environments.
One of the features that has me most excited was the integration between configuration manager and vCOPs. I saw a demo and cannot find it again right now. It showed that when viewing a host for example that is experiencing a performance issue you can correlate the change in performance with any configuration changes that took place at the same time the issue started. So if another team member or maybe yourself was updating a value on network cards and it did not produce any noticeable errors during the change. But vCOPs was tracking a change in performance the new suite will help brings these 2 separate tracks of information together to help fix issues and find root causes faster. Once I can find the screen shot again I will try to remember to update this post with it.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (169)
Posted by Brian on Nov 17, 2011 in Cloud, Orchestrator, vCloud, VMware | 0 comments
In working on several Cloud related projects one of the items that sticks out to me is the need for deeper automation within the vCloud Director product. I understand this is still just version 1.5, but with how hard VMware is pushing the “Your Cloud” journey. I think that some parts are just not ready for what some companies need to do in the way of automation.
If self-service is suppose to be such a big part of Cloud, then the need for automation is going to play a big part. Not everything can be accomplished from creating templates and using customization to change the identity of the new VM. In server virtualization this worked great and saved time for most IT shops. But there were still manual processes that some shops needed to do. This breaks the idea of self-service IT, if a user still relies on someone to execute a manual process to have a VM or application provisioned from vCloud.
I guess what this mostly deals with is private cloud. Many IT shops are trying to automate the creation of as many servers and platforms as possible, to reduce their work load in provisioning new servers. But there are still some manual processes that need to take place and I think that being able to tie vCenter Orchestrator more tightly with vCloud Director could go a long way in help this issue.
Other cloud software companies such as DynamicOps are already doing this type of thing. By making the workflow or automation part of their offerings built into the same admin console. This allows for tight integration and opens up the options for what you are allowed to automate.
If you listen to rumors and in dark alleys you might hear that this type of integration is coming from VMware in a future release. Nobody knows if it will be the next release or even when that will happen.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (169)
Posted by Brian on Nov 7, 2011 in Blade Servers, Hardware, HP | 0 comments
Since vSphere 4 came along VMware has been working with CIM (Computer Information Model) drivers to try and present up details about the underling hardware that vSphere is running on. Initially this was things like health of CPU, Memory and errors like a failed fan and such. But something that I always thought was missing is visibility into locally configured RAID volumes.
For example if you are running ESX(i) on a mirrored pair of local drives, if you are a shop that does not have very good hardware monitoring you might have no idea of the health of this mirror that vSphere is running on. So this becomes even more important with more shops experimenting with running certain workloads on local disk. With VMware and storage companies creating Virtual Storage Appliances that can run on these local disks and still provide the benefits of shared storage, this becomes a must to understand what is happening in your local disks environment.
With the latest batch of CIM drivers from HP they are now exposing some of these details. You can now see the drive configurations and status. The image below shows that a drive is rebuilding in the RAID config. This should be a feature that many HP shops will be happy to see. If you have noticed any other good features from this update leave a note in the comments for others.
a
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (169)
Posted by Brian on Apr 18, 2011 in IBM Servers, VMware, vSphere | 8 comments
I’ve been working with a client lately on a datacenter move and they have selected IBM x3690 servers. The 3690′s will be the ESXi hosts for the new site and are running ESXi embedded. I have not had the opportunity to work with many different clients that choose the embedded route, so it was cool to see how IBM setup the servers.
The servers came with ESXi 4.0 installed on a USB stick from the factory and installed in one of the two internal USB ports that the server offers. Upon turning on the servers some of them booted right to VMware and some did not. After some further looking into the boot order in the BIOS I noticed that the Embedded Hypervisor option was not added to the boot order on a couple of the servers. A quick add and they were running just like the rest, guess someone at the factory missed that one.
The servers took a very long time to post and boot up, part of this was due to the 128 GB of RAM installed. We turned off some of the non-essentials and modified the boot order to go right to ESXi and cut the post time down some. You can see from the image below it’s just another x-series server.
I snapped the image below with the cover over showing off all the sticks of memory installed.
The last image below is a close up to the two USB ports that are internal to the server. The lower one as the USB stick from the factory with ESXi embedded on it.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (169)
Posted by Brian on Apr 11, 2011 in CLI, vMA, VMware, vSphere | 0 comments
This is not something that I’ve had to do very often. But on a recent customer engagement I was working with the client on setting up some new hosts that were recently purchased. These hosts were purchased with Embedded ESXi on them and additional PCI NICs were added to the config. The additional NICs did not have drivers available in the base ESXi build. Shortly after bringing the first host online we noticed that only the onboard NICs showed up in the list.
A quick search on Google for the Intel part number for the NIC lead me to the family name for the adapter. Then a search over at VMware lead me to the download page for VMware that provided the .ISO file to load the drivers into ESXi for the family of adapters. The process took only a few minutes and since this is something that does not come up that often I thought a short write up might help someone.
There are a few ways that this could be done, since we happened to be running ESXi the options were to use the vMA or vCLI. Since this was a new install and a vMA was not setup yet I just quickly tossed vCLI on a server. Then a quick download of the driver .ISO from VMware and unzip the package into a folder on the server with vCLI installed on it. If you wanted to use the vMA you could mount the .ISO to the virtual CD-ROM of the VM and issue the command against it.
Since I was using vCLI all I needed to do was point the command to a local folder. Here is a sample of the command used to perform the patch.
vihostupdate –server HOSTNAME –install –bundle c:\folder\name_of_file.zip
To run this command your host must be in Maintenance mode and it will then take just a couple of minutes to execute. After the update completes a reboot of the host is needed and then the cards should be available for use.
Brian is a Technical Architect for a VMware partner and owner of this website. He is active in the VMware community and is helps lead the Chicago VMUG group. This blog Virtualize Tips was started to document and remember things that I come across while working with tech.
Mail | Web | Twitter | LinkedIn | More Posts (169)
