Blog: VMware

I was installing Vista from a DVD under VMware and needed to the change the boot order in the BIOS to boot from the optical drive first.  The problem was the BIOS splash screen went by so fast I couldn’t hit the F2 key in time.  I found the solution by adding a line to the VMX file of the VM:

bios.bootDelay = “boot delay in milliseconds”
 
15000 gives you 15 seconds to hit F2.  Alternatively, you can add:
 
bios.forceSetupOnce = "TRUE"
 
to automatically enter the BIOS at the next boot.

I cloned a Windows Desktop XP machine and could not access the machine via RDP.  I found that if I edited the registry with a key AllowDirectRDP=True, then I could RDP to the desktop. After researching the problem, I found that this behavior is “by design” for Virtual Desktop Manager “managed” machines. However, I do not believe the original machine was managed by the VDM, but it could have had roots in such a machine. 

Here is the relevant KB article from VMWare.  http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006042

I have been working on VMware vSphere v4 for the last few days and have found that enabling jumbo frames support is not as intuitive as the admin guide makes it sound. The process goes something like this.

1. Enable jumbo frame support on iSCSI SAN (MSA 2012i)
2. Enable jumbo frame support on switch (a Linksys business class in this case)

Both of these are very straight forward and simple to do, but here is where it gets a little tricky. vSphere v4 jumbo frame support for the iSCSI network must be enabled with the CLI. Two things must be done. You must enable jumbo frames on the vSwitch and then able it on the VMkernel port/ports. The command to enable JF enable on the vSwitch looks like this: [more]

esxcfg-vswitch -m <MTU> <vSwitch>

In my case, I wanted a 9000 MTU (9KB) for vSwitch1, so it was ‘esxcfg-vswitch -m 9000 vSwitch1’ . All good so far. Now, I needed to JF enable the VMkernel port. Admin guide says this is the command

esxcfg-vmknic -a -I <ip address> -n <netmask> -m <MTU> <port group name>

So my command looked something like this esxcfg-vmknic -a -I 192.168.155.21 -n 255.255.255.0 -m 9000 “iSCSI VMkernel”

When I ran this command, it said that this port group didn’t exist. Exactly…that is why I am running this command…to create the VMkernel port and associated port group. After MUCH troubleshooting, I finally found that the following sequence WILL work. It must have something to do with the way the port groups and their associated identifiers are created.

1. Create the VMkernel port in the vi client (GUI)
2. Remove the VMkernel port from the CLI with this command esxcfg-vmknic –d “iSCSI VMkernl”
3. Recreate the same VMkernel you just deleted with JF enabled esxcfg-vmknic -a -I 192.168.155.21 -n 255.255.255.0 -m 9000 “iSCSI VMkernel”

 

We use Platespin to do scheduled P2V migrations to provide DR for some of the physical servers at a customer site. I have been troubleshooting some issues with the scheduled protection jobs over the last week or so. The jobs had been running fine for the last couple of months. I have the jobs scheduled to do full synchronizations once per month (first of the month) and all but 2 failed this month. The problem was really strange because I could kick off the full sync and it would run fine for a long time and then all the sudden it would just stall out with a “recoverable error”. I tried all my usual steps to recover from this error…nothing worked.  I used to see this all the time after the new Barracuda was installed. For that issue, I would just add a setting to the ofxcontroller.config file on the source side to bypass the proxy. So, I started searching for another config file that might need to be changed. After tracking the traffic with wireshark, I finally decided there was no interference by the proxy. I submitted a support ticket with Platespin and the tech that working my case asked me whether I was using the “WAN optimizations”. WAN optimizations? That must be a config setting I had never seen. He explained that the problem I was having was that I was running into the 24-hour job termination window. [more]

Any Platespin job MUST complete in 24-hours or it will fail with this “Recoverable Error” message. Actually, the error is not recoverable at all…you have to abort the job and start over. PlateSpin uses WinPE for the target side pre-execution environment when doing the migration/protection jobs. WinPE requires a license if launched for more than 24-hours…platespin doesn’t have the license so the target VM will REBOOT ITSELF after 24 hrs. Hence, the recoverable error that isn’t recoverable. So, back to the WAN optimizations. To help the job finish in time, there are config values you can change in the product’s productinternal.config (for v8.0 or powerconvert.config for PowerConvert Server 7.0) configuration file, located on your Portability Suite Server host, in the following directory:   \Program Files\PlateSpin Portability Suite Server\Web\

Setting	Default	For WANs
fileTransferThreadCount	2	4 to 6
fileTransferMinCompressionLimit	0 (disabled)	65536 (64KB which is the max)
fileTransferCompressionThreadsCount	2	n/a (the 2 is ignored if compression is disabled)
fileTransferSendReceiveBufferSize	0(8192 bytes)	5242880 (5 MB is max, use formula(LINK_SPEED(Mbps)/8)*DELAY(sec)) *1024*1024 to figure out what your setting should be)

After implementing these settings, full sync jobs were completing in 25% of the time they had been taking. It’s a huge improvement.

