News

I signed up for http://twitter.com Find me at http://twitter.com/rogerlund

Or click this follow me on Twitter

PlanetVM http://planetvm.net/blog has posted a blog entry titled: What to do with your NICs

“

I was going to post on pNIC configuation, but it seems that Ed Haletky (Texiwill) has already done so,

• Blue Gears – 2 Physical NICs with VMware ESX
• Blue Gears – 3 Physical NICs with VMware ESX
• Blue Gears – 4 Physical NICs with VMware ESX
• Blue Gears – 5 Physical NICs with VMware ESX
• Blue Gears – 6 Physical NICs with VMware ESX

Why reinvent the wheel I say, thankyou Ed for an excelent series of posts

“

Thanks for the links Planetvm

Full post http://planetvm.net/blog/?p=142

Jason Boche @ http://www.boche.net/blog posted a blog post titled : hgfs registry value causes issues with Terminal Services VMs

“
originally brought this up back in October with my Tip for virtualization Citrix servers invovling user profiles post. I’m bringing it up again because this week VMware updated their knowledgebase document 1317 Windows Guest Cannot Update hgfs.dat and it’s missing a piece of key information that administrators need to be aware of. I’m not going to rehash the whole hgfs registry value again. You can read the details about that in my October post linked above. The workarounds for hgfs issues caused by VMware Tools do work, however, what’s not mentioned is that a re-installation or upgrade of VMware Tools will re-install the hgfs value back in the registry thus introducing problems again. With the amount of ESX/ESXi version upgrades coming from VMware lately, which in turn cause VMware Tools upgrades, this scenario is not going to be uncommon for anyone who is virtualizing Terminal Services or Citrix. Add to that, VMware even recently released an interim VMware Tools upgrade patch subsequent to ESX 3.5.0 Update 3 (ESXe350-200811401-T-BG).
“

Please refer to the full post http://www.boche.net/blog/?p=659

This is one of those things that is a good read, even if you are not running TS in VMware.

Thanks to Jason.

http://vmguy.com posted his weekly KB articles, below I quoted him.

“

Well, VMware can update their HCL distribution format but I can still blog on new/updated KB articles that I see customers asking the most questions on. Here’s this week’s list:

• VMware Update Manager Network Port Requirements
• Manually removing VMware Tools for Windows
• Tech Support Mode for Emergency Support
• USB devices not supported in ESX host virtual machines
• Is Running Older VMware Tools in ESX Server Guests Supported?
• Guidelines for Extending a VMFS Volume
• How do I change a forgotten root password on my ESX Server Host?
• Determining the correct version of sysprep to use
• VMware Tools Upgrade for Windows Guest Cannot Continue

“

Full post http://vmguy.com/wordpress/index.php/archives/306

Virtu-Al http://teckinfo.blogspot.com/ has a blog entry on Microsoft NLB Error when trying to Cluster Cloned VM’s Full Post : http://teckinfo.blogspot.com/2008/12/microsoft-nlb-error-when-trying-to.html

“

After configuring a few NLB VM’s recently on VMware I was intrigued when one of the people I follow on twitter was having issues with cloned NLB’s, SimonLong_ kindly agreed to document the details so I could blog about it and share his experience……

My Job; Cluster 2 VM’s using Microsoft NLB, a simple 2 minute job right? Wrong!

Why? Because my 2^nd VM was a clone of the 1^st.

Once I had my newly created VM’s configured I proceeded to fire up the NLB Manager tool and began to create my new cluster. Cluster configured…first VM added to the cluster, no problems.

Then I tried to add the 2^nd VM… I was confronted with this Error:

“No interfaces are available for installing a new cluster”

“

“

There are two ways I found to fix this;

1. The Lazy way (which I first used)
2. My Recommend solution found here (which I now use, when I realised that I was being a Cowboy).

Solution 1

• Add a second NIC to either VM that your trying to cluster
• Remove the configuration and Disable the primary NIC
• Configure the second NIC

You should now be able to add both VM’s to the NLB Cluster.

Solution 2

• On either VM enter “Device Manager”
• Expand “Network Adapters” and right mouse click on the Network adapter that you are trying to add to the NLB configuration.
• Select ‘Uninstall’. NIC has now been uninstalled.
• Next you want to re-add the network card which in turn will create a new GUID for it. Do this by right mouse clicking your servers name at the top of the ‘Device Manager’ list and select ‘Scan for hardware changes’. This will now re-detect the NIC and give it a new GUID.
• Now exit out of “Device Manager”
• Re-configure the NIC

You should now be able to add both VM’s to the NLB Cluster.

Now that I was able to add the VM into the cluster I did receive the following errors;

