News

http://www.mikedipetrillo.com posted a cool entry on up time and ESX, titled : Mission Critical App Nears Uptime Record

“

I just got an email from a colleague from EMEA. He showed me the picture below. The numbers alone for the uptime on the servers is huge (over 3 years). What’s even more interesting is the app – it’s ATM control software for over 100 banks and it’s in the production environment.
“
Check out the full post for the pic, Thanks Mike!

Full Post http://www.mikedipetrillo.com/mikedvirtualization/2008/12/mission-critical-app-nears-uptime-record.html

Zenoss 2.3.2 is Now Available, posted at http://blog.zenoss.com

“

The latest stable packaged version of Zenoss Core, version 2.3.2, is now available for download. Zenoss Core 2.3.2 is available from:
http://www.zenoss.com/download
and the release notes are available here:
2.3.2 Release Notes (PDF)

Installation and upgrades from earlier versions are now covered in a unified document available here:
Zenoss 2.3.2 Install Guide (zipped PDF)
OSX instructions (zipped PDF)

This is a maintenance release that addresses the following issues, by release:
Verified defects fixed in Version 2.3.2
Verified defects fixed in Version 2.3.1
Verified defects fixed in Version 2.3.0

“

Thanks Matt!

A new KB Article : Consolidating snapshots -VMware KB Article 1007849

This can cause problems, so I quoted the whole KB, this is all from VMware.com and none of this was written by my self.

“
Symptoms

When powering on a virtual machine, the following error message is displayed: The parent virtual disk has been modified since the child was created

Resolution

This error can occur under the following circumstances: The base disk of the virtual machine has been changed Running out of space on the LUN that contains the snapshot Virtual machine suffers a blue screen exception when a snapshot is taken For more details about snapshots and missing header files, see Cannot power on a virtual machine because the virtual disk cannot be opened (1004232). Before implementing the solution, ensure: You know the file names of all virtual disks associated with the virtual machine. Use the following command and record the output: # grep -i filename /vmfs/volumes/old_datastore/vmdir/*.vmx | grep -i vmdk That there is enough space on the target datastore to receive the cloned virtual disks. Use the following command to assess how much space is needed: # ls -lah /vmfs/volumes/old_datastore/vmdir/*flat.vmdk Note: This example assumes that all of the virtual disks are contained in the directory with the virtual machine configuration file (.vmx). A complete snapshot chain with matching CIDs and Parent CIDs (obtained from step 2 in the procedure). The virtual machine is in a powered off state. There is enough time to commit the snapshots. This procedure can take an extended amount of time depending on the size of the delta files. To match the CID of the snapshot to the base disk: Find out what disks the virtual machine is using. Log in to the ESX host and navigate to the directory that contains the virtual machine. Run the following command to identify which virtual disk files are being used: # grep -i filename *.vmx The output appears similar to: scsi0:0.fileName = “vm-000002.vmdk” scsi0:1.fileName = “vm_1-000002.vmdk” This virtual machine has two virtual disks. Check the CID of the base disks and compare them to the snapshots to see if they match. Run the following command to obtain the information about the virtual disk: # cat vm_1-000002.vmdk The output appears similar to: CID=929c1b7d parentCID=20d215cd createType=”vmfsSparse” parentFileNameHint=”vm_1-000001.vmdk” This indicates that the file vm_1-000001.vmdk has the CID of 20d215cd. Do this for each file in the snapshot chain until you get to the base disk. Clone the virtual disk to a new base disk. To clone the virtual disk: Run the vmkfstools -i command to copy out and consolidate the snapshots. This requires enough space for the base disk. The command ls -l *-flat.vmdk gives the size of each base disk in the current directory. Create a directory on a the target datastore if you are not cloning to the current directory: # mkdir /vmfs/volumes/new_datastore/recover Run the vmkfstools -i command to clone out the last vmdk delta disk pointer VMDK: # vmkfstools -i /vmfs/volumes/old_datastore/vmdir/vm_1-000002.vmdk /vmfs/volumes/new_datastore/recover/vm_1.vmdk The output appears similar to: Destination disk format: VMFS thick Cloning disk ‘/vmfs/volumes/old_datastore/vmdir/vm_1-000002.vmdk’… Clone: 100% done. Note: If the above process does not work, choose the next snapshot up the tree as the one you are on (or one of the higher ones) is corrupt. Detach the disk from the virtual machine using the VI Client. Attach the new disk, /vmfs/volumes/new_datastore/recover/vm-disk2.vmdk to the virtual machine. Power up the virtual machine and ensure data integrity (Event Viewer, SQL, E-mail, etc). Delete the base disk and only it’s snapshot disks. # grep -A2 parentFile vm_1-000002.vmdk | grep -v “#” The output appears similar to: parentFileNameHint=”vm_1-000001.vmdk” RW 41943040 VMFSSPARSE “vm_1-000002-delta.vmdk” This indicates that the pointer vm_1-000002.vmdk points to vm_1-000002-delta.vmdk and is using vm_1-000001.vmdk as it’s parent disk. You may run the same command on the parent pointer to determine what files it uses, until you locate them all. # rm /vmfs/volumes/old_datastore/vmdir/vm_1-000002.vmdk # rm /vmfs/volumes/old_datastore/vmdir/vm_1-000002-delta.vmdk # rm /vmfs/volumes/old_datastore/vmdir/vm_1-000001.vmdk # rm /vmfs/volumes/old_datastore/vmdir/vm_1-000001-delta.vmdk # rm /vmfs/volumes/old_datastore/vmdir/vm_1.vmdk # rm /vmfs/volumes/old_datastore/vmdir/vm_1-flat.vmdk Note: If you are going to use rm with a wildcard, echo the command first. This allows you to see which files are being targeted for erase. # echo rm *.vmdk Move the VMDKs back to the original location and re-associate the virtual machine with the new disks. To move the VMDKs back to the original location: Run the following command to clone the disk back to the original data store. # vmkfstools -i /vmfs/volumes/new_datastore/recover/vm_1.vmdk /vmfs/volumes/old_datastore/vmdir/vm_1.vmdk Detach the recovered disk from the virtual machine using the VI Client Attach the new disk in the original location, /vmfs/volumes/old_datastore/vmdir/vm-disk2.vmdk to the virtual machine. Power up the virtual machine and ensure data integrity (Event Viewer, SQL, E-mail, etc). Clean up the snapshot database. Rename the .vmsd file, remove the virtual machine from inventory, and re-add the virtual machine to clear the snapshot database. # mv vm.vmsd vm.oldvmsd

