Posted by Brian on Apr 30, 2010 in Tools, VMware | View Comments
I have written about RV Tools in the past and what a great free tool Rob has created. He has recently updates to version 2.9 with some new features. I recommend that you have a look and I know it’s a staple in my toolkit. Here are some of the updates in this new version. You can download the tool from Rob’s site here.
- On vHost tab new fields: Vendor and model.
- On vHost tab new fields: Bios version and Bios release date.
- On vInfo tab new field: VM overall size in bytes (visible when using VI API 4.0)
- On vSnapshot tab new fields: Snapshot filename and size in bytes (visible when using VI API 4.0)
- New vNic tab. The vNic tab displays for each physival nic on the host the following fields: Host, datacenter, cluster name, network device, driver, speed, duplex setting, mac address, PCI and wakeon switch.
- Layout change on vHost, vSwitch and vPort tabpages. They now all start with host name, datacenter and cluster name.
- The commandline function ExportAll extended with an extra optional parameter. It’s now possible to specify the directory where the export files are written.
read more
Posted by Brian on Apr 30, 2010 in Performance, VMware | View Comments
By now I’m sure that you know how to do a P2V or Physical to Virtual migration. There are several quality tools available including VMware Converter available as a Free download. But after you have converted your physical machine there will be some further clean up to do on your new virtual machine. This clean up is necessary to make sure you will have a stable and error free VM.
What exactly do you need to clean up? Well since a migration to virtual is a exact copy of the physical machine there will be left over applications, device drivers and non present devices left over. These all can affect the performance and stability of your virtual machine.
The first step you can perform is to remove and vendor specific applications or device drivers installed. You can remove these as you would any installed applications. These could be video drivers, nic teaming applications or management agents. They should all be removed as they will no longer work in your virtual machine and are likely to cause issues.
The next step is to remove any old devices that are no longer present and are not showing up in Device Manager. To do this you will have to enable the ability to see non present devices. I have list two methods below to enable this ability on Windows servers. These commands must be run from your newly created virtual machine.
Method 1:
Open a command prompt
Set devmgr_show_nonpresent+devices=1
Then open up Device Manager
Click View and then click Show Hidden Devices
Expand each section and look for devices that are dimmed
You can then right click them and choose Uninstall to remove
Method 2:
Right click on My Computer icon and select Properties
Click the Advanced tab
Click the Environment Variables button
In the lower part of the window just below the System variables box click on the New button
Variable Name = devmgr_show_nonpresent_devices
Variable Value = 1
then click OK to create the new variable
Click on OK buttons on remaining windows to close out of them
Now you will be able to start removing old devices
Then open up Device Manager
Click View and then click Show Hidden Devices
Expand each section and look for devices that are dimmed
You can then right click them and choose Uninstall to remove
Hope this gives you a start on your clean up process for freshly converted virtual machines. There are sure to be some other tasks that might be worth doing also, take these and create a process that works for your environment.
read more
Posted by mike on Apr 25, 2010 in VMware | View Comments
Needed some new switching action for the lab, can’t wait for them to arrive! I’ll be documenting the new lab setup here soon. I think I might need a 24U rack…
read more
Posted by Brian on Apr 22, 2010 in VMware, vCenter Server | View Comments
I know this would seem like an easy thing and you might not give it a second thought. But if you’ve ever had an alarm that just wont clear and the virtual machine is no longer suffering from the event that caused it. Then you might benefit from the following suggestions that I came across. As always I recommend that you investigate each alarm and make sure that your are not ignoring any serious issues before clearing any alarms.
Sure alarms can alert you to some pretty serious events, but many are triggered by short term or non-reoccurring events. You might get an event for excessive CPU utilization due to something crazy happening on a Windows server. It passes or was dealt with by the SA and does not return. But that nagging alarm keeps staring you down each time you visit vCenter. Sure you have acknowledged the alarm and plenty of time has passed without a re-occurrence. But that little red diamond alarm still remains.
Option #1 is the simplest way and will not cause any interruptions to any tasks. This method will clear the alarms but it will clear them for all hosts, VMs, datastores or whatever you are clearing the alarm for. Also you must do this at the level that the alarm was created on, for example if the alarm was created at the Datacenter level then it will clear the alarm for every object in that Datacenter for the specific alarm that you are modifying. Once you located the correct alarm at the proper level you need to edit the alarm and uncheck the Enable this Alarm setting. Give it a few seconds for the command to complete then you can re-edit the alarm and enable it again. This will clear all occurrences of this alarm at this level and below.
Option #2 is a more manual way but will also only clear alarms on a specific host. With this method you need to be able to restart services on the host. I will usually just use Putty and SSH to the host and run from the command line. You the command that I have listed just below to restart the VPXA service and this should clear All alarms on this ESX host. Just be sure that you have looked at the cause of all alarms for this host before clearing them.
# service vmware-vpxa restart
If there are any other good options for clearing these alarms feel free to drop a note in the comments and I will update the post.
read more
Posted by Brian on Apr 15, 2010 in VMware, vCenter Server, vSphere | View Comments
This something that I don’t have to use very ofter but it can save sometime if you have a standalone ESX hosts. If you have vSphere with vCenter server than Storage VMotion is the way to do this same thing. It’s also much easier to accomplish. But if you are a small shop or have a standalone host some place these few steps will get the job done.
Just to make things clear you cannot do this while the Virtual Machine is running, you will have to shut it down first. Then log into the service console via SSH or at the console directly. You need to login with root privileges or us SU – to elevate your rights.
Before starting you will need to find out the LUN ID that your machine is located on. You do not want to use the datastore friendly name for these commands. There are 2 ways that you can find this out.
First method is from the command line you move into the /vmfs/volumes directory and list its contents. You can then move into the different LUN’s to find the Virtual Machine that you want to move.
The second option to find out the LUN ID would be to connect directly to your host. Then go to the Configuration tab and click on storage from the left section. You can then click on the Datastores and you will be able to see the ID in the lower section. I circle an example on the picture above.
Now that you have identified the LUN ID’s and shutdown your virtual machine. You can now unregister the VM so that it can be moved without breaking anything. Use the command listed below with your details and refer to the picture above to see what it looks like on my test machine.
vmware-cmd -s unregister /vmfs/volumes/LUN ID/vmname
Now that the virtual machine has been unregistered it can be moved. This can be done by the mv linux command and providing a source and target locations. Use a command like the one below and again refer to the image above to a real life example.
mv /vmfs/volumes/source LUN ID/vmname /vmfs/volumes/destination LUN ID/vmname
The last step now that you have moved the virtual machine is to register it with the host. This is similar to the earlier step and I have listed a command sample below. Also the image above shows my lab example.
vmware-cmd -s register /vmfs/volumes/LUN ID/vmname/vmname.vmx
read more