· Could not read configuration of interface “{DF52417D-E337-4543-A223-8D17514E02BC}”: error 0x800706ba

· Update 2 failed with error 0x800706ba

Ignore it the VM still seems to converge fine into the cluster.

“

I saw this and wanted to post it, as it is always better to know about this stuff ahead of time.

Full Post http://teckinfo.blogspot.com/2008/12/microsoft-nlb-error-when-trying-to.html

New VMware KB : VMware ESX Server 3.5, Patch ESX350-200802408-SG: Security Updates to the Python Package (1003451)

“

Summaries and Symptoms

This patch provides service console updates for the Python package. The patch fixes the following security issues:

• An integer overflow issue with the way Python’s Perl Compatible Regular Expression (PCRE) module handles certain regular expressions. If a Python application uses the PCRE module to compile and execute untrusted regular expressions, it might be possible to cause the application to crash, or to execute arbitrary code with the privileges of the Python interpreter.

  The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2006-7228 to this issue.

• A flaw in Python’s locale module where strings generated by the strxfrm() function are not properly NULL-terminated. This might result in disclosure of data stored in the memory of a Python application using the strxfrm() function.

  The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2007-2052 to this issue.

• Multiple integer overflow flaws in Python’s imageop module that can allow an attacker to cause the application to crash, enter an infinite loop, or possibly execute arbitrary code with the privileges of the Python interpreter.

  The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2007-4965 to this issue.

“

Full KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003451

http://www.yellow-bricks.com posted this blog post titled : EnableResignature and/or DisallowSnapshotLUN Full Blog Post ( site : http://www.yellow-bricks.com/2008/12/11/enableresignature-andor-disallowsnapshotlun/ )

“

I’ve spend a lot of time in the past trying to understand the settings for EnableResignature and DisallowSnapshotLUN. It had me confused and dazzled a couple of times. Every now and then I still seem to have trouble to actually understand these settings, after a quick scan through the VCDX Enterprise Study Guide by Peter I decided to write this post and I took the time to get to the bottom of it. I needed this settled once and for all, especially now I start to focus more on BC/DR.

According to the San Config Guide(vi3_35_25_san_cfg.pdf) there are three states:

1. EnableResignature=0, DisallowSnapshotLUN=1 (default)
   In this state, you cannot bring snapshots or replicas of VMFS volumes by the array into the ESX Server host regardless of whether or not the ESX Server has access to the original LUN. LUNs formatted with VMFS must have the same ID for each ESX Server host.
2. EnableResignature=1, (DisallowSnapshotLUN is not relevant)
   In this state, you can safely bring snapshots or replicas of VMFS volumes into the same servers as the original and they are automatically resignatured.
3. EnableResignature=0, DisallowSnapshotLUN=0 (This is similar to ESX Server 2.x behavior.)
   In this state, the ESX Server assumes that it sees only one replica or snapshot of a given LUN and never tries to resignature. This is ideal in a DR scenario where you are bringing a replica of a LUN to a new cluster of ESX Servers, possibly on another site that does not have access to the source LUN. In such a case, the ESX Server uses the replica as if it is the original.

“

Please read the full post on this, as it is a complicated topic.
I ran in to this, when I was unplugged and replugging in multiple sata drives into different ports on my unsupported ESXi box. The test box would see the drive but not the datatstore, therefore I had to enable Resignature to get it to see it again.

Thanks to Duncan for this.

You could think I am crazy to link this, but I thought this would be somthing to try at home, so here I am linking it.

http://www.yellow-bricks.com posted this blog post on ESX in Workstation ( site : http://www.yellow-bricks.com/2008/12/10/esx-in-workstation/ )

“

Lately I’ve been testing scripted builds of ESX hosts and several other tools like RDA. Because of this I had to reinstall my ESX hosts several times. Sometimes I actually had to completely delete them before I could start over again. You can consider this blog posting as a note to myself, this way I can do a simple search on my own blog when everything is screwed up again:

1. Create Virtual Machine, Custom
2. WS 6.5 Compatibility
3. Linux Kernel, other
4. Number of processors: 2
5. Memory: 1024
6. Bridged Networking (change to team later on)
7. LSI Logic
8. New disc, SCSI
9. 6GB, pre-allocated, single file
10. Customize hardware, remove: soundcard, usb, floppy
    set execution mode to: Intel VT-x
11. Edit .vmx and add the following:
    ethernet0.virtualDev = "e1000"
monitor_control.restrict_backdoor = "true"
12. Install ESX
13. Add VM to Team and select “LAN 1″ for networking(keep the test vm’s completely isolated)

“

I hope to try this as stated above.

Thanks Duncan.