“

Full KB at VMware.com
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1007849&sliceId=1&docTypeID=DT_KB_1_1&dialogID=10302840&stateId=1%200%2010310298

http://www.vmwarewolf.com has a post titled : Deployed or cloned VM base disk will point to template’s or original VM’s vmdk if “Edit Virtual Hardware” is used to modify it

I like to link any blog posts that I think are important to business to me or others, and here is one.

“

I have heard that we are getting a few calls into support on this one, so I am rushing this new Knowledgebase article ( http://kb.vmware.com/kb/1007755 to be publicly available. It’s not quite out yet, so here’s the scoop.

• Deployed VM’s base disk will point to the original template’s vmdk if Edit Virtual Hardware is used to modify it.

• A cloned VM’s base disk will point to the original VM’s vmdk if Edit Virtual Hardware is used to modify it.

The problem is caused by a bug in hostd. When reconfiguring of the vmdk happens, hostd sets the vmdk path in the vmx to the backing disk in the config specification.

VMware is aware of the problem and expects a future release to address it. The current recommendation is to not use this (currently experimental) feature.

In the case that you already used the feature:

1. After deploying the VM, review the VM properties, specifically the virtual disk location.

2. Change the virtual disk settings manually to point to the correct file by right-clicking the VM and selecting Edit Settings…

3. In the Hardware tab, select Hard Disk 1

4. Verify the Disk File box points to the intended vmdk file. If it does not remove the Hard Disk.

5. Click Add… and use the Hardware Wizard to select the correct vmdk file.

“Thanks to http://www.vmwarewolf.com

See Full Post

http://www.vmwarewolf.com/deployed-or-cloned-vm-base-disk-will-point-to-templates-or-original-vms-vmdk-if-edit-virtual-hardware-is-used-to-modify-it/

Join the VMware Virtualization forum is going on now

http://vshow.on24.com/vshow/virtualization

http://www.mikedipetrillo.com has a very interesting article, titled : Using Perfmon in a Windows VM

“

This post is sponsored by IT Knowledge Exchange. Visit ITKnowledgeExchange.com today to ask your toughest virtualization questions and get answers from your peers.

I got a question from a customer as well as a partner recently about whether or not they should use Perfmon in a Windows VM. I emailed our internal performance team to make sure that my answer of “no – it could give you bad results” was an ok answer. Turns out they’re in the process of writing a KB article on the subject and with their permissions I’ve pasted the draft of that KB article below. NOTE: This applies to ESX 3.5 and prior. Talk to your local VMware SE to get some insight into how things are changing. Unfortunately, I can’t talk about future offerings that haven’t been publicly talked about (press, VMworld, etc) in a blog posting.

“

“

To ensure the performance numbers are accurate for a virtual machine, perform functional testing on the virtual machine. The internal workings of the virtual machine should not be known by the tester or the performance tools. Follow these guidelines:

• Use performance tools that are located outside of the virtual machine you are monitoring.
• If possible, run the performance tools on a host where the virtual machine is not running.
• For load tests, generate the load outside of the virtual machine being measured.
• Do not use benchmarking tools. Instead, measure real applications.

“
Please refer to the Full Link to read the KB Article, I have quoted just a part.

http://www.mikedipetrillo.com/mikedvirtualization/2008/12/using-perfmon-in-a-windows-vm.html

Thanks to Mike.

http://www.mikedipetrillo.com has a update on the ESXi writing via the RCLI. Titled : UPDATE: VMware RCLI now writes to ESXi Free Hosts

“

I wrote a few days ago that the ESXi 3.5 U3 update unlocked the API set. Well, this was only partially true. I was just trying out some power operations and the command line kept staring back at me blank. I went back and pinged some of the folks in engineering and low and behold I ran into bigger issues. Turns out that while fixing an API bug the API set got partially unlocked. Yes, you read that right, VMware didn’t mean to unlock the API set – at least not wholly and not yet.

So, if you went out and started madly coding some killer VirtualCenter Client replacement then hold off because I’m told the U4 update will lock things back down again. Good news is that only customers who are using the free version of ESXi have been affected. VirtualCenter and VI (Foundation, Standard, Enterprise) customers are not affected since they had rights to the API set all along.

That’s what I get for running off and blogging about new finds too quick.

“

Thanks for the update Mike. I guess that it’s back to the drawing board for those of us trying to do more with less.

Full Post http://www.mikedipetrillo.com/mikedvirtualization/2008/12/update-vmware-rcli-now-writes-to-esxi-free-hosts.html

http://blog.scottlowe.org has a blog post titled : Enabling Enhanced VMXNet

“
I’ve been doing some additional digging into jumbo frames and other networking configurations, and along the way I came across references to VMware’s Enhanced VMXNet network adapters. These were apparently introduced in VMware ESX 3.5 and are necessary in order for virtual machines to take advantage of features like TCP Segmentation Offload (TSO) or jumbo frames.

The funny thing is this: even though the Enhanced VMXNet adapters are supported on both 32-bit and 64-bit versions of Windows Server 2003 and a few different flavors of Linux, the only way to be able to specify that you want to use an Enhanced VMXNet driver is if the virtual machine is configured as 64-bit Windows Server 2003 Enterprise Edition. This is outlined in this VMware KB article describing to how enable enhanced VMXNet drivers in Windows Server 2003.

“

Please refer to the Full post for the full document.

Full Post : http://blog.scottlowe.org/2008/12/15/enabling-enhanced-vmxnet/

Thanks to the Author.

Jason posted a blog entry on ESX partitioning per my request, tiled: MEPS (my ESX partitioning scheme)

“
Here is a topic that has been discussed in great depth on the VMTN forums over the years but Roger Lund has asked me if I would post my ESX partitioning scheme. Here it is, with a bit of my reasoning which I’ve learned along the way. Enjoy!
“

Please look at Jason’s blog for the table and information below.

Full Post http://www.boche.net/blog/?p=674

Thanks Jason!