You might also want to check out a previous post on Moving a PlateSpin Image Between Image Servers to Setup a DR Sync that discusses using local image servers at both ends to seed a server image across a WAN.

I was testing a new VMware security application (Tripwire ConfigCheck).  I downloaded it to a virtual machine and followed the instructions to run the application (a cmd file), but it didn’t run – I edited the cmd file & added a pause to see if I could tell where it stopped & it appeared to be before calling a .jar file – I did not have Java installed, so I installed Java & tried again – still failed – I read the instructions & found it supports JRE 1.5 or higher, but just in case, I installed the older version (1.5) to see if it would work – still didn’t work – finally, I opened up a command prompt & ran the cmd file from there & received an error that stated your display settings must be at 1024 X 768 for the application to run – my virtual system resolution was too low ...

When trying to use PlateSpin to seed a server image across a WAN connection for a DR site the job would fail after a certain amount of time. Come to find out the process has a time limit of 24 hours to finish or it will fail. This time limit is hard set and cannot be increased. A way around this is to use a local image server at both ends.

Update:  We've added another post that discusses WAN optimizations for Platespin that you'll want to read.

These are the basic steps you need to follow: [more]

1. Create an image server local to the source (Discover then right click in Portability Suite and choose install image server).
2. Capture the image (Drag the source to the image server).
3. Export the image (this step fixes the config.xml file point to the right location after it moves the image files).
   • The Image Operations tool is installed with the PowerConvert server and not with the Image server.
     On the PowerConvert server you have to locate the following folder: “C:\Program Files\PlateSpin PowerConvert Server\bin”
   • In that folder locate the folder: “ImageOperations” and copy it to the Image server.
   • On the Image server:
     1. Open a command prompt.
     2. Navigate to the folder “ImageOperations’ that was copied over from the PowerConvert server.
     3. Run the command “imageoperations /gather /imagepath={path of the image} /output={path that you want to place the copy of the image}” without the quotes.
     4. Once the command completes the folder specified in /output will contain the files that need to be copied to the other image server.
4. Move the files across the WAN (FTP, Physically, etc whatever method best works for the environment).
5. Create an image server local to the target ESX host.
6. Import the image into the image server local to the target.
   • The Image Operations tool is installed with the PowerConvert server and not with the Image server.
     On the PowerConvert server you have to locate the following folder: “C:\Program Files\PlateSpin PowerConvert Server\bin”
   • In that folder locate the folder: “ImageOperations” and copy it to the Image server.
   • On the new Image server:
     1. Copy the folder “ImageOperations” again to this folder from the PowerConvert server that installed this Image server.
     2. Open a command prompt.
     3. Navigate to the folder “ImageOperations” that was copied over from the PowerConvert server.
     4. Run the command “imageoperations /register /imagepath={path of files copied from old Image server}” without quotes.
     5. Once the command completes refresh the details of the Image server from within PowerConvert.
7. From the Discovered Server list expand the image server local to the target and deploy the image to target ESX host
8. Select the deployed server and choose Prepare For Synchronization
9. Setup a filed based server sync job.

Once completed the job should allow for incremental updates over a slower link without hitting the 24 hour time limit.

Today VMware released the much anticipated vSphere.  vSphere 4 is the upgrade to VI3.5 and will replace the VI name.  VMware has also restructured their licensing [more]to the following:

Small Business:

1. Essentials
2. Essentials Plus

Mid-Size & Enterprise Business:

1. Standard
2. Advanced
3. Enterprise
4. Enterprise Plus

To learn more about vSphere, or to download a free trial, visit http://www.vmware.com/products/vsphere/

I was trying to add a scsi controller to a ESX box to use in a VM running on the box. The ESX operating system recognized the PCI-based Adaptec controller (it was on the HCL) but when I added the SCSI controller to the VM, it would not boot and displayed the following error:

Unable to open SCSI device 'vmfs/devices/genscsi/vmhba3:5:0:0'(scsi3:0):Could not find the file. Failed to configure scsi3.

The problem was that there was an extra “:0” at the end of the file name. I edited the .vmx file for the virtual machine and it worked! Note that also you need to edit with wordpad (not notepad) because of the construct of the .vmx file. [more]

edit vmx file
Edit ******.vmx (wordpad, etc...)

(Before)
scsi0:1.present = "true"
scsi0:1.deviceType = "scsi-passthru"
scsi0:1.fileName = "/vmfs/devices/genscsi/vmhba3:5:0:0"
scsi0:1.allowGuestConnectionControl = "false"

(After)
scsi0:1.present = "true"
scsi0:1.deviceType = "scsi-passthru"
scsi0:1.fileName = "/vmfs/devices/genscsi/vmhba3:5:0"
scsi0:1.allowGuestConnectionControl = "false"

I was able to find a solution in the following VMware Communities thread: http://communities.vmware.com/thread/199408

Many times, through the natural evolution of a virtual machine under VMWare, the data store names are not related to the name of the virtual machine. You can "rename" these data store names by "cloning" the machine. This process will re-align the machine name and the data store names.