VMware Communities : Document List - VMware Infrastructure™

P2V using the same hardware

Sun, 08 Nov 2009 20:44:35 GMT

Hello everyone,

I'll start by saying that this isn't my first ESX/ESXi deployment and I'll also say that I've searched for a solution to my problem unsuccessfully but I know that there must be a guide somewhere (it's probably my search terms that are leading me the wrong direction).

As I said above, this isn't my first deployment... heck this isn't even my first P2V however this is the first time I've been asked to virtualize a Windows 2003 SBS box on to the hardware that it is currently running on. i thought that it should be fairly starightforward so I launched Converter and looked for the option to convert my physical machine into a file that I could then import to the same server hardware running ESXi server (after I had installed it hours later).

Can someone please help me find the best practices or a guide for doing this?

Thanks!

No you need some sort of virtualization platform available typically ESX/ESXi

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

Thanks for your reply weinstein5,

I have my own ESXi Server here at my site: would it be possible to use Converter to move (P2V) the SBS server to my ESXi server, wipe the box that SBS is on right now, install ESXi, and then move the VM over to the customer's newly created ESXi server?

Sounds like quite a few opportunities for massive headaches... or am I getting worried about nothing?

If you have a large enough external hard disk, or network share, you could use VMware Standalone Converter to convert the physical SBS box to a virtual machine, making the destination type for VMware Workstation. Once that's completed, you can wipe the SBS installation, install ESX and then use the Converter to convert the Workstation VM into an ESX (virtual infrastructure) VM. I can't think of any reason why this won't work.

HTH

Sam

If you have an existing ESXi host then you should have no problems. Convert directly to the ESXi host. Start the VM to test. Test thoroughly since when you wipe the SBS machine you don't have a second chance. If the physical SBS has lots of empty space on disks consider shrinking the disk as you convert. It will make hosting and moving somewhat easier. Once you are satisfied it is working. Do the deed and install ESXi. You can use converter to clone the SBS from one ESXi host to another or you can use a tool like Veeam FastSCP to copy the VM from one host to another. Whichever way you choose to P2V make absolutely sure you have a good working VM before you wipe the hardware.

Hi Sam and DSAVERT, thank you for your replies.

If I choose to go Sam's route: I have an empty Drobo with 2+ TB of free space that I
could use. Do I need to be concerned about version conflicts? (IE If
I convert to a file for VMWare Workstation 6.5.x will it work on ESXi
3.5.x or ESXi 4.x)

If I choose to go DTAVERT's route: I'm already planning to do a Cold Metal (Bare Metal) backup of the machine using Acronis and then executing the P2V conversion and all the rest. If I shrink the disk prior to the move will I have any problems resizing it when it gets back on to the orignal (now ESXi) server? I tried this a couple of years back and I ended up having a problem with Windows having a really cramped partition on the resized disk. To rephrase, as I don't know if there have been any advances in the way that VMWare handles Windows partition resizing (or if it's even possible without a third party utility IE: Partition Magic, etc)... do I need to be concerned about resizing the disk and then resizing the Windows partition?

I'm kind of surprised that there isn't a KB article or VMware authored process on doing something like this. Small Businesses typically don't have the resources (spare ESXi server) sitting idle.

VMware Converter will sort out the version issues - that's what it does I would definitely agree with DSAVERT that testing is required.

In terms of resizing partitions - you can use a boot disk called gparted to resize the VM's hard disk if need be, I actually resized one this morning. It's just a case of booting the VM from the CD and then the program itself is pretty easy. Think of VMware's resizing as changing the size of the "physical disk" and let gparted resize the logical disk.

BadTim wrote:

If I shrink the disk prior to the move will I have any problems resizing it when it gets back on to the orignal (now ESXi) server?

I'm not suggesting that you re-size just for the sake of resizing. Think about what you are doing here. You will be moving your SBS server back to the machine it was running on. The SBS server had all the disk space on the physical server. Once P2Vd it will be moved back to that server. It will now be sharing the space at least with ESXi. Unless you add more disk space it won't fit. I am only suggesting that you look at how much empty space the current physical server has. Think about what you might grow to and shrink to that level.

I'm kind of surprised that there isn't a KB article or VMware authored process on doing something like this. Small Businesses typically don't have the resources (spare ESXi server) sitting idle.

That's what Server or Workstation or Player is for. Trying to figure out what everyone has and how to overcome the differences for each OS combination would make for an overly large, complex KB article. If you do a search through the forums you will find many similar posts.

Thank you all for the assistance with solving this! I'm going to get it done tonight and I'll reply back if there are any surprises.

Cheers,

Bad Tim

Good luck.

Hello everyone,

I figured I'd post a follow-up with my methodology and observations along the way just in case it helps anyone in the future. A big thanks goes to the three people who posted replies to my initial post.

Details: Microsoft Windows 2003 SBS Standard operating as the Domain Controller, DHCP, DNS, Exchange, etc running on a Dell PowerEdge 1900 (1x 2GHz Xeon, 2GB RAM, 250GB HDD split into two partitions by SBS)

Methodology that I used:

Perfomed a 'cold metal' backup of the entire server to external storage (USB attached storage drive #1)
Disconnected the SBS server from the network. (Not sure if I needed to do this, just seemed logical)
Connected a external (USB) hard drive (USB attached storage drive #2)
Using VMWare Converter (VMWare cCenter Converter Standalone 4.0.1 build 161434 with a standard client install) I converted the running SBS machine to a Workstation v6.x VM and stored it on my USB attached storage drive (#2)
Wiped the hard drive array where SBS was installed (in my case we were doing a hard drive upgrade at the same time so I removed the two 250GB drives and installed two new 1TB drives in a RAID-1 array)
Installed and configured ESXi 4 on the RAID-1 array.
Back to VMWare Converter on my other comptuer: converted my Workstation VM and deployed on the newly installed ESXi 4 server.

Success!

Note: it took about 9 hours to clone the SBS to the VM workstation file and then another 10 hours to move it on to the ESXi server. I was using a gigabit network to move files and preform the conversions.

This document was generated from the following thread: P2V using the same hardware

Has anyone figured out VCB 1.5 custom quiescing scripts?

Fri, 30 Oct 2009 17:53:05 GMT

Has anyone played with the custom scripts for VCB 1.5 / ESX3.5U2? According to the VM Backup Guide pg 52, the pre-freeze and post-thaw scripts are now located under C:\Program Files\VMware\VMware Tools\backupScripts.d.

For pre-freeze, it says "All scripts are invoked in ascending alphabetical order with freeze as the first argument." I created a pre-freeze-script.bat and a freeze_script_1.bat under that directory. Neither worked. Also, C:\windows\pre-freeze-script.bat does not work either...

Moderator" since there doesn't seem to be a VCB community, I posted here, please move if appropriate.

Dave

Bump..... :o(

1.Make sure you installed the latest VMtools on the guest.

2. We ended up using FREEZE.bat and that seems to work.

Thanks Jason -

I renamed C:\Program Files\VMware\VMware Tools\backupScripts.d\freeze.bat to C:\Program Files\VMware\VMware Tools\backupScripts.d\FREEZE.bat

That did not work. I ran a repair to vmware tools and then it worked. The file names are case sensitive.

I used C:\Program Files\VMware\VMware Tools\backupScripts.d\THAW.bat for the thaw script.

Dave

Hello,

the problem is that scripts are launched twice. Before and after creation of snapshot.

So before snapshot is made scripts are launched in ascending alphabetical order - freeze then thaw

and after creation of snapshot in descending order - first thaw for the second time and then freeze ... as it written in backup guide

but I don't understand why it's like that ...

Here is what we have found out:

Each script in the backupscripts.d folder will get ran for EACH Argument sent. So as a example before a backup snaps it will run each script in that folder with the argument of FREEZE starting with freeze.bat in that folder. When THAW is called the same thing happens.

So if you have 3 scripts in that directory each will get ran for FREEZE and each will run for THAW.

What we did was create 1 script that will take Arguments like FREEZE, THAW, FREEZEFAIL

you can verify this by creating 2 scripts in that directory that write the current time to a file. Run a VCB job and you will see that file get written to 4 times. 2 for the FREEZE and 2 for the THAW.

Hello,

Ok I understand but now how can I stop the database before the snap and start it after snap ?

If I have two scripts, first for stopping the databases and second for starting them again, both scripts will run before and after the snap in the different order. That's no use.

database will stop and start before snapshot and start again and stop after backup.

In the previous versions of VCB it was ok.

Something like this:

if "%1%" == "freeze" goto doFreeze

goto doThaw

:doFreeze

call c:\windows\pre-freeze.bat

goto EOF

:doThaw

call c:\windows\post-thaw.bat

so you would create 1 script and have a section for Freeze and Thaw...

Ok now it works.

The argument send by vcb was the missing factor ...

Thanks.

... there is one more thing

after FREEZE section of the script is done snapshot is being made but it's not completed but finished in 95% and waiting.

It is completed in 100% but not before a thaw section is done. Shouldn't snapshot be completed when database is stopped ?

Is it normal ?

Jason -

What did you actually name the script? Is this a uppercase / lowercase thing as well?

Dave

Lowser case. Freeze.bat

Hello,

It doesn't matter. VCB will execute anything that's in ...backuScripts.d folder.

I tried a few file names before. The FREEZE.bat and THAW.bat seem to work no matter what the contents. But they execute twice. I think the " IF %1 == Freeze" statement makes it non-case sensitive. I have to test it out in my lab. On college tours with my daughter this week, so I have limited connectivity...

Dave

This is correct. Each script in that folder will run regardless of name for each operation. You will need to create 1 script that accepts Freeze and Thaw as arguments.

OK. I re-ran all of the tests again. All versions are confirmed as latest builds. I had to set the date back to allow the VM to power on because of the issues with ESX3.5U2...

A script with "if %1% == "freeze'" as the first argument - it will execute as a pre freeze script.

A script with "if %1% == "thaw"" as the first argument - it will execute as a post thaw script.

If multiple scripts exist in backupScripts.d, AND the contain the argument, they are executed in order as documented (reverse for thaw)

HOWEVER....

If the name of the file is freeze.bat, it will execute twice. If it is called thaw.bat, it will also execute twice. This has been confirmed by others.

Thanks to all for the assistance.

Dave

After further testing, I can confirm that ALL custom scripts placed in the backupScripts.d directory will execute during both the pre-freeze AND post-thaw events. This means that logic needs to be placed in the script so that the desired result is gained. If no "IF' statements are contained in the scripts, they will be executed during both the pre-freeze and post-thaw events, which could be undesireable. I also confirmed that these script names are NOT case-sensitive.

Hello,

thank you for this solution. I my situation it works only partly. If I manually stop service and than manually execute script in backupScripts.d directory script start service. If I start backup of VM via VCB than VCB send "freeze" and script stop the service but after a while job fail based on "Custom Pre-Freeze script failed". I don't know where I would looking for error

You can try checking the logs on the VM under %TEMP% and on the ESX host in the VM's directory.

Dave

************************
"There is an island of opportunity in the middle of every difficulty. Miss that, though, and you're pretty much doomed."
despair.com

I would like more accurately specify error message. During creating snapshot I get message:

Creating quiesced snapshot failed ...... script in the virtual machine exited with non-zero return code.

If you did not do a "COMPLETE" install of VMware Tools, the sync driver does not install. Run the VMware Tools installer and modify the install, then add the sync driver. If you are running ESX3.5 add the VSS driver too. See the attached screenshot.

Dave

************************
"There is an island of opportunity in the middle of every difficulty. Miss that, though, and you're pretty much doomed."
despair.com

I add VSS driver - still sthe same. It looks like VCB don't send THAW argument.

Can you post a copy of the script you are running?

I took script code from this thread. I change only directory with "execution" scripts.

if "%1%" == "freeze" goto doFreeze

goto doThaw

:doFreeze

call "c:\Program Files\VMware\VMware Tools\services_scripts\freeze.bat"

goto EOF

:doThaw

call "c:\Program Files\VMware\VMware Tools\services_scripts\thaw.bat"

Can you post " freeze.bat"

I'm not sure if the VSS driver actually NEEDS to pre-freeze / post-thaw. VSS does it differently. Assuming you are running ESX 3.5U2

Dave

************************
"There is an island of opportunity in the middle of every difficulty. Miss that, though, and you're pretty much doomed."
despair.com

You wrote that I shoul add VSS driver. I think VSS is especially for databases.

You wrote that I shoul add VSS driver . I think VSS is especially for databases.

I cant find it in the VM Backup Guide, but I think only the SYNC driver uses the scripts. I believe the VSS driver just uses VSS and the script is NOT required. The VSS driver takes care of quiescing the app and disk.

Dave

************************
"There is an island of opportunity in the middle of every difficulty. Miss that, though, and you're pretty much doomed."
despair.com

Correct, If you are using VMware's VSS provider then it will be called automatically by VCB.

Some additional information:
If the VSS driver is installed together with the recent VMware Tools the new location and behaviour is used for custum scripts. The scripts are called every time you start to use VCB.

If you only have the the sync installed the old path under <%windir%>/system32 is used.

The above isnt true for a guest VM which runs the WinXP OS. Because of a bug the old location is always used. I have to to dig for the PR where VMware describes the problem.

This drives me nuts because my Target system was first a W2k3 and later i testet with WinXP because i dont want to backup my 600GB production VM.

Here is my current script which works around for every of my problems.

Placed it under the new location ../VMware Tools/backupScripts.d
=========================================================
@echo off

if "%1%" == "" goto noParam
if "%1%" == "freeze" goto doFreeze
if "%1%" == "thaw" goto dothaw
if "%1%" == "freezeFail" goto dofreezefail
goto wrongParam

:doFreeze
call c:\windows\pre-freeze-script.bat
goto Ende

:dothaw
call c:\windows\post-thaw-script.bat
goto Ende

:dofreezefail
call c:\windows\post-freezefail-script.bat
goto Ende

:noParam
echo "Usage: %0 "
echo At least one Parameter is needed!
goto Ende

:wrongParam
echo "Usage: %0 "
echo "%1" is not a valid parameter!
goto Ende

:Ende
========================================================

Regards
Joerg

Remember if you found this or others answers helpful do not forget to award points by marking an answer as helpful or correct **

Some additional information:
If the VSS driver is installed together with the recent VMware Tools the new location and behaviour is used for custom scripts. The scripts are called every time you start to use VCB.

If you only have the the sync installed the old path under <%windir%>/ is used.

The above isnt true for a guest VM which runs the WinXP OS. Because of a bug the old location is always used. I have to to dig for the PR where VMware describes the problem.

This drives me nuts because my Target system was first a W2k3 and later i testet with WinXP because i dont want to backup my 600GB production VM.

Here is my current script which works around for every of my problems.

Placed it under the new location ../VMware Tools/backupScripts.d
=========================================================
@echo off

if "%1%" == "" goto noParam
if "%1%" == "freeze" goto doFreeze
if "%1%" == "thaw" goto dothaw
if "%1%" == "freezeFail" goto dofreezefail
goto wrongParam

:doFreeze
call c:\windows\pre-freeze-script.bat
goto Ende

:dothaw
call c:\windows\post-thaw-script.bat
goto Ende

:dofreezefail
call c:\windows\post-freezefail-script.bat
goto Ende

:noParam
echo "Usage: %0 "
echo At least one Parameter is needed!
goto Ende

:wrongParam
echo "Usage: %0 "
echo "%1" is not a valid parameter!
goto Ende

:Ende
========================================================

Regards
Joerg

Remember if you found this or others answers helpful do not forget to award points by marking an answer as helpful or correct **

Altix, thank very much!!! Your script works.

Hello,

The scripts works fine!

I'm only wondering wherefor the freezefail is? What the meaning of this argument?

Can anyone tell?

Regards,

Matthijs

HA! I just saw your question..Only two months late....

Freezefail is when the freeze process returns a non-zero code, allows you to do a little error notification or cleanup.

Dave Convery
VMware vExpert 2009
http://www.dailyhypervisor.com

Careful. We don't want to learn from this.
Bill Watterson, "Calvin and Hobbes"

This document was generated from the following thread: Has anyone figured out VCB 1.5 custom quiescing scripts?

vmware-vdiskmanager –x and avaiable space in FreeBSD virtual machine

Fri, 02 Oct 2009 06:05:26 GMT

Hello everyone.

I Had made virtual machine with guest OS – FreeBSD , after few weeks , there was not enough space on my vmdk image file . Then I used “vmware-vdiskmanager –x” to increase space in my vmdk file.
Everything gone ok , Vmware shows available space – 8 GB , but wen I try to installed Gnome GUI (which need approximately 3 GB space ) then FreeBSD shows me info that disk is full (in this moment
disk was filled by 3.6 GB ) , can someone tell me why ? What I should to do , to use expanded disk space in FreeBSD ?

Regards
Lokis

IETF X.509 Certificate Signature Collision Vulnerability

Fri, 25 Sep 2009 00:01:35 GMT

Hi all, I have the next cuestion..

How I know if this affect my VMWare ESX 3.5.0

Vulnerability Report
.indent {
margin-left: 1cm;
}
.proof {
white-space: pre;
font-family: monospace;
width: 90%;
word-wrap: break-word;
}*CVE#:*

CVE-2004-2761

Summary:

X.509 Certificates using the MD5 algorithm may be affected by
a vulnerability that can weaken security.

Details:

A vulnerability exists in X.509 certificates which, when
signed via MD5, may allow for phishing attacks. The flaw is specific to
weaknesses in the MD5 algorithm used to sign X.509 certificates. It is possible
for a potential attacker to generate multiple pairs of certificates, which share
like MD5 signatures. Typical exploration would allow the attacker to impersonate
a legitimate website.

Fix:

See references or contact the vendor for appropriate patch
information. Typically, this problem is associated with NSS libraries or FireFox
packages, among other applications.

Note: According to a paper discussing
the vulnerability, written by the discovering team, creating rogue certificates
requires prior knowledge of a pre-signed certificate. Therefore it can be
assumed that any certificate created before the announcement of the
vulnerability is effectively safe from such an attack. If the certificate was
created prior to 2009, this issue can be considered a false positive. Any
certificate signed with MD5 created in 2009 or later, however, should be
replaced by a new certificate signed with a stronger hashing
method.

Workaround:

Utilize an alternative hashing method to sign
certificates (ex: SHA-256, SHA-512)

Sample ftp script (python) for ESXI 4

Wed, 09 Sep 2009 12:30:42 GMT

The following code is an adaptation of Sean B. Palmer's nftp.py script. It was created to allow copying files to remote servers for backup purposes.
The script will itterate through a specified folder (or multiple folders) and copy it's contents to the remote ftp server.

Two files are required: xnftp.py and xnftp.conf
This script was tested on esxi4 running python 2.5

to backup a complete folder, issue the following command:
code python arcoftp.py -d ${VM_NAME} ${BACKUP_SERVER}[/code]

ESXi 3.5

Tue, 01 Sep 2009 12:01:43 GMT

we have 4 nic and we must change the ip adresse on 2 nic in a other subnet

who can i do this ?

thanks

How to expand the ESX Datastore on SAS RAID pools using CLI on IBM BCS

Mon, 31 Aug 2009 06:01:01 GMT

Ghetto Tech Preview - ghettoVCB-restore.sh - Restoring VM's backed up from ghettoVCB to ESX(i) 3.5 and 4.0+

Mon, 24 Aug 2009 06:28:38 GMT

This script performs a restore of virtual machines backed up using ghettoVCB. Tasks are performed directly within the service console of the ESX(i) server involved in the restore process. This is currently a Ghetto Tech Preview that includes basic restore functionality. Two main use cases are supported in this release:

1) Restore a VM that contains ALL VMDKs on one datastore
2) Restore a VM that has VMDKs located on multiple datastores

In all cases, restored VMs will have VMDKs that reside on the SAME datastore chosen for the restore process. Please ensure that there is sufficient space on the target datastore before attempting a restore operation. In the near future, restoration of VMs backed up using the compression feature of ghettoVCB will be implemented.

Features

Support for logging output
Support for various debugging output
Allow spaces in VM(s) backup list (not recommended and not a best practice)
Support for restore in the following formats: ZEROEDTHICK (default behavior), 2GB SPARSE, THIN or EAGERZEROEDTHICK

Requirements:

VMs backed up using ghettoVCB.sh on ESX(i) 3.5 or 4.0
SSH console access to ESX/ESXi 3.5 or 4.0 host

Setup:

1) Download ghettoVCB-restore.sh to either your ESX or ESXi
2) Change the permissions on the script to ensure it can be executed:

chmod +x ghettoVCB-restore.sh

Usage:

[root@himalaya ~]# ./ghettoVCB-restore.sh
###############################################################################
#
# ghettoVCB-restore for ESX/ESXi 3.5u2+ & 4.x+
# Author: William Lam
# http://www.engineering.ucsb.edu/~duonglt/vmware/
# Created: 08/18/2009
# Last modified: 08/25/2009
#
###############################################################################

Usage: ./ghettoVCB-restore.sh -c [VM_BACKUP_UP_LIST] -l [LOG_FILE]

OPTIONS:
   -c     VM backup list
   -l     File ot output logging

(e.g.)

Output will go to stdout
        ./ghettoVCB-restore.sh -c vms_to_restore

Output will log to /tmp/ghettoVCB-restore.log
        ./ghettoVCB-restore.sh -c vms_to_restore -l /tmp/ghettoVCB-restore.log

Standard input for script is a file that contains:
1) Full path to the backed up VM
2) Full restore path
3) Restoration disk format
Reminder: When creating this file on a non-Linux/UNIX system, one may introduce ^M characters that will cause the script to misbehave. To ensure that this does not occur, please create the file on the ESX/ESXi host.

Here is a sample of what the file should look like:

[root@himalaya ~]# cat vms_to_restore
#"<DIRECTORY or .TGZ>;<DATASTORE_TO_RESTORE_TO>;<DISK_FORMAT_TO_RESTORE>"
# DISK_FORMATS
# 1 = zeroedthick
# 2 = 2gbsparse
# 3 = thin
# 4 = eagerzeroedthick
# e.g.
# "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-18--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;2"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vMA-resize/vMA-resize-2009-08-23--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;3"

Comments in the input file is acceptable so long as the intended line is preceded by a #. The above sample VM restore file, vms_to_restore, describes the following backup:

VM to restore	Datastore to restore to	VMDK format
/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-20--1	/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage	zeroedthick
/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1	/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage	zeroedthick
/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1	/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage	2gbsparse
/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vMA-resize/vMA-resize-2009-08-23--1	/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage	thin

Sample Execution:

Execute restore with output going to stdout (restore the first two VMs listed from above):

Input file:

[root@himalaya ~]# cat vms_to_restore
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"

[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore
################## Restoring VM: VCAP  #####################
Start time: Sun Aug 23 22:31:26 PDT 2009
Restoring VM from: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-20--1"
Restoring VM to Datastore: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage" using Disk Format: "zeroedthick"
Creating VM directory: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP" ...
Copying "VCAP.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "VCAP.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-20--1/VCAP.vmdk'...
Clone: 100% done.
Registering VCAP ...
End time: Sun Aug 23 22:32:32 PDT 2009
################## Completed restore for VCAP! #####################

################## Restoring VM: sideswipe  #####################
Start time: Sun Aug 23 22:32:32 PDT 2009
Restoring VM from: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1"
Restoring VM to Datastore: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage" using Disk Format: "zeroedthick"
Creating VM directory: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/sideswipe" ...
Copying "sideswipe.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "sideswipe.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1/sideswipe.vmdk'...
Clone: 100% done.
Updating VMDK entry in "sideswipe.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1/4a31aece-e34d675a-72cf-003048d9586a/sideswipe.vmdk'...
Clone: 100% done.
Updating VMDK entry in "sideswipe.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1/4a31aece-e34d675a-72cf-003048d9586a/sideswipe_1.vmdk'...
Clone: 100% done.
Updating VMDK entry in "sideswipe.vmx" file ...
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/sideswipe/sideswipe-2009-08-20--1/sideswipe_1.vmdk'...
Clone: 100% done.
Registering sideswipe ...
End time: Sun Aug 23 22:34:46 PDT 2009
################## Completed restore for sideswipe! #####################


Start time: Sun Aug 23 22:31:26 PDT 2009
End   time: Sun Aug 23 22:34:46 PDT 2009
Duration  : 3.33 Minutes


---------------------------------------------------------------------------------------------------------------

Execute restore with output going to log file /tmp/ghettoVCB-restore.log (restore the last two VMs listed from above):

Input file:

[root@himalaya ~]# cat vms_to_restore
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;2"
"/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vMA-resize/vMA-resize-2009-08-23--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;3"

[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore -l /tmp/ghettoVCB-restore.log
Logging output to "/tmp/ghettoVCB-restore.log" ...

cat /tmp/ghettoVCB-restore.log

Display debug information level 1:

[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore -d 1

################ DEBUG MODE ##############
Virtual Machine: "VCAP"
VM_VMX: "VCAP.vmx"
VM_ORG_FOLDER: "VCAP-2009-08-20--1"
VM_FOLDER_NAME: "VCAP"
VMDK_LIST_TO_MODIFY:
scsi0:0.fileName = "VCAP.vmdk"
scsi0:0.fileName  = "VCAP-0.vmdk"
##########################################


################ DEBUG MODE ##############
Virtual Machine: "sideswipe"
VM_VMX: "sideswipe.vmx"
VM_ORG_FOLDER: "sideswipe-2009-08-20--1"
VM_FOLDER_NAME: "sideswipe"
VMDK_LIST_TO_MODIFY:
scsi0:0.fileName = "sideswipe.vmdk"
scsi0:0.fileName  = "sideswipe-0.vmdk"
scsi0:1.fileName = "/vmfs/volumes/4a31aece-e34d675a-72cf-003048d9586a/sideswipe/sideswipe.vmdk"
scsi0:1.fileName  = "sideswipe-1.vmdk"
scsi1:8.fileName = "/vmfs/volumes/4a31aece-e34d675a-72cf-003048d9586a/sideswipe/sideswipe_1.vmdk"
scsi1:8.fileName  = "sideswipe-2.vmdk"
scsi3:12.fileName = "sideswipe_1.vmdk"
scsi3:12.fileName  = "sideswipe-3.vmdk"
##########################################


Start time: Sun Aug 23 23:04:49 PDT 2009
End   time: Sun Aug 23 23:04:49 PDT 2009
Duration  : 0 Seconds

---------------------------------------------------------------------------------------------------------------

Display debug information level 2:

[root@himalaya ~]# ./ghettoVCB-restore.sh -c vms_to_restore -d 2
################## Restoring VM: stupid ass vm with spaces  #####################
==========> DEBUG MODE LEVEL 2 ENABLED <==========
Start time: Sun Aug 23 23:05:11 PDT 2009
Restoring VM from: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1"
Restoring VM to Datastore: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage" using Disk Format: "2gbsparse"
Creating VM directory: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/stupid ass vm with spaces" ...
Copying "stupid ass vm with spaces.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "stupid ass vm with spaces.vmx" file ...

SOURCE: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1/stupid ass vm with spaces.vmdk"
        ORIGINAL_VMX_LINE: -->scsi0:0.fileName = "stupid ass vm with spaces.vmdk"<--
DESTIONATION: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/stupid ass vm with spaces/stupid ass vm with spaces-0.vmdk"
        MODIFIED_VMX_LINE: -->scsi0:0.fileName  = "stupid ass vm with spaces-0.vmdk"<--
Updating VMDK entry in "stupid ass vm with spaces.vmx" file ...

SOURCE: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1/4a31aece-e34d675a-72cf-003048d9586a/stupid ass vm with spaces.vmdk"
        ORIGINAL_VMX_LINE: -->scsi0:1.fileName = "/vmfs/volumes/4a31aece-e34d675a-72cf-003048d9586a/stupid ass vm with spaces/stupid ass vm with spaces.vmdk"<--
DESTIONATION: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/stupid ass vm with spaces/stupid ass vm with spaces-1.vmdk"
        MODIFIED_VMX_LINE: -->scsi0:1.fileName  = "stupid ass vm with spaces-1.vmdk"<--
Updating VMDK entry in "stupid ass vm with spaces.vmx" file ...

SOURCE: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/stupid ass vm with spaces/stupid ass vm with spaces-2009-08-20--1/4a31aece-e34d675a-72cf-003048d9586a/stupid ass vm with spaces_1.vmdk"
        ORIGINAL_VMX_LINE: -->scsi0:2.fileName = "/vmfs/volumes/4a31aece-e34d675a-72cf-003048d9586a/stupid ass vm with spaces/stupid ass vm with spaces_1.vmdk"<--
DESTIONATION: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/stupid ass vm with spaces/stupid ass vm with spaces-2.vmdk"
        MODIFIED_VMX_LINE: -->scsi0:2.fileName  = "stupid ass vm with spaces-2.vmdk"<--
Registering stupid ass vm with spaces ...
End time: Sun Aug 23 23:05:11 PDT 2009
################## Completed restore for stupid ass vm with spaces! #####################

################## Restoring VM: vMA-resize  #####################
==========> DEBUG MODE LEVEL 2 ENABLED <==========
Start time: Sun Aug 23 23:05:11 PDT 2009
Restoring VM from: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vMA-resize/vMA-resize-2009-08-23--1"
Restoring VM to Datastore: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage" using Disk Format: "thin"
Creating VM directory: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vMA-resize" ...
Copying "vMA-resize.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "vMA-resize.vmx" file ...

SOURCE: "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vMA-resize/vMA-resize-2009-08-23--1/vMA-resize.vmdk"
        ORIGINAL_VMX_LINE: -->scsi0:0.fileName = "vMA-resize.vmdk"<--
DESTIONATION: "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vMA-resize/vMA-resize-0.vmdk"
        MODIFIED_VMX_LINE: -->scsi0:0.fileName  = "vMA-resize-0.vmdk"<--
Registering vMA-resize ...
End time: Sun Aug 23 23:05:11 PDT 2009
################## Completed restore for vMA-resize! #####################


Start time: Sun Aug 23 23:05:11 PDT 2009
End   time: Sun Aug 23 23:05:11 PDT 2009
Duration  : 0 Seconds

---------------------------------------------------------------------------------------------------------------

Change Log:

Known Issues:

Kill PID process

Mon, 17 Aug 2009 16:41:20 GMT

Stopping the virtual machine by issuing the command vmware-cmd /vmfs/volumes/<datastorename>/<vmname>/<vmname>.vmx stop. This must be done on the ESX host where the Virtual Machine is running!
If this does not work, one can issue the following command: vmware-cmd /vmfs/volumes/<datastorename>/<vmname>/<vmname>.vmx stop hard. This will try to kill the Virtual Machine instantly.
A final solution is to kill the PID (process ID). Issue the following command: ps auxfww | grep <vmname> to locate the correct PID (BTW: this cannot be done via *ESXTOP*). The first number to appear in the output is your PID. The PID can be used to terminate the process by issuing kill -9 PID.

There is a problem using PS to kill the running VM process, in that it can still leave the VM World running in the background.
Another way to stop an errant VM is to issue the commands vm-support -x to list the running VMs and their World IDs, then vm-support -X worldid (note the x is case sensitive in both commands). This then prompts the user with a couple of questions, then runs a debug stop of the VM, and creates a set of log files as well that you can forward to VMware tech support for them to check if you so desire

This document was generated from the following thread: esxRanger and ESX 3.01 and Kill Process?

Script : Listing of all datastores and extents

eric.paquay@gmail.com — Thu, 06 Aug 2009 12:45:18 GMT

This simple script is listing all datastores AND extents of your host server.
I wrote this one because sometimes our Storage team is requesting us if they could work on specifics LUN IDs, and if these are just additional extents, I had to review one-by-one all the properties of each datastores (and clusters).
I had enough, so .. voilà !

Enjoy,

Eric

#!/bin/bash

# Listing of LUNs extents

echo "List of LUNs extents :"
for filename in $(ls -la /vmfs/volumes/ |grep ^l |awk '{ print $NF }') ;
do
echo "------------------------------------------------"
echo "Datastore Name : " $(vmkfstools -P /vmfs/volumes/$filename/ -h | grep label |awk '{ print $NF }')
vmkfstools -P /vmfs/volumes/$filename/ -h | grep vmhba
done
echo "------------------------------------------------"

echo "All done !"

HP DL380 G6 Processors

Wed, 15 Jul 2009 14:51:20 GMT

Fax hardware for vm's?

Thu, 02 Jul 2009 18:29:25 GMT

Have anyone found a solution for running fax software in a vm and fax hardware on the network? Currently I can only find some ISDN pci cards and that doesn't work with a vm. I hope that a solution like AnywhereUSB for usb devices is out there just for faxing.

You could use good old COM Modems even COM ISDN Modems would help you

COM modems work great, and unlike PCI modems, when a COM modem locks, you cycle its power. When a PCI modem locks, you cycle the whole host. Not a good thing on an ESX host.

I believe GFi do an IP Based solution..

http://www.gfi.com/

GFI has IP based software, but requires a PBX or some other hardware device to manage fax calls.

It seems that there currently aren't any available product for virtualization other than traditionel serial attached solutions (modems) that can be connected by tcp/ip

I strongly suggest the IP based soluton.... better if using an ethernet connection over optical fibers, yes it requires some additional hardware but it decouples your ESX server from the phone lines (something you still have to consider with COM modems).
Think at what could happen if, during a thunderstorm, lighting hits the phone line where the modem is connected... it can blew up your ESX server!
And don't tell me the chances are low.. it has already happened..

regards,

Antonello

Another reason to use IP based solutions and decouple fax modems from the host a VM runs on is that they make moving VMs around (VMotion) a lot harder if not impossible.

Frank.

Agreed.

We are using RightFax from Captaris in this same setup. We have the Fax Work Server in a VM and the two remote board servers are stand alone physicals with the full length PCI card. We went with this option because it provided a good measure of redundancy in the critical patient care setup of pharmacy prescription transmission in both the front end and back end aspects.

We are about to try GFI Faxmaker with Eicon Diva Soft IP on an ESX 3 VM, coupled to Cisco CM.
I'll keep you posted on whether it works!!

We are in the process of getting two PowerEdge 2900's and had planned on putting in a Brooktrout fax card in each. We have RightFax to send scripts to pharmacies. If we run Rightfax on a VM, does anyone know if their is a problem with using one or both fax boards and then if a PE2900 fails everything will still works because one of the fax board resources is still available.

If you're using ESX, the fax cards will not work at all.

VMware ESX server has no support for devices such as fax cards, which is why our fax servers are remaining as physical servers.

As far as VMware Server goes, I would imagine the same issue would apply.

Here's a good post on the very question you're posing:

http://www.vmware.com/community/thread.jspa?messageID=396541&#396541

It deals with VMware Server (GSX) but it still holds. Basically, with an internal card, you're SOL.

Here's a clip from that posting that sums up the issue pretty well (thanks FP@PM!):

"The concept of a hosted virtual machine is that the vserver can be moved to any host server and work. Any device on the host must be seen by the host and must have a VMware virtual counterpart. So yes your host will see you Fax Card but a virtual server on that host will only see a serial port. So if your software on the virtual server can make use of a comm port the application will work, but if it need the drivers of the card to function then it will not."

Hi ,
I'm interested in your test , can you provide more details ?
I understand you'll install GFI Faxmaker on a VM and use a fax board on a different physical server equipped with EICON SOFT IP , am I right ?
How it worked ?
Thanks

With Eicon Diva soft IP you don't need any fax hardware what so ever!

We've got the server talking directly to the Cisco Voice Router which is connected to an ISDN line (we found it easier not to configure Call Manager) so in theroy VMotion should work.

The software was just over £400 for 2 lines and we're just about to pilot with the first 10 users. Adding more lines is just a software upgrade.

One thing worth mentioning is that Eicon Diva Soft IP looks like it comes with a USB dongle if you read some manuals but it doesn't.

This document was generated from the following thread: Fax hardware for vm's?

How to Increase the Hard Disk Size of Guest OS

Wed, 01 Jul 2009 19:55:51 GMT

The original copy of these instructions is located here --> http://vmetc.com/2007/11/07/increase-the-size-of-a-virtual-disk/

When I need to increase the size of a virtual disk (.vmdk), you use the console command vmkfstools and the Gparted LiveCD. If you did not know, Gparted is an open source Partition Magic Alternative. Available on sourceforge.net

These steps are for a Windows VM. They should work for any OS, however.

1. Download the Gparted LiveCD ISO. You will need to save it to a location you can use it to boot the VM, like uploading it using the VI client to the ESX host's data store.
2. Shutdown the virtual machine you want to resize
3. Log into the ESX Server via Putty, or however you can get to the console.
4. Use vmkfstools to increase the size of the .vmdk For example if you had a VM named "MyOS" in a folder called "myVMFS" and you wanted to increase it from 20GB to 24GB you would type (it is case sensitive):

vmkfstools -X 24g /vmfs/volumes/myVMFS/myOS.vmdk

vmkfstools -X 24576m /vmfs/volumes/myVMFS/myOS.vmdk

5. Boot the VM to the Gparted ISO
6. Once the Gparted partition editor loads, click your disk in the partition list
7. Click the Resize/Move button
8. Drag the arrow to extend the size of the partition. Be sure to work out the free space before and/or after the partition by sliding the whole partition either left or right.
9. Next click the Apply button to start the resizing process.
10. After it completes click the Close button
11. Reboot the VM without the Gparted ISO to the VM's OS.
12. You will have to wait for a chkdsk on the reboot. Then Windows will reboot again.
13. Check your new disk size in My Computer and Disk Manager!

As an alternative to steps 3 & 4, you can resize the disk using the VI client GUI by choosing to Edit Settings, then click on the HD you want to resize, type in the new size, click OK. Again, the VM has to be powered off in order to do this. Doing this still requires you to run the Gparted utility to resize a partition, otherwise you will only be able to ADD a partion using the new space. If the disk you are resizing happens to be a non-system disk, you may be able to extend the partition within Windows to use the new space.

Another way to do this is to use a "ghost" program:

1) Add a second HDD to the vm. The end size you want. In you're case 40Gb.
2) Restart VM and boot off a bootable ghost disk.
3) Use ghost program to clone disk 1 to disk 2.
4) After this is done power off VM.
5) Remove 1st HDD and set the 2nd drive to drive 1 in Virtual device node under edit VM settings.
6) Power up vm and that should be it.

The above steps were mostly taken from the discussion boards on this site and tweaked slightly for readability and spelling.

Buslogic to Lsi

Wed, 01 Jul 2009 11:57:54 GMT

Troubleshoot ESXi 3.5 installation on IBM HS20

Mon, 29 Jun 2009 12:42:16 GMT

When installing ESXi on IBM Blade HS20, after you've accepted the license agreement, you get the following message:

"Installation operation Failed!
The installation operation has encountered a fatal error:
Unable to find a supported device to write the VMWare ESX Server 3.i3.5.0 image to."

Here are some steps that can help you in order to install ESXi on this machine:

Disable IBM MegaRaid if it has been enable from the IDE Configuration in the system BIOS
Boot on ESXi installation cd-rom
Browse this procedure, and use the section Find the device's PCI IDs using the ESXi boot cd
Check if you hardware is listed in the HCL Documentation
Use Install ESXi 3.5 to an IDE drive to modify TargetFilter.py to continue the installation process

Note: If MegaRaid was enable, it means there are two disks. Be sure that the boot sequence is correctly set, to boot on the disk which has received ESXi installation.

all links in this document have been found using the VMWare community

how to create encrypted password to add users

yattongwu@hotmail.com — Fri, 26 Jun 2009 10:48:28 GMT

To generate the encrypted password, run "/sbin/grub-md5-crypt" from an ESX box

Create the user "Yattong"

/usr/sbin/useradd -p '+/sbin/grub-md5-crypt output...+' Yattong

How-to Setup Internal routing on VI3i Host with Vyatta Virtual Router

Mon, 09 Mar 2009 15:39:55 GMT

after insert a hot-plugable Disk into my proLiant , How to use max capacity

Mon, 09 Mar 2009 09:18:14 GMT

Hello Welcome to the community,

I'm a Esxi starter an have a Problem after plug in a 4th Disk into my Dell ProLiant server.

The Dell ArrayConfigurationUtility expands my existing logical Drive and set the capacity from 268 GB to 410 GB.

That's fine up to here. In the VI Client under <configuration<strorage<properties the Device shows Capacity 410 GB but on the left site

there is an extent with capacity 268 gb. If i klick on the add extent button i get an empty Form.

How can I get max capacity on the extent or is it possible to expand the extent.

Thanks

Heiko Mevius

VMware VCB frontend script for Windows / ESX

Wed, 04 Mar 2009 17:59:56 GMT

Here is my little contribution to Vmware World: a frontend for Vmware VCB that tends to make backups of virtual machines easier.

Features

Can be run from Windows (VCB framework needed) or ESX host
Connection to ESX or to Virtual Center
2 backup types: full VM (logs, config file and all Vdisks), or selected Vdisks
3 launching modes:
- interactive: ask you for each VM(s) the backup type (full or disk selection) and copy
- save: store a backup list to a file
- run: backup the list of VM(s) specified in file (log to external file)
Multiple configuration files support: eg: one config file to access a standalone ESX another to access Virtual Center
Copy disks via LAN or SAN (see vcb_tool.conf)

Installation

Windows

Extract the content of zip file to VCB framework directory
Edit the vbc_tool.conf file and change the setup section to match your need

Be carefull to edit the file with an editor that supports Linux text file (Notepad++ or Gvim for example) or use dos2unix provided in bin folder.

ESX

Copy bin/vcb_tool.sh and vcb_tool.conf files to ESX
make the script executable executable using "chmod +x vcb_tool.sh".

Usage

vcb_tool -c file.conf : config and option file (vcb_tool.conf if not specified)
vcb_tool -s batchfile : save backup scenario to batchfile
vcb_tool -r batchfile : run backup tool scenario from batchfile (think cron or windows tasks)
vcb_tool -i : launch backup tool in interactive mode (for fast and ponctual backups)

For Windows usage I provide one sample batch file for each mode.

Screenshots

Comments and suggestions are welcome.

Enjoy!

David LIMA
Infrastructure Consultant

ghettoVCB with log to file

Wed, 04 Mar 2009 17:19:35 GMT

I took the liberty to tweek lamw's awsome script

I simply add a variable called LOG_FILE_LOCATION and had most of the ECHO command to pipe in a file.

You can get the original script here ghettoVCB.sh - Free alternative for backing up VM's for ESX(i) 3.5 and 4.0+

I used the script on ESXi and had no problems with it...this dosen't mean you should'nt test it before!!!

All credits for the script should go to lamw

VMWare ESXi Hardisk Space

Wed, 04 Mar 2009 02:10:54 GMT

Hi,

I facing an issue that the hardisk space for host (Vmware ESXi) maximum = 256GB.

Is it anywhere can increase the hardisk space?? It is because my hardisk space for server around 1.2TB.

Please help..

How to deploy VM from template in ESXi (3.5U2)

Sat, 28 Feb 2009 04:43:34 GMT

Hi :

I want to deploy VM from my VM template in ESXi (3.5U2). The function that deploy VM from VM template is not in VI (ESXi include VI ).Would anyone tell me to deploy VM from template must use VIMA or using another tools.

Thank you !

ESX upgrade from 3.02 to 3.5 - Migrate fails, operation timed out

Thu, 19 Feb 2009 22:39:04 GMT

I have 3 ESX servers in cluster and a Virtual Center server.

Upgraded the virtual center server to version 2.5. Then I planned to upgrade ESX servers. Migrated all virtual machines from one of the ESX. The upgrade failed (due to noe unplug fibre cables to SAN), and I had to do a totally new install of 3.5. The install went well, and looks good in vCenter.
Have manually setup switches and vnics. But when trying to migrate virtual machines from one of the esx with version 3.02 the migrate fails with error: Operation timed out

Validating is reporting OK. I had 2 virtual machines that was powered off when re-installing. Powering one of this on is working OK.
Have also applied all Critical and Non Critical updates from Update Manager to the new installed ESX server.

Update: When doing a cold migrate, the migrate works OK, but powering the machine o, reveale that the network cable is plugged out. So I guess my neworking config that I manually have entered is not correct. Is it an easy way to export/import all network settings to my new 3.5 ESX ...? Have tried ITQ Infrastructure Client version 1.0.0.22631 with no luck

Hope this helps

http://everythinglinux.org/rsync/

since you are not well versed with GNU/Linux, you can even try this if it works

On ESX server 1

cd /vmfs/volumes

then use scp -r DATASTORE/* root@ESX_SERVER_2:/vmfs/volumes/REQUIRED_DATASTORE

by this way you will be syncing the vmfs partitions or technically speaking copying the VM's from one server to another...

Regards
Anil
Save the planet, Go Green

if you found my answer to be useful, feel free to mark it as Helpful or Correct.

This document was generated from the following thread: ESX upgrade from 3.02 to 3.5 - Migrate fails, operation timed out

Exchange Server 2007 Design Considerations

Wed, 18 Feb 2009 21:06:27 GMT

Virtualizing Microsoft Exchange Server 2007

Wed, 18 Feb 2009 20:59:49 GMT

Installing ESX 3.5 on Workstation

Wed, 18 Feb 2009 20:56:25 GMT

Hp and Vmware

Wed, 18 Feb 2009 20:53:42 GMT

Migrate ESX 2.5.X vm's to ESX 3.5.X server

ian.forbes@scalar.ca — Tue, 10 Feb 2009 20:12:18 GMT

I'm involved in a project to migrate several vm's that are currently on an ESX 2.5.X server (SAN storage) over to an ESX 3.5.X server (different SAN storage). I've read the Upgrade Guide. What I'd like to be able to do is be able to perform the migration and be in a rollback position if something goes awry.

If both of my ESX 2.5 and 3.5 servers can see each other's SANS, would I be able to do a cold migration from ESX 2.5 --> ESX 3.5? A live migration is out of the question as the ESX 2.5 server is AMD and the ESX 3.5 server is Intel. During the cold migration steps i'm presented with a screen that states:

Keep virtual machine configuration files and virtual disks in their current locations.

Move virtual machine configuration files and virtual disks

If I were to select 'Move virtual machines....' I'm assuming all the vm files (vmx, vmdk, etc) would get moved over to whatever datastore I select. So, now I've moved an ESX 2.5/vmfs2 vm over to ESX 3.5/vmfs3 datastore. Has that vm now been upgraded to vmfs3, or do I have to perform another step? Should I be able to power up that vm now?

If things don't work out would I now be able to cold migrate BACK to the ESX 2.5 server and vmfs2 datastore?

Cheers

Hi,

You will need to perform two more steps first will be to upgrade the VM's virtual hardware and second will be to upgrade the tools. You can right click on the VM in inventory and can see these options.

Thanks,

Samir

P.S : If you think this information is helpful consider rewarding points

Hi kooltechies

Thanks for the quick response. So, as far as versions of vmfs is concerned. If I'm copying a vmfs2 vm into a vmfs3 datastore, the vm will become vmfs3 format? Also, if I wanted to "rollback" would I be able to do a cold migration back to the ESX 2.5 server/vmfs2 datastore and be back to how I started?

Cheers

It's been a bit since I had to do this, but ESX 2.5 vs ESX 3.x, they introcduct VMFS3. And they also re-configured the file layout. In 2.5 there was a separate location for the VMX, nvram etc and the VMDK's were in a different location. in ESX 3.x, now all the files associated to that VM resides under /vmfs/volumes/datastore/VMname. The cleanest way I was able to do this was:

Build ESX 3.x VM shells on your ESX3 host, using the same VM information as your 2.5's with memory, the OS flavor, NICs etc.

Create those VMs with no disk attached. This will create your folder structure.

Then use Veeam or WinSCP to copy the vmdk's from your 2.5 storage to the new folder structure.

Then via VC add those vmdk's back your newly created VMs

Power them up and it will prompt you to "Upgrade the vmdk to vmfs3"

Probably worth mentioning if you "Remove from inventory" of your 2.5 VMs, I believe you can create the same name.

Assuming you have enought space to do all of this...then if you need to dump back to your 2.5, simply "Remove from inventory" and add in the 2.5 VMs again.

I know this is sort of a long way around, but it worked and the safety net is there if you have to move back because I don't believe you will be able to cold migration from 3.x to 2.5.

Hi Cruicer

Thanks for the response. Instead of using WINSCP or a copy program could I not log onto VC 2.5 and browse the ESX 2.5 datastore - open the vm folder and select/copy all of the ESX 2.5 vm files over to the ESX 3.5 datastore/newly created folder structure?

I'm just figuring if it might be easier to take advantage of the capability of VC 2.5 to browse datastores and perform "windows explorer like" copies.

I do like the fact that this way seems to leave the door open to add back to the ESX 2.5 server.

I would think so...worth a shot, what's the worst that can happen...you copy fails. Veeam is a freeware in case you were wondering...

You are going to have to take a one VM by one VM approach. since in 2.5 you stored all the VMDK's in one location (I believe again it's been awhile) you are going to want to grab the VMDK from one VM on your 2.5 host, then copy it to the \vmfs\volumes\datastorename\VMon3.xname\ Again create your shell first so you have the vmx, yada yada files. dump the vmdk's into it re-attach bing bang boom....now where is that "easy button"...

Another option - use VMware Converter to move the ESX 2.5 guests to the ESX 3.5 hosts - the converter creates the new image on the vmfs3 storage, upgrades the guest to vmfs2 format and installs the updated tools.

The only issue we've seen is that we have to go into the guest and remove the invisible NIC and reconfigure the IP addresses.

Another option is to use the Converter function in VirtualCenter 2.5 - Live conversion works in the right security environments. (We tested it but had some security updates to .Net that boke the live conversion feature.)

Veeam is freeware? Cool. I thought it would cost something. I never used it before. How would I use Veeam to copy the ESX 2.5 vm files from one SAN to another SAN? Both ESX servers can see each other's stoarge btw.

Cheers

but if you want to preserve the VM name...can't do it w/ Converter...plus I didn't think converter worked w/ 2.5...could be wrong or could have been with the beta version of converter.

We're using version 3.0.3 and you can keep the name of the guest during the conversion.

Once you get it installed, it basically resembles file manager for windows...you can drap and drop from one ESX host to the other. If you know the root password of your 3.x hosts, by default ssh is disabled...you can enable it but if you have a local account as well, veeam will also elivate your access to root level.

But how does that work if you already have a VM with that same name in the environment. Won't he get a duplicate name error? I've only used converter for P2V...so pardon my questions.

We have the ESX 2.5 guest/hosts still in VirtualCenter 2.0.x and the ESX 3.5 hosts in VirtualCenter 2.5.

Converter logs into VC2.0.x - you choose the guest, and then it logs into VC2.5 where you add a virtual machine.

So the guest is not part of the same VC environment - note for Converter 3.0.3, the guest servers being migrated must be turned off and the speed of the migration depends on both your network and SAN.

If the migration fails, you turn on the guest in VC2.0.x; if it works, you're already up and running (assuming you checked the option to start the guest upon completion.)

Keep in mind that I'd be copying to a different datastore. I don't think that having the same name would present problems - but I'm not sure. So, the consensus is that Converter 3.0.3 works fine to migrate from ESX 2.5 to ESX 3.5? Other then the nic issue it shouldn't present any problems?

What about the Converter Enterprise that comes with VC 2.5? Will that work too?

Cheers

What if I don't have VC 2.0? Will Converter log onto an ESX server?

Ok...that makes sense, two totally different VC environments...but if one only had one Virtual Center server w/ 2.x and 3.x hosts...guessing you would have to have different VM names? Datastores is not the issue, it is the your overall ESX environment if all of your hosts are managed by one Virtual Center server, then you can't have two VMs of the same exact name.

We've moved a couple of hundred guests using the process I've described and will be using it until we've completed our upgrade.

We tested the Entreprise Converter withing VC and it offers a live migration option. Unfortunately when we went to use it in production, there had been some .Net patches and we got into the .Net equivalent of dll hell. Since the cold migration process works with Converter 3.0.3, we decided to use it rather than figure out which .Net component went screwy.

Crucier - My environment would just be one VC 2.5 - but the ESX 2.5 server is not part of VC. The plan was to add it to VC 2.5, but if that might prsent problems with duplicate names then i'll keep it stand-alone.

It seems that I can run Converter and i believe Converter can log onto a VC and/or an ESX server - so, hopefully it won't be a problem. Once again I like the fact that if the upgrade is unsuccessful I should be able to power up my ESX 2.5 vm and go about my business like nothing happned.

Thanks all for the great responses.....much appreciated!

Cheers

This document was generated from the following thread: Migrate ESX 2.5.X vm's to ESX 3.5.X server

"general fault cauesd by" after copying vm's between storage

Sat, 31 Jan 2009 10:18:10 GMT

Deal all,

i'm installed and configure 4 ESXi servers and connect them to San,

So, when copying Vm,s from local storage (Datastore) to san storage (datastore) through the copying give error:

"general fault caused by file" and the Lun is corrupted and disappears between al servers.

can any one help me

Slow disk performance with Mapped Raw LUN (RDM) in ESXi 3.5.0 U3

Fri, 30 Jan 2009 20:56:04 GMT

Hi all,

So I'm seeing drastically lower sequential transfer rates in my guest operating system when I switch from the standard virtual disk to a Mapped Raw LUN. And by drastic, I mean that the transfer rate in the guest is less than half when I expect at least the equivalent if not better.

$ dd if=/dev/sdb of=/dev/null bs=1MB count=16384
16384000000 bytes (16 GB) copied, 57.9021 seconds, 283 MB/s

$ dd if=/dev/sdc of=/dev/null bs=1MB count=16384
16384000000 bytes (16 GB) copied, 125.228 seconds, 131 MB/s

The Mapped Raw LUN for Raw Device Mapping (RDM) was configured like so:

$ vmkfstools -a lsilogic -z /vmfs/devices/disks/vmhba2\:3\:0\:0 \
    /vmfs/volumes/datastore/guestvm/mydisk.vmdk
  cat >> guestvm.vmx << EOF
  scsi0:2.present = "true"
  scsi0:2.fileName = "/vmfs/volumes/datastore/guestvm/mydisk.vmdk"
  scsi0:2.deviceType = "scsi-hardDisk"
  scsi0:2.mode = "independent-persistent"
  scsi0:2.redo = ""
  EOF

Both the standard virtual disk and the Mapped Raw LUN are 2-disk RAID 1 arrays on the same channel in a PowerVault DAS attached to a PERC 6/e controller in an older PowerEdge 1950. The guest operating system is CentOS 5.2 and is running idle alone. The kernel has been passed "elevator=noop", the partitions are mounted with "defaults,noatime,nodiratime,data=journal", and the read ahead buffers have been increased ("blockdev --setra 16384"). Feel free to recommend any other IO optimizations; however, the performance difference does not appear to be due to these settings.

According to VMware and 3rd parties, I should be getting anywhere between marginal and large performance gains, not drops.

Performance Characterization of VMFS and RDM Using a SAN
VMware VMFS Vs RDM (Raw Device Mapping)

Any thoughts what might be wrong? Any improvements for a guest that will handle heavy IO?

Justin

Suggested configuration for RAID level

Wed, 28 Jan 2009 14:48:52 GMT

Hallo,

I have a server 4core, 16 GB RAM, 4 discks SAS 140 GB and a EMC SAN whith fibre channel. What is the suggested RAID level for reduncancy and performance ?

Raid 1 + (one disk advanced for other use)
Raid 10 (is really necessary for an ESX configuration ?)

others

Raid 5 (suggested for VMFS but no for simple ESX configuration)
Raid 6 (not suggested because too slow)

Thanks

For your ESX install run a pair of SAS drives locally in the server RAID1. You can then remove the other 2 drives as they are not really required.

Your EMC SAN should have a lot of redundancy features built in. If you can afford the disk use RAID 1+0 (10) for your VMFS volumes. If not use RAID5. Configure hot spare drives with both options.

As to the local storage (As opposed to the EMC SAN) I would go with RAID 1+0 for best performance. If you have an EMC SAN you will probably be storing most of your VMs on the SAN. Your local storage will be for your ESX install and perhaps a datastore for testing. As such you would want to go with a RAID that offered high performance and redundancy , even though it does so at high disk cost, because size is not you primary concern on the local storage.

As to your EMC (Clariion AX whatever) You will want to cut up LUNS based on performance needs of your VMs.

RAID 5 LUNS for your regular VMs

RAID 1+0 LUNS for SQL (Oracle or MSSQL) or Exchange VMs

Just my two cents on storage opinions vary and the right answer for you is dependent on your environment.

Agree with lightbulb. Different LUNs at different Raid level will give you the required performance and cost benefits.

Try not to run too many VMs per LUN. You should be able to get a recommendation of the max number of VMs per LUN from EMC dependant on the controllers you are running in your SAN.

Thanks to all for the reply

This document was generated from the following thread: Suggested configuration for RAID level

ghettoQuickMigrate.sh - "Quick" Migration for VM(s) running on ESXi 3.5u2+

Sun, 25 Jan 2009 09:53:49 GMT

Description:

This script utilizes VMware VIMA and the VI Perl Toolkit found in VMware VIMA.

ESXi is a formidable hypervisor solution in both licensed and free operation mode. When fully licensed in a Virtual Center cluster, ESXi's features (VMotion, HA, DRS, VCB, etc...) are indistinguishable from ESX. One feature of importance, VMotion, is used to perform live migrations of VMs that reside on shared storage from one host to another. In free operation mode however, ESXi hosts are independent of each other, in which case, useful features like VMotion become unusable.

The motivation for this script (ghettoQuickMigrate.sh) then is to provide administrators running the free version of ESXi on several hosts with the capability to perform Hyper-V-like "quick" migrations of virtual machines residing on shared storage between the hosts. VMware's VIMA virtual appliance was chosen as the central launch point for the quick migration process. ghettoQuickMigration.sh is executed from within VIMA and is compatible with ESXi 3.5u2+.

Excerpt from Hyper-V Quick Migration Document:

For a planned migration, quick migration saves the state of a running guest virtual machine (memory of original server to disk/shared storage), moves the storage connectivity from one physical server to another, and then restores the guest virtual machine onto the second server (disk/shared storage to memory on the new server). The speed of the migration depends on how much memory needs to be written to disk, and on the speed of the connectivity to storage; generally, migration takes just a few seconds.

This script follows similarly to the Hyper-V Quick Migration process with the exception of replacing the disk resource swap with a virtual machine unregister/register command on the source and target hosts respectively. The state (powered ON/Suspended/OFF) of the virtual machine designated for migration is preserved through the entire process. Online virtual machines undergoing this migration will experience a temporary pause due to the suspend and resume steps.

Like VMware's VMotion storage requirement, virtual machines in environments where this quick migration script is employed must reside on shared storage between source and target hosts. The script will provide a list of validated VMs that fit this criteria. Unlike VMware's VMotion CPU feature requirements, this script does not validate and enforce source and target CPU hardware compatibility. It is up to the user to ensure that virtual machines designated for migration are compatible with both the source and target host CPU features prior to execution of the script.

Requirements

VMs running on ESXi 3.5u2+
VMware VIMA (virtual appliance)

Usage

ghettoQuickMigrate input parameters:

Usage: ./ghettoQuickMigrate.sh [-s SOURCE_ESX] [-d DESTINATION_ESX] [-i CONFIG_FILE_TO_OUTPUT] [-c CONFIG_FILE]

OPTIONS:
   -s     Source ESXi 3.5u2+ Server IP or Hostname
   -d     Destination ESXi 3.5u2+ Server IP or Hostname
   -i     Generate a configuration file
   -c     Configuration file to be executed

(e.g.)
    Generate configuration file
        ./ghettoQuickMigrate.sh -s himalaya.primp-industries.com -d olga.resnet.ucsb.edu -i migrationConf

    Execute configuration file
        ./ghettoQuickMigrate.sh -c migrationConf

Setup

Two default VMware VI Perl Toolkit scripts require a slight modification. On initial execution, this script (ghettoQuickMigrate.sh) will duplicate and modify the necessary lines of the two scripts. This operation will require the user to enter the password for their vi-admin account. Once entered, the following two scripts will be generated and stored in /usr/lib/vmware-viperl/apps/vm.
1) my-vmregister.pl
2) my-vmcontrol.pl

Prior to starting, ensure that the VMware VIMA host is managing the appropriate ESXi 3.5u2+ hosts (those that will be utilizing the ghettoQuickMigrate.sh script). The script uses VMware VI Fast Pass authentication to connect to the ESXi server(s). The following steps will demonstrate how to set this up prior to executing the script.

1. Add ESXi hosts to VIMA managment using vifp

A password prompt for the vi-admin account and root password to the pertinent ESXi host(s) will be presented.

[vi-admin@vima-primp-industries ~]$ sudo vifp addserver olga.resnet.ucsb.edu
root@olga.resnet.ucsb.edu's password:
[vi-admin@vima-primp-industries ~]$

2. Verify that the appropriate hosts are being managed by VIMA

[vi-admin@vima-primp-industries ~]$ sudo vifp listservers
olga.resnet.ucsb.edu
himalaya.primp-industries.com

3. Lastly, prior to running any of the RCLI or VI Perl Toolkits that utilize VI Fast Pass (not all can), run the following command on the appropriate ESXi host(s).

[vi-admin@vima-primp-industries ~]$ vifpinit olga.resnet.ucsb.edu

To remove a server from VIMA, use the argument “removeserver” on the host and provide the appropriate credentials.

Now, you're ready to begin!

Example execution

1. Initial script preparation and VI Fast Pass authentication

[vi-admin@vima-primp-industries ~]$ ./ghettoQuickMigrate.sh -s olga.resnet.ucsb.edu -d kalina.resnet.ucsb.edu -i migrationConf

VI Fast Pass "vifpinit" has not been executed for either "olga.resnet.ucsb.edu" or "kalina.resnet.ucsb.edu"!
Please run the following once prior to executing this script:

        vifpinit olga.resnet.ucsb.edu
                or
        vifpinit kalina.resnet.ucsb.edu

You can check your environmental variables to ensure the following have been defined:

        env | grep VI

        VI_SERVER, VI_PROTOCOL, VI_PORTNUMBER, VI_SERVICEPATH, VI_USERNAME and VI_PASSWORD

[vi-admin@vima-primp-industries ~]$ vifpinit olga.resnet.ucsb.edu

2. Generating available virtual machine list

[vi-admin@vima-primp-industries ~]$ ./ghettoQuickMigrate.sh -s olga.resnet.ucsb.edu -d kalina.resnet.ucsb.edu -i migrationConf

Retrieving info from: olga.resnet.ucsb.edu ...
Generating virtual machine list (this may take some time)....

1)  quickMigrate-1
2)  quickMigrate-2
3)  quickMigrate-3
4)  exit

Please select VM(s) to be migrated (e.g. 1,2,3,4,5 or 1,2,3-5):

3. Confirmation of selected VM(s)

Note: The current configuration will be saved to the specified file if migration is not executed.

[vi-admin@vima-primp-industries ~]$ ./ghettoQuickMigrate.sh -s olga.resnet.ucsb.edu -d kalina.resnet.ucsb.edu -i migrationConf

Retrieving info from: olga.resnet.ucsb.edu ...
Generating virtual machine list (this may take some time)....

1)  quickMigrate-1
2)  quickMigrate-2
3)  quickMigrate-3
4)  exit

Please select VM(s) to be migrated (e.g. 1,2,3,4,5 or 1,2,3-5):
1-3

Selected VM(s):

1) quickMigrate-1
2) quickMigrate-2
3) quickMigrate-3

Please confirm the quick migration of the listed 3 VM(s) from "olga.resnet.ucsb.edu" to "kalina.resnet.ucsb.edu"? (y or n)
y

4. Execution of migration

--------------------------------------------------------------------
SOURCE :: |olga.resnet.ucsb.edu|
--------------------------------------------------------------------
quickMigrate-1                                          [          ]
quickMigrate-2                                          [  queued  ]
quickMigrate-3                                          [  queued  ]

--------------------------------------------------------------------
TARGET :: |kalina.resnet.ucsb.edu|
--------------------------------------------------------------------


====================================================================
Migrating quickMigrate-1
Status: Suspending
0/3 VM(s) migrated -- 3 VM(s) left to migrate

5. Migration progress for each VM will be updated on the screen

--------------------------------------------------------------------
SOURCE :: |olga.resnet.ucsb.edu|
--------------------------------------------------------------------
quickMigrate-2                                          [####      ]
quickMigrate-3                                          [  queued  ]

--------------------------------------------------------------------
TARGET :: |kalina.resnet.ucsb.edu|
--------------------------------------------------------------------
quickMigrate-1                                          [ migrated ]


====================================================================
Migrating quickMigrate-2
Status: Unregistering
1/3 VM(s) migrated -- 2 VM(s) left to migrate

--------------------------------------------------------------------
SOURCE :: |olga.resnet.ucsb.edu|
--------------------------------------------------------------------
quickMigrate-3                                          [  queued  ]

--------------------------------------------------------------------
TARGET :: |kalina.resnet.ucsb.edu|
--------------------------------------------------------------------
quickMigrate-1                                          [ migrated ]
quickMigrate-2                                          [########  ]


====================================================================
Migrating quickMigrate-2
Status: Resuming
2/3 VM(s) migrated -- 1 VM(s) left to migrate

6. Migration completed

--------------------------------------------------------------------
SOURCE :: |olga.resnet.ucsb.edu|
--------------------------------------------------------------------

--------------------------------------------------------------------
TARGET :: |kalina.resnet.ucsb.edu|
--------------------------------------------------------------------
quickMigrate-1                                          [ migrated ]
quickMigrate-2                                          [ migrated ]
quickMigrate-3                                          [ migrated ]


====================================================================
3/3 VM(s) migrated


Start time: Mon Jan 26 00:58:34 PST 2009
End   time: Mon Jan 26 01:00:00 PST 2009
Duration  : 1.43 Minutes

vmware esxi on dell optiplex 745 cannot be completed

Thu, 22 Jan 2009 09:19:09 GMT

i need help regarding the above topic

Can't Add Harddisk capacity 500 GB

Wed, 21 Jan 2009 06:07:07 GMT

I have VM on ESX 3.5 when i try add hard disk capacity 500 GB have error "a general system error occurred: The file is too big for the filesystem"

DualCPU w/ different CPUID & Microcode Level

Tue, 20 Jan 2009 23:16:08 GMT

Hello All,

I have a IBM HS21 XM in a BladeCenter S chassis w/ 2 Xeon Quad core
CPUs . Both cpus are the same speed but they have different CPUIDs and
Microcode levels.

ESX 3i 3.5.0 build-123629 will load and run fine w/ 1 cpu but freezes while booting if both cpus are installed.

Thanks for any help,

Scott

ghettoClone.sh - Automate cloning VM(s) for ESX/ESXi 3.5u2+ utilizing VMware VIMA: RCLI + VI Perl Toolkit

Fri, 09 Jan 2009 23:57:43 GMT

Description

This script utilizes VMware RCLI (Remote command line interface) and VMware VI Perl Toolkit found in VMware VIMA.

VMware currently provides few automated options to clone existing virtual machines that require the use of Virtual Center. That is, virtual machine cloning can be achieved through the use of VI Client and tools like “vmclone.pl” (which is part of the VI Perl Toolkit) however it is a stringent requirement that Virtual Center must be present in the virtual infrastructure to take advantage of these options. In contrast, virtual machine cloning can also be achieved manually by executing a sequence of commands through the Service Console. The benefit of this option is that Virtual Center is not needed however it quickly becomes cumbersome and impractical if a large number of virtual machines are to be cloned.

The motivation for this script ( ghettoClone.sh ) then is to provide administrators with a means to automatically clone and deploy a large subset of virtual machines into a virtual environment without requiring tedious Service Console work or Virtual Center. Furthermore, for ease of accessibility, the free VMware VIMA appliance was chosen as the central launch point for the cloning process. ghettoClone.sh is executed from within VIMA and is compatible with both ESX and ESXi 3.5u2+. It accepts a single source virtual machine along with inputted configuration parameters to tailor cloned virtual machines.

Please note that ghettoClone.sh will generate full one to one copies of the source VM (which include all VMDK files associated with it). Each cloned virtual machine will inherit all attributes pertaining to the source VM except that of the UUID bio/location ID’s and display name which will be unique across all generated clones. If you're looking to deploy Linked Clones, please refer to this script instead: http://communities.vmware.com/docs/DOC-9020

Important Note: Upon execution of the cloning process, the user will be prompted to select an available datastore where cloned virtual machines will be stored. It is up to the user to ensure that there is enough space prior to executing the cloning process. This includes but is not limited to considering swap file sizes and room for possible snapshots. The cloning process will begin immediately after confirmation of the datastore so please proceed with caution. It is recommended that the dry run process is executed before committing to a configuration.

Requirements:

VMware VIMA (virtual appliance)
ESX/ESXi 3.5u2+
my-vmregister.pl (modified version of the sample code provided by VMware) [Download at the bottom]

Usage:

ghettoClone.sh input parameters:

Usage: ./ghettoClone.sh [-h SERVER] [-v VM_TO_CLONE] [-n NAMING_CONVENTION] [-s START] [-e END] [-f NAME_FILE] -d

Please quote your params if you dare to use spaces in your naming conventions!
Ensure this script is being executed on VMware VIMA and your ESX/ESXi hosts are 3.5u2+

OPTIONS:
   -h   ESX/ESXi 3.5+ Server IP or Hostname
   -v   VM to clone (VM display name)
   -n   Clone naming convention
   -s   Starting value
   -e   Ending value
   -f   File containg naming convention for VM clones (separate each name with newline)
   -d   Dry run, produces only text output of what would be executed based on input parameters

(e.g.)
        ./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB_TEST -n "UCSB-CLONE-" -s 1 -e 10
        ./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB_TEST -n "UCSB-CLONE-" -s 1 -e 10 -d
        ./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB_TEST -f cloneInputFile.txt
        ./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB_TEST -f cloneInputFile.txt -d

Use cases

There are 2 supported use cases:

Option 1 - Deploy clones from source VM by specifying a cloned VM naming convention and amount (start/end parameter) of clones.

Option 2 - Deploy clones from source VM by specifying a subset of VM names through an input file. The amount of cloned VMs will directly correlate with the amount of display names present in the input file.

Both use cases support the “Dry Run” feature which allows the user to simulate and validate execution of the script before actual execution of the cloning process.

Prerequisite

Prior to starting, ensure that the VMware VIMA host is managing the appropriate ESX or ESXi 3.5u2+ hosts (those that will be utilizing the ghettoClone.sh script). The script uses VMware VI Fast Pass authentication to connect to the ESX/ESXi server(s). The following steps will demonstrate how to set this up prior to executing the script.

1. Add ESX/ESXi hosts to VIMA managment using vifp

A password prompt for the vi-admin account and root password to the pertinent ESX/ESXi host(s) will be presented.

[vi-admin@vima-primp-industries ~]$ sudo vifp addserver olga.resnet.ucsb.edu
root@olga.resnet.ucsb.edu's password:
[vi-admin@vima-primp-industries ~]$

2. Verify that the appropriate hosts are being managed by VIMA

[vi-admin@vima-primp-industries ~]$ sudo vifp listservers
olga.resnet.ucsb.edu
himalaya.primp-industries.com

3. Lastly, prior to running any of the RCLI or VI Perl Toolkits that utilize VI Fast Pass (not all can), run the following command on the appropriate ESX/ESXi host(s).

[vi-admin@vima-primp-industries ~]$ vifpinit olga.resnet.ucsb.edu

To remove a server from VIMA, use the argument “removeserver” on the host and provide the appropriate credentials.

Now, you're ready to begin!

Example execution

Environment

ESXi 3.5u3 host
Source VM 1 is Windows XP SP2 with 2 VMDK's (10 GB and 50 MB) named UCSB_TEST stored on local storage
Source VM 2 is Windows XP SP2 with 2 VMDK's (10 GB and 100 MB) named UCSB-ENGINEERING stored on FC LUN
Clone 3 VMs

Option 1

1. Dry run execution

./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB_TEST -n "UCSB-RESNET-CLONE-" -s 1 -e 3 -d

[vi-admin@vima-primp-industries ~]$ ./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB_TEST -n "UCSB-RESNET-CLONE-" -s 1 -e 3 -d

Retrieving info from: olga.resnet.ucsb.edu ...
Selection    Available space       Maximum Capacity     Type                 Name
1)           34.18 GB              124.75 GB            VMFS                 dlgCore-FC-LUN200.Templates
2)           244.61 GB             255.25 GB            VMFS                 olga-local-SAS.Storage
3)           91.58 GB              151.75 GB            VMFS                 dlgCore-FC-LUN202.VMstorage2
4)           29.19 GB              152.75 GB            VMFS                 dlgCore-FC-LUN203.VMstorage3
5)           53.29 GB              150.75 GB            VMFS                 dlgCore-FC-LUN201.VMstorage1
6)           exit

Please select a datastore in which the cloned virtual machines will be stored:
2
#################### DRY RUN MODE ####################
# Temp working directory: tmp_clone_2009-01-09_144356
# ESX Server to initiate clone: olga.resnet.ucsb.edu
# SOURCE VM: UCSB_TEST
# SOURCE VM PATH: [http://olga-local-SAS.Storage|http://olga-local-SAS.Storage] UCSB_TEST/UCSB_TEST.vmx
# SOURCE VM DIR: [http://olga-local-SAS.Storage|http://olga-local-SAS.Storage] UCSB_TEST
# SOURCE VM DATASTORE: [http://olga-local-SAS.Storage|http://olga-local-SAS.Storage]
# DESTINATION VM DATASTORE: [http://olga-local-SAS.Storage|http://olga-local-SAS.Storage]
# VMDK-[0]: ->UCSB_TEST_1.vmdk<-
# VMDK-[1]: ->UCSB_TEST.vmdk<-
# 2 valid VMDK(s) total
# Clone naming convention: UCSB-RESNET-CLONE-{1-3}
# 3 clone(s) to create
##################################################

Start time: Fri Jan  9 14:36:59 PST 2009
End   time: Fri Jan  9 14:37:04 PST 2009
Duration  : 5 Seconds

2. Select a datastore and start clone duplication ( note: in this instance, duplication will take place on the same datastore [local storage: source and destination]. Duplication may be faster on FC/iSCSI/NFS and dissimilar source and destination datastores.)

./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB_TEST -n "UCSB-RESNET-CLONE-" -s 1 -e 3

[vi-admin@vima-primp-industries ~]$ ./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB_TEST -n "UCSB-RESNET-CLONE-" -s 1 -e 3

Retrieving info from: olga.resnet.ucsb.edu ...
Selection    Available space       Maximum Capacity     Type                 Name
1)           34.18 GB              124.75 GB            VMFS                 dlgCore-FC-LUN200.Templates
2)           244.61 GB             255.25 GB            VMFS                 olga-local-SAS.Storage
3)           91.57 GB              151.75 GB            VMFS                 dlgCore-FC-LUN202.VMstorage2
4)           29.19 GB              152.75 GB            VMFS                 dlgCore-FC-LUN203.VMstorage3
5)           53.29 GB              150.75 GB            VMFS                 dlgCore-FC-LUN201.VMstorage1
6)           exit

Please select a datastore in which the cloned virtual machines will be stored:
2

0% Complete! - Creating clone "UCSB-RESNET-CLONE-1" - 0/3 - Time elapsed: 5 Seconds
0% Complete! - Creating clone "UCSB-RESNET-CLONE-1" - 0/3 - Time elapsed: 31 Seconds
...
0% Complete! - Creating clone "UCSB-RESNET-CLONE-1" - 0/3 - Time elapsed: 6.67 Minutes
33% Complete! - Creating clone "UCSB-RESNET-CLONE-2" - 1/3 - Time elapsed: 6.77 Minutes
...
33% Complete! - Creating clone "UCSB-RESNET-CLONE-2" - 1/3 - Time elapsed: 13.43 Minutes
66% Complete! - Creating clone "UCSB-RESNET-CLONE-3" - 2/3 - Time elapsed: 13.52 Minutes
...
66% Complete! - Creating clone "UCSB-RESNET-CLONE-3" - 2/3 - Time elapsed: 20.45 Minutes
100% Complete! - Creating clone "UCSB-RESNET-CLONE-3" - 3/3 - Time elapsed: 20.53 Minutes

Start time: Fri Jan  9 14:48:23 PST 2009
End   time: Fri Jan  9 15:08:56 PST 2009
Duration  : 20.55 Minutes

Option 2

0. Input file

[vi-admin@vima-primp-industries ~]$ cat toCloneList
ALima
AAmbrosio
MKerr

The script accepts a file listing display names of the VM clones to be created. Each needs to be separated by a newline.

1. Dry run execution

./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB-ENGINEERING -f toCloneList -d

[vi-admin@vima-primp-industries ~]$ ./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB-ENGINEERING -f toCloneList -d

Retrieving info from: olga.resnet.ucsb.edu ...
Selection    Available space       Maximum Capacity     Type                 Name
1)           52.83 GB              124.75 GB            VMFS                 dlgCore-FC-LUN200.Templates
2)           244.61 GB             255.25 GB            VMFS                 olga-local-SAS.Storage
3)           91.50 GB              151.75 GB            VMFS                 dlgCore-FC-LUN202.VMstorage2
4)           29.19 GB              152.75 GB            VMFS                 dlgCore-FC-LUN203.VMstorage3
5)           53.29 GB              150.75 GB            VMFS                 dlgCore-FC-LUN201.VMstorage1
6)           exit

Please select a datastore in which the cloned virtual machines will be stored:
3
#################### DRY RUN MODE ####################
# Temp working directory: tmp_clone_2009-01-09_151630
# ESX Server to initiate clone: olga.resnet.ucsb.edu
# SOURCE VM: UCSB-ENGINEERING
# SOURCE VM PATH: [http://dlgCore-FC-LUN200.Templates|http://dlgCore-FC-LUN200.Templates] UCSB-ENGINEERING/UCSB-ENGINEERING.vmx
# SOURCE VM DIR: [http://dlgCore-FC-LUN200.Templates|http://dlgCore-FC-LUN200.Templates] UCSB-ENGINEERING
# SOURCE VM DATASTORE: [http://dlgCore-FC-LUN200.Templates|http://dlgCore-FC-LUN200.Templates]
# DESTINATION VM DATASTORE: [http://dlgCore-FC-LUN202.VMstorage2|http://dlgCore-FC-LUN202.VMstorage2]
# VMDK-[0]: ->UCSB-ENGINEERING_1.vmdk<-
# VMDK-[1]: ->UCSB-ENGINEERING.vmdk<-
# 2 valid VMDK(s) total
# Clone naming convention: [ AAmbrosio ALima MKerr ]
# 3 clone(s) to create
##################################################

Start time: Fri Jan  9 15:16:36 PST 2009
End   time: Fri Jan  9 15:16:41 PST 2009
Duration  : 5 Seconds

2. Select datastore and start clone duplication ( note: in this instance, duplication will take place from one source FC datastore to different destination FC datastore)

./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB-ENGINEERING -f toCloneList

[vi-admin@vima-primp-industries ~]$ ./ghettoClone.sh -h olga.resnet.ucsb.edu -v UCSB-ENGINEERING -f toCloneList

Retrieving info from: olga.resnet.ucsb.edu ...
Selection    Available space       Maximum Capacity     Type                 Name
1)           52.83 GB              124.75 GB            VMFS                 dlgCore-FC-LUN200.Templates
2)           244.61 GB             255.25 GB            VMFS                 olga-local-SAS.Storage
3)           91.50 GB              151.75 GB            VMFS                 dlgCore-FC-LUN202.VMstorage2
4)           29.19 GB              152.75 GB            VMFS                 dlgCore-FC-LUN203.VMstorage3
5)           53.29 GB              150.75 GB            VMFS                 dlgCore-FC-LUN201.VMstorage1
6)           exit

Please select a datastore in which the cloned virtual machines will be stored:
3

0% Complete! - Creating clone "AAmbrosio" - 0/3 - Time elapsed: 10 Seconds
...
0% Complete! - Creating clone "AAmbrosio" - 0/3 - Time elapsed: 2.62 Minutes
33% Complete! - Creating clone "ALima" - 1/3 - Time elapsed: 2.70 Minutes
...
33% Complete! - Creating clone "ALima" - 1/3 - Time elapsed: 5.42 Minutes
66% Complete! - Creating clone "MKerr" - 2/3 - Time elapsed: 5.50 Minutes
...
66% Complete! - Creating clone "MKerr" - 2/3 - Time elapsed: 8.12 Minutes
100% Complete! - Creating clone "MKerr" - 3/3 - Time elapsed: 8.20 Minutes

Start time: Fri Jan  9 15:21:35 PST 2009
End   time: Fri Jan  9 15:29:49 PST 2009
Duration  : 8.23 Minutes

How to configure ESXi to shutdown using an APC SmartUPS (with lamw scripts)

Thu, 08 Jan 2009 12:26:26 GMT

VMware server and ESX server at a glance

Wed, 31 Dec 2008 09:13:22 GMT

VMFS Best Practices

Wed, 31 Dec 2008 06:52:14 GMT

Linked Clones script for ESXi

Wed, 17 Dec 2008 18:47:49 GMT

~ # ./ghetto-esxi-linked-clones.sh
######################################################
#
# UCSB ResNet Linked Clones Tool for ESXi
# Author: william2003[at]gmail[dot]com
#         duonglt[at]engr[dot]ucsb[dot]edu
# Created: 09/30/2008
#
######################################################

Usage: ghetto-esxi-linked-clones.sh [FULL_PATH_TO_MASTER_VMX_FILE] [VM_NAME] [START_#] [END_#]
        i.e.
                ./ghetto-esxi-linked-clones.sh /vmfs/volumes/4857f047-4e4ec6bf-a8b8-001b78361a3c/LabMaster/LabMaster.vmx LabClient- 1 200
        Output:
                LabClient-{1-200}
~ #

update child resource configuration constantly scrolling in the VI client

Tue, 09 Dec 2008 10:29:16 GMT

I cannot connect to certain hosts in my farm from virtualcenter, they show as (not responding).
Therefore I connect directly to them and in the Recent Tasks pane, i "see Update Child Resource Configuration" constantly scrolling in the tasks list.

This is what is killing the server connectivity.

Ideas?!

I have just been having exactly the same problem.

Hosts would briefly go "not responding" then return, also had problems editing VM configs, starting/stopping VMs etc.

Eventually spotted the hosts were continuously doing "Update Child Resource Configuration" many times each second.
I tried disabling DRS, but no effect.
Eventually I went through the following sequence for all hosts (fortunately only 5 of them)

Disconnect host from VC.
Remove host from VC.
service vmware-vpxa stop - this stopped the Update Child.. tasks.
service mgmt-vmware restart.
Add host back into VC.

This appears to have resolved the problem and didn't require any VMs to be restarted, but it is not something I would like to repeat too often!

Ce document a été généré à partir du fil de discussion suivant: update child resource configuration constantly scrolling in the VI client

my-vmware-cmd.sh - Custom management script for administering a large amount of virtual machines on ESX 3.x and ESXi

Sat, 06 Dec 2008 18:11:00 GMT

“my-vmware-cmd” was developed to aid in the day-to-day management of our VDI environment. This script allows specific operations to be executed across a specified set of virtual machines by utilizing a subset of available VMware service console operations. Although specific to our VDI environment, the script is versatile in that it can be extended to other virtual machine environments.

Compatiable with:
VMware ESX 3.5 Update 3
VMware ESXi 3.5 Installable Update 3
VMware ESX 3.5 Update 2
VMware ESXi 3.5 Installable Update 2
VMware ESX 3.5 Update 1
VMware ESXi 3.5 Installable Update 1
VMware ESX 3.5
VMware ESXi 3.5 Installable
VMware ESX Server 3.0.3
VMware ESX Server 3.0.2 Update 1
VMware ESX Server 3.0.2
VMware ESX Server 3.0.1
VMware ESX Server 3.0.0

The script accepts a text file that specifies virtual machine display names. In addition to running the script locally on an ESX/ESXi host, the script can be executed remotely from a centralized host such as an administrative UNIX/Linux system that has access to the ESX/ESXi hosts that the virtual machines reside on.

Usage:
        Local execution-
            my-vmware-cmd.sh [operation] [vm_input_file] <optional_arguments>
        Remote execution-
            my-vmware-cmd.sh remote [ESX_ESXI_IP_ADDRESS] [operation] [vm_input_file] <optional_arguments>

   Operations:
        start [vm_input_file]
           -- Start all VMs in the input file
        stop [vm_input_file]
           -- Stop all VMs in the input file
        suspend [vm_input_file]
           -- Suspend all VMs in the input file
        resume [vm_input_file]
           -- Resume all suspended VMs in the input file
        reset [vm_input_file]
           -- Hard reset all VMs in the input file
        shutdown [vm_input_file]
           -- Shutdown all VMs in the input file (VMware Tools required)
        reboot [vm_input_file]
           -- Reboot all VMs in the input file (VMware Tools required)
        snap [vm_input_file]
           -- Create administrative pristine snapshot of all VMs in the input file
        revert [vm_input_file]
           -- Revert all VMs in the input file back to pristine state
        purge [vm_input_file]
           -- Removes from local inventory and purges all VMs in the input file
        mac [vm_input_file] [generic|nixdhcp] [http://NETWORK (172.30.0)|http://NETWORK (172.30.0)] [HOST_COUNT_START (200)] <NIC_#> default=0
           -- Extracts MAC addresses and generates either a generic file or one compatible with *nix dhcpd
               ( e.g. my-vmware-cmd.sh mac [vm_input_file] generic )
               ( e.g. my-vmware-cmd.sh mac [vm_input_file] nixdhcp 172.30.0 200 )
        vnic [vm_input_file] <NIC_#> default=0
           -- Change vNic portgroup for all VMs in the input file
               ( e.g. my-vmware-cmd.sh vnic [vm_input_file] 3 )

The majority of operations are relatively self explanatory; this document will focus on three operations that are specific to our VDI environment.

purge
mac
vnic

These operations will be demonstrated across 32 linked clones that have been generated from the developed ghetto-esx-linked-clones.sh script.

purge

This operation unregisters and removes specified linked clones that have been generated from ghetto-esx(i)-linked-clones.sh. Linked clones must be purged prior to updating the Master VM image associated to the clones. The issue arises from the fact that linked clones are tied to the Master VMDK. Modifications to respective Master images are not possible until associated LCs are destroyed. When a “delete from disk” operation is issued in VIClient on said VMs, all attributes of the VMs will be removed including referenced VMDKs. In this circumstance, the Master VMDK in which all linked clones are referencing will be removed.

Basically, the purge operation handles linked clone deletions properly by locally unregistering specified linked clones and deleting their respective directories while leaving the Master VM image intact. One caveat to this process is that the inventory change will be reflected on Virtual Center as an orphaned VM. In this case, one just needs to issue ”remove from inventory” operations on the orphaned VMs.

Virtual Machine Input file(s):

[root@olga lamw]# cat vm_input_file_1
LinkedCLones-1
LinkedCLones-2
LinkedCLones-3
LinkedCLones-4
LinkedCLones-5
LinkedCLones-6
LinkedCLones-7
LinkedCLones-8
LinkedCLones-9
LinkedCLones-10
LinkedCLones-11
LinkedCLones-12
LinkedCLones-13
LinkedCLones-14
LinkedCLones-15
LinkedCLones-16

[root@olga lamw]# cat vm_input_file_2
LinkedCLones-17
LinkedCLones-18
LinkedCLones-19
LinkedCLones-20
LinkedCLones-21
LinkedCLones-22
LinkedCLones-23
LinkedCLones-24
LinkedCLones-25
LinkedCLones-26
LinkedCLones-27
LinkedCLones-28
LinkedCLones-29
LinkedCLones-30
LinkedCLones-31
LinkedCLones-32

Local Execution on ESX host:

Scenario: Purge Linked Clones 1-16 on local ESX Host

[root@olga lamw]# vmware -v
VMware ESX Server 3.5.0 build-123630

[root@olga lamw]# ./my-vmware-cmd.sh purge vm_input_file_1
###############################################################################
#
# UCSB ResNet Virtual Machine Managment Tool for VMware ESX 3.5+ and ESXi
# Author: william2003[at]gmail[dot]com
# Created: 07/05/2008
#
###############################################################################

Validating Virtual Machine list against VMs on ESX Server: olga.resnet.ucsb.edu

"LinkedCLones-1"
"LinkedCLones-2"
"LinkedCLones-3"
"LinkedCLones-4"
"LinkedCLones-5"
"LinkedCLones-6"
"LinkedCLones-7"
"LinkedCLones-8"
"LinkedCLones-9"
"LinkedCLones-10"
"LinkedCLones-11"
"LinkedCLones-12"
"LinkedCLones-13"
"LinkedCLones-14"
"LinkedCLones-15"
"LinkedCLones-16"

Purge the following 16 Virtual Machine(s) y/n?
y

Purging Virtual Machines in the specified list:

Purging has been confirmed for the following 16 Virtual machine(s)

Unregistering "LinkedCLones-1" VM_ID=15856 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-1
Unregistering "LinkedCLones-2" VM_ID=15872 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-2
Unregistering "LinkedCLones-3" VM_ID=15888 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-3
Unregistering "LinkedCLones-4" VM_ID=15904 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-4
Unregistering "LinkedCLones-5" VM_ID=15920 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-5
Unregistering "LinkedCLones-6" VM_ID=15936 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-6
Unregistering "LinkedCLones-7" VM_ID=15952 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-7
Unregistering "LinkedCLones-8" VM_ID=15968 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-8
Unregistering "LinkedCLones-9" VM_ID=15984 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-9
Unregistering "LinkedCLones-10" VM_ID=16000 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-10
Unregistering "LinkedCLones-11" VM_ID=16016 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-11
Unregistering "LinkedCLones-12" VM_ID=16032 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-12
Unregistering "LinkedCLones-13" VM_ID=16048 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-13
Unregistering "LinkedCLones-14" VM_ID=16064 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-14
Unregistering "LinkedCLones-15" VM_ID=16080 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-15
Unregistering "LinkedCLones-16" VM_ID=16096 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-16

Start time: Mon Dec  8 22:45:36 PST 2008
End   time: Mon Dec  8 22:46:11 PST 2008
Duration  : 35 Seconds

Completed purge for all specified Virtual Machines!

Remote Execution on non-ESX host (VIMA):

Scenario: Purge Linked Clones 17-32 from remote VIMA host

[vi-admin@vima-primp-industries ~]$ vmware -v
-bash: vmware: command not found
[vi-admin@vima-primp-industries ~]$ uname -a
Linux vima-primp-industries.com 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
[vi-admin@vima-primp-industries ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
[vi-admin@vima-primp-industries ~]$

[vi-admin@vima-primp-industries ~]$ ./my-vmware-cmd.sh remote 172.30.0.64 purge vm_input_file_2
###############################################################################
#
# UCSB ResNet Virtual Machine Managment Tool for VMware ESX 3.5+ and ESXi
# Author: william2003[at]gmail[dot]com
# Created: 07/05/2008
#
###############################################################################

Executing remote operation: "purge" on host: 172.30.0.64 with the following specified Virtual Machines:

#####################################
LinkedCLones-17
LinkedCLones-18
LinkedCLones-19
LinkedCLones-20
LinkedCLones-21
LinkedCLones-22
LinkedCLones-23
LinkedCLones-24
LinkedCLones-25
LinkedCLones-26
LinkedCLones-27
LinkedCLones-28
LinkedCLones-29
LinkedCLones-30
LinkedCLones-31
LinkedCLones-32
#####################################

OPERATION WILL BE EXECUTED IMMEDIATELY ONCE AUTHENTICATION ON REMOTE HOST SUCCEEDS!
Would you like to continue y/n?
y

Purging Virtual Machines in the specified list:

root@172.30.0.64's password:
Validating Virtual Machine list against VMs on ESX Server: olga.resnet.ucsb.edu

Unregistering "LinkedCLones-17" VM_ID=16112 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-17
Unregistering "LinkedCLones-18" VM_ID=16128 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-18
Unregistering "LinkedCLones-19" VM_ID=16144 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-19
Unregistering "LinkedCLones-20" VM_ID=16160 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-20
Unregistering "LinkedCLones-21" VM_ID=16176 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-21
Unregistering "LinkedCLones-22" VM_ID=16192 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-22
Unregistering "LinkedCLones-23" VM_ID=16208 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-23
Unregistering "LinkedCLones-24" VM_ID=16224 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-24
Unregistering "LinkedCLones-25" VM_ID=16240 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-25
Unregistering "LinkedCLones-26" VM_ID=16256 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-26
Unregistering "LinkedCLones-27" VM_ID=16272 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-27
Unregistering "LinkedCLones-28" VM_ID=16288 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-28
Unregistering "LinkedCLones-29" VM_ID=16304 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-29
Unregistering "LinkedCLones-30" VM_ID=16320 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-30
Unregistering "LinkedCLones-31" VM_ID=16336 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-31
Unregistering "LinkedCLones-32" VM_ID=16352 and removing /vmfs/volumes/dlgCore-FC-LUN200.Templates/LinkedCLones-32

Start time: Mon Dec  8 22:56:45 PST 2008
End   time: Mon Dec  8 22:57:19 PST 2008
Duration  : 34 Seconds

Completed purge for all specified Virtual Machines!

mac

This operation extracts MAC addresses associated with specified VMs and outputs a file named: "dhcp-eth#-YYYY-MM-DD-HHMMSS". This outputted file can then be used to reserve IPs on either Windows or *nix DHCP servers. There are two output options, one being a generic output relating VM names to their respective MAC address and the other a prepared file that is compatible with popular *nix dhcpd releases.

Scenario: Extract MAC Addresses for the 32 Linked Clones and output in a generic form.

Local Execution on ESXi host:

~ # vmware -v
VMware ESX Server 3i 3.5.0 build-123629
~ # ./my-vmware-cmd.sh mac vm_input_file generic
###############################################################################
#
# UCSB ResNet Virtual Machine Managment Tool for VMware ESX 3.x and ESXi
# Author: william2003[at]gmail[dot]com
# Created: 07/05/2008
#
###############################################################################

Validating Virtual Machine list against VMs on ESX Server: olga.resnet.ucsb.edu

Start time: Sat Dec 20 03:38:55 UTC 2008
End   time: Sat Dec 20 03:38:58 UTC 2008
Duration  : 3 Seconds

Completed "dhcp-eth0-2008-12-20-033855" generation file for all specified Virtual Machines!

~ #
~ # cat dhcp-eth0-2008-12-20-033855
LinkedClones1   005056b45d33
LinkedClones10  005056b45a2f
LinkedClones11  005056b450ec
LinkedClones12  005056b44182
LinkedClones13  005056b43790
LinkedClones14  005056b40346
LinkedClones15  005056b407fb
LinkedClones16  005056b42a3f
LinkedClones17  005056b44c11
LinkedClones18  005056b41f24
LinkedClones19  005056b42308
LinkedClones2   005056b4440f
LinkedClones20  005056b47039
LinkedClones21  005056b44219
LinkedClones22  005056b4699b
LinkedClones23  005056b42e7c
LinkedClones24  005056b4028b
LinkedClones25  005056b46f1c
LinkedClones26  005056b42299
LinkedClones27  005056b4225e
LinkedClones28  005056b42eed
LinkedClones29  005056b425fd
LinkedClones3   005056b42502
LinkedClones30  005056b45556
LinkedClones31  005056b477c3
LinkedClones32  005056b425df
LinkedClones4   005056b428d7
LinkedClones5   005056b4602f
LinkedClones6   005056b46e43
LinkedClones7   005056b41139
LinkedClones8   005056b4683d
LinkedClones9   005056b40566
~ #

Scenario: Create DHCP IP reservation file for the 32 Linked Clones on Network: "172.30.200", starting from Host: "50" and increment to the last VM.

Remote Execution on non ESX host (VIMA):

[vi-admin@vima-primp-industries ~]$ vmware -v
-bash: vmware: command not found
[vi-admin@vima-primp-industries ~]$ uname -a
Linux vima-primp-industries.com 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
[vi-admin@vima-primp-industries ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
[vi-admin@vima-primp-industries ~]$

[vi-admin@vima-primp-industries ~]$ ./my-vmware-cmd.sh remote 172.30.0.64 mac vm_input_file linux 172.30.200 50
###############################################################################
#
# UCSB ResNet Virtual Machine Managment Tool for VMware ESX 3.x and ESXi
# Author: william2003[at]gmail[dot]com
# Created: 07/05/2008
#
###############################################################################

Connecting to 172.30.0.64 to extract MAC Addresses:
root@172.30.0.64's password:

Completed "dhcp-2008-12-06-182712" generation file for all specified Virtual Machines!

[vi-admin@vima-primp-industries ~]$ cat dhcp-2008-12-06-182712
host LinkedClones-1        { hardware ethernet 00:50:56:b4:19:f8; fixed-address 172.30.200.50; }
host LinkedClones-2        { hardware ethernet 00:50:56:b4:3f:7b; fixed-address 172.30.200.51; }
host LinkedClones-3        { hardware ethernet 00:50:56:b4:36:af; fixed-address 172.30.200.52; }
host LinkedClones-4        { hardware ethernet 00:50:56:b4:0a:13; fixed-address 172.30.200.53; }
host LinkedClones-5        { hardware ethernet 00:50:56:b4:4c:cb; fixed-address 172.30.200.54; }
host LinkedClones-6        { hardware ethernet 00:50:56:b4:26:a9; fixed-address 172.30.200.55; }
host LinkedClones-7        { hardware ethernet 00:50:56:b4:7c:f0; fixed-address 172.30.200.56; }
host LinkedClones-8        { hardware ethernet 00:50:56:b4:31:6f; fixed-address 172.30.200.57; }
host LinkedClones-9        { hardware ethernet 00:50:56:b4:1f:75; fixed-address 172.30.200.58; }
host LinkedClones-10        { hardware ethernet 00:50:56:b4:55:9b; fixed-address 172.30.200.59; }
host LinkedClones-11        { hardware ethernet 00:50:56:b4:3b:8d; fixed-address 172.30.200.60; }
host LinkedClones-12        { hardware ethernet 00:50:56:b4:45:b8; fixed-address 172.30.200.61; }
host LinkedClones-13        { hardware ethernet 00:50:56:b4:1f:29; fixed-address 172.30.200.62; }
host LinkedClones-14        { hardware ethernet 00:50:56:b4:5d:14; fixed-address 172.30.200.63; }
host LinkedClones-15        { hardware ethernet 00:50:56:b4:03:98; fixed-address 172.30.200.64; }
host LinkedClones-16        { hardware ethernet 00:50:56:b4:4f:81; fixed-address 172.30.200.65; }
host LinkedClones-17        { hardware ethernet 00:50:56:b4:3b:43; fixed-address 172.30.200.66; }
host LinkedClones-18        { hardware ethernet 00:50:56:b4:0b:85; fixed-address 172.30.200.67; }
host LinkedClones-19        { hardware ethernet 00:50:56:b4:5e:0a; fixed-address 172.30.200.68; }
host LinkedClones-20        { hardware ethernet 00:50:56:b4:12:14; fixed-address 172.30.200.69; }
host LinkedClones-21        { hardware ethernet 00:50:56:b4:06:08; fixed-address 172.30.200.70; }
host LinkedClones-22        { hardware ethernet 00:50:56:b4:45:55; fixed-address 172.30.200.71; }
host LinkedClones-23        { hardware ethernet 00:50:56:b4:67:b0; fixed-address 172.30.200.72; }
host LinkedClones-24        { hardware ethernet 00:50:56:b4:48:12; fixed-address 172.30.200.73; }
host LinkedClones-25        { hardware ethernet 00:50:56:b4:48:c3; fixed-address 172.30.200.74; }
host LinkedClones-26        { hardware ethernet 00:50:56:b4:38:50; fixed-address 172.30.200.75; }
host LinkedClones-27        { hardware ethernet 00:50:56:b4:3f:ac; fixed-address 172.30.200.76; }
host LinkedClones-28        { hardware ethernet 00:50:56:b4:68:c9; fixed-address 172.30.200.77; }
host LinkedClones-29        { hardware ethernet 00:50:56:b4:72:a4; fixed-address 172.30.200.78; }
host LinkedClones-30        { hardware ethernet 00:50:56:b4:66:78; fixed-address 172.30.200.79; }
host LinkedClones-31        { hardware ethernet 00:50:56:b4:53:e7; fixed-address 172.30.200.80; }
host LinkedClones-32        { hardware ethernet 00:50:56:b4:2f:8b; fixed-address 172.30.200.81; }

vnic

This operation reconfigures the portgroup of the specified vNic (default eth0) for a given set of VMs. This operation supports remote execution but requires 2 SSH authentications by design. The operation also requires that the VMs in question be powered off prior to execution. Unfortunately due to the limitation of the CLI, there is currently no dynamic way of modifying the vNic portgroup while the VM is powered on.

Scenario: Change 16 of the 32 Linked Clones from "IsolatedNetwork" to "labs.90-172.30.90-23" network

1. Portgroup Selection:

[root@olga lamw]# ./my-vmware-cmd.sh vnic vm_input_file_1
###############################################################################
#
# UCSB ResNet Virtual Machine Managment Tool for VMware ESX 3.x and ESXi
# Author: william2003[at]gmail[dot]com
# Created: 07/05/2008
#
###############################################################################

Validating Virtual Machine list against VMs on ESX Server: olga.resnet.ucsb.edu
CHOICE          VLAN ID         PORTGROUP
------------------------------------------
1              4095            trunk.PassThrough
2              3252            dev.3252-172.30.52-24
3              3249            dev.3249-172.30.49-24
4              3248            dev.3248-172.30.48-24
5              333             nc.333-172.30.0-24
6              90              labs.90-172.30.90-23
7              333             SC.NC333
8              100             SC.Core100
9              3251            VMk.3251
10             0               IsolatedNetwork
11             Quit

Please select a portgroup to apply to the following Virtual Machine(s):
10

2. Portgroup configuration:

"LinkedClones-1"
"LinkedClones-2"
"LinkedClones-3"
"LinkedClones-4"
"LinkedClones-5"
"LinkedClones-6"
"LinkedClones-7"
"LinkedClones-8"
"LinkedClones-9"
"LinkedClones-10"
"LinkedClones-11"
"LinkedClones-12"
"LinkedClones-13"
"LinkedClones-14"
"LinkedClones-15"
"LinkedClones-16"

Would you like to update the Network configuration for "eth0" to apply "labs.90-172.30.90-23" to the following 16 Virtual Machine(s) y/n?
y
VM Network Portgroup update will take affect for the following 16 Virtual machine(s)

Completed configuring LinkedClones-1 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-2 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-3 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-4 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-5 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-6 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-7 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-8 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-9 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-10 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-11 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-12 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-13 from "IsolatedNetwork" to "labs.90-172.30.90-23
Completed configuring LinkedClones-14 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-15 from "IsolatedNetwork" to "labs.90-172.30.90-23"
Completed configuring LinkedClones-16 from "IsolatedNetwork" to "labs.90-172.30.90-23"

Start time: Tue Dec  9 18:37:05 PST 2008
End   time: Tue Dec  9 18:37:49 PST 2008
Duration  : 44 Seconds

Completed Network Configurations for all specified Virtual Machines!

Known Issues:

1. When running "my-vmware-cmd" on ESXi and using operation "vnic", you may see the following warning output, this can be ignored, this is due to some of the limited capabilities of the binaries in the busy box environment.

Warning Message

Please select a portgroup to apply to the following Virtual Machine(s):

bash: Network: unknown operand

Linked Clones script for ESX 3.x

Wed, 03 Dec 2008 23:05:37 GMT

This script allows users to create linked cloned virtual machine(s) from a master (or golden) virtual machine. Clones may be stored on any type of datastore (LOCAL, SAN, NFS) that is presented to the ESX host. The script is very capable in deploying a large VDI environment in a relatively short amount of time.

Compatiable with:
VMware ESX 3.5 Update 3
VMware ESX 3.5 Update 2
VMware ESX 3.5 Update 1
VMware ESX 3.5
VMware ESX Server 3.0.3
VMware ESX Server 3.0.2 Update 1
VMware ESX Server 3.0.2
VMware ESX Server 3.0.1
VMware ESX Server 3.0.0

There are currently 3 supported use cases:

1) Default
Generate linked clones located in the same datastore that houses the master (golden) virtual machine. Writes will be directed to their respective linked virtual machine delta file with reads originating from the master virtual machine.

2) Distributed Write(s) I/O
Generate linked clones evenly across available datastores of choice. Reads will originate from the specified master virtual machine while writes are directed towards their respective virtual machine delta files that have been dispersed across the specified datastores.

3) Distributed Read(s) & Write(s) I/O
Duplicate the master virtual machine on available datastores of choice and evenly generate linked clones off of each duplicated master virtual machine. Reads and writes will be isolated onto the datastore of the linked clone(s) in question. This process is similar to running multiple instances of the default behavior of the script.

Note: This linked clones script is virtual machine OS independent (i.e. it is not restricted to just Windows OS’s for VDI environment). For example, one can utilize this script to their advantage in development environments where new VMs need to be (mass) cloned quickly for testing.

DISCLAIMER - When deleting linked clones, our process requires that the admin utilizes the “my-vmware-cmd” toolset that has been developed. Under no circumstances should the “delete from disk” feature be used on a linked clone from within VIClient. This is to ensure that the master image of which clones are linked from is not terminated.

The following requirements will be validated by the script prior to execution:

Master VM is offline
Master VM does not contain any Snapshots or RDMs
Valid eth0 interface
Single VMDK disk (remove any instances in the .vmx file if you have others)

Example Execution of all 3 Use cases:

Storage Environment:

[root@olga lamw]# vmware-vim-cmd hostsvc/summary/fsvolume

Name                  		Type      SubType                         Path                              Device         Capacity       Mode
dlgCore-FC-LUN200.Templates    VmfsVolume   VMFS      /vmfs/volumes/48e1cd81-81223593-6cd8-00215acaa2b2   vmhba1:0:200:1   133949292544   readWrite
dlgCore-FC-LUN202.VMstorage2   VmfsVolume   VMFS      /vmfs/volumes/48e1a4a6-3b55e69b-02a9-001f29c948e2   vmhba1:0:202:1   162940321792   readWrite
olga-local-SAS.Storage         VmfsVolume   VMFS      /vmfs/volumes/49167992-ac31f0a5-3f9f-001f29c7a04c   vmhba0:0:0:5     274072600576   readWrite
dlgCore-FC-LUN203.VMstorage3   VmfsVolume   VMFS      /vmfs/volumes/48e16ed0-420158d5-5601-00215acaa2b2   vmhba1:0:203:1   164014063616   readWrite
dlgCore-FC-LUN201.VMstorage1   VmfsVolume   VMFS      /vmfs/volumes/48e1b819-3443974c-03c4-001f29c948e2   vmhba1:0:201:1   161866579968   readWrite

[root@olga lamw]# vdf -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/cciss/c0d0p2     7.9G  1.2G  6.3G  16% /
/dev/cciss/c0d0p1     244M   27M  204M  12% /boot
/dev/cciss/c0d0p7     2.0G   33M  1.9G   2% /home
none                  391M     0  391M   0% /dev/shm
/dev/cciss/c0d0p8     2.0G   33M  1.9G   2% /tmp
/dev/cciss/c0d0p6     4.0G  289M  3.5G   8% /var
/vmfs/devices         273G     0  273G   0% /vmfs/devices
/vmfs/volumes/48e16ed0-420158d5-5601-00215acaa2b2
                      152G  108G   44G  70% /vmfs/volumes/dlgCore-FC-LUN203.VMstorage3
/vmfs/volumes/48e1a4a6-3b55e69b-02a9-001f29c948e2
                      151G  105G   46G  69% /vmfs/volumes/dlgCore-FC-LUN202.VMstorage2
/vmfs/volumes/48e1b819-3443974c-03c4-001f29c948e2
                      150G  126G   24G  84% /vmfs/volumes/dlgCore-FC-LUN201.VMstorage1
/vmfs/volumes/48e1cd81-81223593-6cd8-00215acaa2b2
                      124G   71G   53G  57% /vmfs/volumes/dlgCore-FC-LUN200.Templates
/vmfs/volumes/49167992-ac31f0a5-3f9f-001f29c7a04c
                      255G  1.3G  253G   0% /vmfs/volumes/olga-local-SAS.Storage

Default Case

Master Virtual Machine: /vmfs/volumes/olga-local-SAS.Storage/UCSB-GAUCHOS/UCSB-GAUCHOS.vmx stored on LOCAL STORAGE
Storage Medium: LOCAL STORAGE
32 Linked Clones on the same datastore as the Master VM

~~root@olga lamw~~# ./ghetto-esx-linked-clones.sh /vmfs/volumes/olga-local-SAS.Storage/UCSB-GAUCHOS/UCSB-GAUCHOS.vmx LinkedClones- 1 32

1. Confirmation after initial execution of script:

######################################################
#
# UCSB ResNet Linked Clones Tool for ESX 3.x
# Author: william2003[at]gmail[dot]com
#         duonglt[at]engr[dot]ucsb[dot]edu
# Created: 06/26/2008
#
######################################################

Requested parameters:
        Master Virtual Machine Image: /vmfs/volumes/olga-local-SAS.Storage/UCSB-GAUCHOS/UCSB-GAUCHOS.vmx
        Requested Number of Linked Clones: 32 VMs
        Initial Master Memory: 2048 MB
        Initial Master VMDK Size: 10 GB
        Expected Storage Consumption: 84 GB

        Please verify that there is enough storage space for the requested configuration before running


Would you like to continue with these parameters y/n?
y

2. Linked Clones construction progress:

Generating Linked Clones ...
59% Complete! - Linked Clones Created: 19/32

3. Completed Linked Clones output:

Generating Linked Clones ...
100% Complete! - Linked Clones Created: 32/32


Waiting for Virtual Machine(s) to obtain their MAC addresses...

Linked clones VM MAC addresses stored at:
        lcs_created_on-2008-12-09-210343/UCSB-GAUCHOS

Start time: Tue Dec  9 21:00:06 PST 2008
End   time: Tue Dec  9 21:03:40 PST 2008
Duration  : 3.57 Minutes

Maps before Default case execution:

Maps after Default execution:

Red denotes the Master VM
Green denotes the datastore
Orange denotes the last Linked Clone created

Distributed Write(s) I/O Case

Master Virtual Machine: /vmfs/volumes/dlgCore-FC-LUN200.Templates/UCSB-RESNET/UCSB-RESNET.vmx stored on FC SAN
Storage Mediums: LOCAL STORAGE and FC SAN
64 Linked Clones distributed across 2 datastores

~~root@olga lamw~~# ./ghetto-esx-linked-clones.sh /vmfs/volumes/dlgCore-FC-LUN200.Templates/UCSB-RESNET/UCSB-RESNET.vmx LinkedClones- 1 64 dw

1. Datstore selection:

#FREE SPACE     DATASTORE(S)
1)    44G       /vmfs/volumes/dlgCore-FC-LUN203.VMstorage3
2)    44G       /vmfs/volumes/dlgCore-FC-LUN202.VMstorage2
3)    24G       /vmfs/volumes/dlgCore-FC-LUN201.VMstorage1
4)    53G       /vmfs/volumes/dlgCore-FC-LUN200.Templates
5)    253G      /vmfs/volumes/olga-local-SAS.Storage
6)    Quit

Please select datastore(s) to be used: (e.g. 1,2,3):
4,5

2. Confirmation after initial execution of script:

######################################################
#
# UCSB ResNet Linked Clones Tool for ESX 3.x
# Author: william2003[at]gmail[dot]com
#         duonglt[at]engr[dot]ucsb[dot]edu
# Created: 06/26/2008
#
######################################################

Requested parameters:
        Master Virtual Machine Image: /vmfs/volumes/dlgCore-FC-LUN200.Templates/UCSB-RESNET/UCSB-RESNET.vmx
        Requested Number of Linked Clones: 64 VMs
        Initial Master Memory: 2048 MB
        Initial Master VMDK Size: 10 GB
        Expected Storage Consumption: 167 GB

        Please verify that there is enough storage space for the requested configuration before running

Distributed Write I/O Scheme selected. Linked clones will be evenly distributed across the following datastore(s):

        /vmfs/volumes/dlgCore-FC-LUN200.Templates
        /vmfs/volumes/olga-local-SAS.Storage


Would you like to continue with these parameters y/n?
y

3. Completed Linked Clones output:

Generating Linked Clones ...
100% Complete! - Linked Clones Created: 64/64


Waiting for Virtual Machine(s) to obtain their MAC Addresses...

Linked clones VM MAC addresses stored at:
        lcs_created_on-2008-12-09-211724/UCSB-RESNET

Start time: Tue Dec  9 21:12:43 PST 2008
End   time: Tue Dec  9 21:17:19 PST 2008
Duration  : 4.60 Minutes

Maps before Default execution:

Maps after Default execution:

Red denotes the Master VM
Green denotes the two datastores
Orange denotes the last Linked Clones created

Distributed Read(s) & Write(s) I/O Case

Master Virtual Machine: /vmfs/volumes/dlgCore-FC-LUN200.Templates/UCSB-ENGINEERING/UCSB-ENGINEERING.vmx stored on FC SAN
Storage medium: FC SAN
128 Linked Clones distributed across 2 datastores

~~root@olga lamw~~# ./ghetto-esx-linked-clones.sh /vmfs/volumes/dlgCore-FC-LUN200.Templates/UCSB-ENGINEERING/UCSB-ENGINEERING.vmx LinkedClones- 1 128 drw

1. Datstore selection:

#FREE SPACE     DATASTORE(S)
1)    44G       /vmfs/volumes/dlgCore-FC-LUN203.VMstorage3
2)    43G       /vmfs/volumes/dlgCore-FC-LUN202.VMstorage2
3)    24G       /vmfs/volumes/dlgCore-FC-LUN201.VMstorage1
4)    53G       /vmfs/volumes/dlgCore-FC-LUN200.Templates
5)    253G      /vmfs/volumes/olga-local-SAS.Storage
6)    Quit

Please select datastore(s) to be used: (e.g. 1,2,3):
1,2

2. Confirmation after initial execution of script:

######################################################
#
# UCSB ResNet Linked Clones Tool for ESX 3.x
# Author: william2003[at]gmail[dot]com
#         duonglt[at]engr[dot]ucsb[dot]edu
# Created: 06/26/2008
#
######################################################

Requested parameters:
        Master Virtual Machine Image: /vmfs/volumes/dlgCore-FC-LUN200.Templates/UCSB-ENGINEERING/UCSB-ENGINEERING.vmx
        Naming convention for Linked-Cloned Master Virtual Machine: MASTER-LinkedClones-{1-2}
        Naming convention for Linked-Cloned Virtual Machines: LinkedClones-{1-128}
        Looking to create: 2 Master VMs
        Requested Number of Linked Clones: 128 VMs
        Initial Master Memory: 2048 MB
        Initial Master VMDK Size: 10 GB
        Expected Storage Consumption: 353 GB

        Please verify that there is enough storage space for the requested configuration before running

Distributed Read & Write I/O Scheme selected. Operation will duplicate master image and evenly generate
linked clones from these dupulicated images across the specified datastore(s):

        /vmfs/volumes/dlgCore-FC-LUN203.VMstorage3
        /vmfs/volumes/dlgCore-FC-LUN202.VMstorage2

        Distribution of Linked Clones per datastore: 64

MASTER-LinkedClones-1 will be stored on:
        /vmfs/volumes/dlgCore-FC-LUN203.VMstorage3
                The following VMs will be linked to "MASTER-LinkedClones-1" under this datastore:
                        LinkedClones-{1-64}

MASTER-LinkedClones-2 will be stored on:
        /vmfs/volumes/dlgCore-FC-LUN202.VMstorage2
                The following VMs will be linked to "MASTER-LinkedClones-2" under this datastore:
                        LinkedClones-{65-128}


Would you like to continue with these parameters y/n?
y

3. Creating Master image on each Datastore to distribute read(s)/write(s) Linked Clones

Creating MASTER-LinkedClones-1 on: /vmfs/volumes/dlgCore-FC-LUN203.VMstorage3
Creating MASTER-LinkedClones-2 on: /vmfs/volumes/dlgCore-FC-LUN202.VMstorage2
Initiating vmkfstools copy ...
Initiating vmkfstools copy ...
0% Complete! - Linked Clones Created: 0/128
Registering newly created MASTER-LinkedClones-1 ...

Registering newly created MASTER-LinkedClones-2 ...
2% Complete! - Linked Clones Created: 3/128

4. Completed Linked Clones output:

100% Complete! - Linked Clones Created: 128/128


Waiting for Virtual Machine(s) to obtain their MAC addresses...

Linked clones VM MAC addresses stored at:
        lcs_created_on-2008-12-09-214627/MASTER-LinkedClones-1
        lcs_created_on-2008-12-09-214627/MASTER-LinkedClones-2

Start time: Tue Dec  9 21:36:49 PST 2008
End   time: Tue Dec  9 21:46:22 PST 2008
Duration  : 9.55 Minutes

Maps before Default execution:

Maps after Default execution:

Red denotes the Master VM
Green denotes the two datastores
Purple denotes the 2 replicated Master VM in each of the datastores
Orange denotes the last Linked Clones created

Known Issues:

1. When running "ghetto-esx-linked-clones.sh" on VMware ESX 3.0.0, the "FULL_PATH_TO_MASTER_VMX_FILE" must be in the UUID format and not the human readable symlink, this was fixed in VMware ESX 3.0.1 and possibly updated in one of the 3.0.0 patchset.

Solution, use the following:

./ghetto-esx-linked-clones.sh /vmfs/volumes/4857f047-4e4ec6bf-a8b8-001b78361a3c/VM-MasterImage/VM-MasterImage.vmx LinkedClone- 1 200

Instead of

./ghetto-esx-linked-clones.sh vmfs/volumes/himalaya-local-SATA.Storage/VM-MasterImage/VM-MasterImage.vmx LinkedClone- 1 200

Please help with enabling nic teaming in ESX

Tue, 25 Nov 2008 15:36:24 GMT

Good day! I need help with configuring NIC teaming on ESX. I have ESX installed on HP server which has 2 nic cards 1GB each. This server is connected with bouth cards to CISCO 2970 switch.

On a Switch side I configured Etherchanell. On the ESX side in vSwitch properties on NIC Teaming I changed the load balancing to "Route Based on IP hash" .

The CISCO switch is connected to our main swith with 2 FC trunk connection. When I'm trying to copy some data from VM guest to other location i see on "ESXTOP" that only 1 nic is transmitting packets and another is showing me 0.

Thanks in advance for any help.

Have a great day!

How to create a root keypair files for dropbear, SSH and PuTTY inside an ESXi Server

Tue, 25 Nov 2008 05:47:43 GMT

First of all I discovered that the minimum keysize between SSH and dropbear keys are 768 BITS! Keep this
info everytime in your mind. Then creating the root keys is simpler, than creating the SSH-keys for other non-root
users. The later task tends to be tedious but not impossible. I gonna try to explain the simpler way (root SSH-Keys), if
you need advice for creating non-root SSH keys inside an ESXi box, come back to me.

Prerequisites:

You must have enabled the SSH server to login into the ESXi box. (Look here in this community forum for detailed explanation)
You must have set for security reasons a root password anyway
Do not enable lockdown mode, otherwise you can only login via the DCUI.
If you need more security restrictions you can put at the end of the ssh row a -g allowing root only to login using the identity file, not interactive anymore!

Security advice:
Keep your keys expecially the private one secure by placing it inside encrypted filesystems or limit the usage by chmod 600 for user root.

Steps:

login as root into a fresh booted ESXi box.
create an hidden directory called /.ssh with mkdir /.ssh
create the RSA dropbear key by executing /bin/dropbearkey -t rsa -f id_rsa -s 768 > id_rsa.pub
create the DSA dropbear key by executing /bin/dropbearkey -t dss -f id_dsa -s 1024 > id_dsa.pub
open the /.ssh/id_rsa.pub and /.ssh/id_dsa.pub file and delete the first and last line with your favorite editor.
NOTE: Do not change anything else, only one line beginning with ssh-rsa or ssh-dss must exist.
make a copy of your RSA private dropbear key by executing cp id_rsa id_rsa.db
make a copy of your DSA private dropbear key by executing cp id_dsa id_dsa.db
now convert the RSA dropbearkey to SSH format by executing /bin/dropbearconvert dropbear openssh id_rsa id_rsa.ssh.
now convert the DSA dropbearkey to SSH format by executing /bin/dropbearconvert dropbear openssh id_dsa id_dsa.ssh.
NOTE: This are your private SSH-Keys the public key remains the same.In other Linux/Windows Environment copy
*id_rsa.ssh to id_rsa and id_dsa.ssh to id_dsa and you can use the same RSA/DSA keys everywhere:-)# *
Copy the RSA public key to authorized_keys with cat id_rsa.pub > authorized_keys
Append the DSA public key to authorized_keys with cat id_dsa.pub >> authorized_keys
NOTE: Please check that ALL private keys MUST have chmod 600 otherwise every SSH server refuse to use it, because other chmod are INSECURE!
If you plan to use PuTTY as I do always, copy the id_rsa.pub and id_rsa.ssh to a PuTTY environment, rename id_rsa.ssh to Id_rsa and use puttygen to create an id_rsa.ppk (Putty Private Key) file
You can also copy the the id_dsa.pub and id_dsa.ssh to the same place and create an id_dsa.ppk file
Copy the newly created id_rsa.ppk and id_dsa.ppk key to your ESXi box under /.ssh
in case you need it elsewhere and forgot how to build it again
Now put all the /.ssh stuff inside the oem.tgz
Reboot and get the message file out of an ESXi box trying from another place scp -i id_rsa root@<esxi-ip>:/var/log/messages .
NOTE: If everything went fine you will never be asked to provide the root password and can now execute batch commands via cron

If you now ask what is the difference between a RSA and a DSA Key and which is better to use. Here the answer:
Its been accepted knowledge for several years now that in relation to performance only,DSA is faster for Key Generation and Signing and RSA is faster for Verification.
So use RSA for copy, because verification is faster and DSA for SSL web server application, because creating and signing is faster.

Another ESXi backup script

Sun, 23 Nov 2008 06:03:35 GMT

Applying execute permissions to scripts!

Thu, 20 Nov 2008 11:10:35 GMT

Hi,

I need some help installing naviagent on my esx box. I have tried to run the ./ESX_install.sh script with the appropriate name but keep getting permission denied. I have logged into the system using putty and have upgraded to root permissions using su, so it should work.

Anyone got suggestions why this wouldnt work? This is urgent. I have attached my .sh file

Thanks

I managed to answer my own question here.

When you need to execute a script you need to applying execute permissions to all files to be run by the script.

To do this, run chmod 755 "filename" to apply execute permissions.

This document was generated from the following thread: Running ./ESX_Install.sh gives Permission Denied

ghettoVCB.sh - Free alternative for backing up VM's for ESX(i) 3.5 and 4.0+

Tue, 18 Nov 2008 03:04:10 GMT

Description:

This script performs backups of virtual machines residing on ESX(i) 3.5/4.0+ servers using methodology similar to VMware's VCB tool. The script takes snapshots of live virtual machines, backs up the master VMDK(s) and then upon completion, deletes the snapshot until the next backup. The only caveat is that it utilizes resources available to the Service Console of the ESX server running the backups as opposed to following the traditional method of offloading virtual machine backups through a VCB proxy.

This script has been tested on ESX 3.5/4.0 and ESXi 3.5/4.0 and supports the following backup mediums: LOCAL STORAGE, SAN and NFS. The script is non-interactive and can be setup to run via crontab. Currently, this script accepts a text file that lists the display names of virtual machine(s) that are to be backed up. Additionally, one can specify a folder containing configuration files on a per VM basis for granular control over backup policies.

Additionally, for ESX environments that don't have persistent NFS datastores designated for backups, the script offers the ability to automatically connect the ESX server to a NFS exported folder and then upon backup completion, disconnect it from the ESX server. The connection is established by creating an NFS datastore link which enables monolithic (or thick) VMDK backups as opposed to using the usual *nix mount command which necessitates breaking VMDK files into the 2gbsparse format for backup. Enabling this mode is self-explanatory and will evidently be so when editing the script (Note: VM_BACKUP_VOLUME variable is ignored if ENABLE_NON_PERSISTENT_NFS=1 ).

In its current configuration, the script will allow up to 3 unique backups of the Virtual Machine before it will overwrite the previous backups; this however, can be modified to fit procedures if need be. Please be diligent in running the script in a test or staging environment before using it on production live Virtual Machines; this script functions well within our environment but there is a chance that it may not fit well into other environments.

Features

Support for multiple VMDK disk(s) backup per VM
Only valid VMDK(s) presented to the VM will be backed up
Online back up of VM(s)
Ability to shutdown guestOS and initiate backup process and power on VM afterwards with the option of hardpower timeout
Allow spaces in VM(s) backup list (not recommended and not a best practice)
Ensure that snapshot removal process completes prior to to continuing onto the next VM backup
VM(s) that intially contain snapshots will not be backed up and will be ignored
Ability to specify the number of backup rotations for VM
Output back up VMDK(s) in either ZEROEDTHICK (default behavior) or 2GB SPARSE or THIN or EAGERZEROEDTHICK format
Support for both SCSI and IDE disks
Non-persistent NFS backup
Fully support VMDK(s) stored across multiple datastores
Ability to compress backups (Experimental Support)
Ability to configure individual VM backup policies NEW!
Ability to include/exclude specific VMDK(s) per VM (requires individual VM backup policy setup) NEW!
Ability to configure logging output to file NEW!
Independent disk awareness (will ignore VMDK) NEW!
New timeout variables for shutdown and snapshot creations NEW!
Ability to configure snapshots with both memory and/or quiesce options NEW!
Ability to configure disk adapter format NEW!
Additional debugging information including dry run execution NEW!
Support for VMs with both virtual/physical RDM (pRDM will be ignored and not backed up) NEW!

Requirements:

VMs running on ESX(i) 3.5/4.0+
SSH console access to ESX/ESXi host

Setup:

1) Download ghettoVCB.sh to either your ESX or ESXi system

2) Change the permissions on the script to ensure it can be executed:

[root@himalaya ~]# chmod +x ghettoVCB.sh

Configurations:

The following variables need to be defined within the script or in VM backup policy prior to execution.

Defining the backup datastore and folder in which the backups are stored (if folder does not exist, it will automatically be created):

VM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS

Defining the backup disk format (zeroedthick, eagerzeroedthick, thin, and 2gbsparse are available):

DISK_BACKUP_FORMAT=thin

Defining the backup rotation per VM:

VM_BACKUP_ROTATION_COUNT=3

Defining whether the VM is powered down or not prior to backup (1 = enable, 0 = disable):

Note: VM(s) that are powered off will not require snapshoting

POWER_VM_DOWN_BEFORE_BACKUP=0

Defining whether the VM can be hard powered off when "POWER_VM_DOWN_BEFORE_BACKUP" is enabled and VM does not have VMware Tools installed

ENABLE_HARD_POWER_OFF=0

If "ENABLE_HARD_POWER_OFF" is enabled, then this defines the number of (60sec) iterations the script will before executing a hard power off when:

ITER_TO_WAIT_SHUTDOWN=3

The number (60sec) iterations the script will wait when powering off the VM and will give up and ignore the particular VM for backup:

POWER_DOWN_TIMEOUT=5

The number (60sec) iterations the script will wait when taking a snapshot of a VM and will give up and ignore the particular VM for backup:

Default value should suffice

SNAPSHOT_TIMEOUT=15

Defining whether or not to enable compression (1 = enable, 0 = disable):

ENABLE_COMPRESSION=0

Defining the adapter type for backed up VMDK (buslogic and lsilogic are available):

ADAPTER_FORMAT=buslogic

Defining whether virtual machine memory is snapped and if quiescing is enabled (1 = enable, 0 = disable):

Note: By default both are disabled

VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0

*Defining VMDK(s) to backup from a particular VM either a list of vmdks or "all"

VMDK_FILES_TO_BACKUP="myvmdk.vmdk"

Ensure that you do not edit past this section:

########################## DO NOT MODIFY PAST THIS LINE ##########################

Usage:

[root@himalaya ~]# ./ghettoVCB.sh
###############################################################################
#
# ghettoVCB for ESX/ESXi 3.5 & 4.x+
# Author: William Lam
# http://www.engineering.ucsb.edu/~duonglt/vmware/
# Created: 11/17/2008
# Last modified: 11/14/2009
#
###############################################################################

Usage: ./ghettoVCB.sh -f [VM_BACKUP_UP_LIST] -c [VM_CONFIG_DIR] -l [LOG_FILE]

OPTIONS:
   -f     List of VMs to backup
   -c     Configuration directory for VM backups
   -l     File to output logging
   -d     Debug level [info|debug|dryrun] (default: info)

(e.g.)

Backup VMs stored in a list
        ./ghettoVCB.sh -f vms_to_backup

Backup VMs based on specific configuration located in directory
        ./ghettoVCB.sh -f vms_to_backup -c vm_backup_configs

Output will log to /tmp/ghettoVCB.log
        ./ghettoVCB.sh -f vms_to_backup -l /tmp/ghettoVCB.log

Dry run (no backup will take place)
        ./ghettoVCB.sh -f vms_to_backup -d dryrun

The input to this script is a file that contains the display name of the virtual machine(s) separated by a newline. When creating this file on a non-Linux/UNIX system, you may introduce ^M character which can cause the script to miss-behave. To ensure this does not occur, plesae create the file on the ESX/ESXi host.

Here is a sample of what the file would look like:

[root@himalaya ~]# cat vms_to_backup
VCAP
VIMA
vMA-2

Sample Execution:

Backup VMs stored in a list
Backup VMs based on individual VM backup policies
Debug Mode
Dry run Mode

Backup VMs stored in a list

Log verbosity: info (default)
Log output: stdout (default)

[root@himalaya ~]# ./ghettoVCB.sh -f vms_to_backup

2009-11-12 06:14:10 -- info: ============================== ghettoVCB LOG START ==============================

2009-11-12 06:14:10 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2009-11-12 06:14:10 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2009-11-12 06:14:10 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2009-11-12 06:14:10 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2009-11-12 06:14:10 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2009-11-12 06:14:10 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2009-11-12 06:14:10 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2009-11-12 06:14:10 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2009-11-12 06:14:10 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2009-11-12 06:14:10 -- info: CONFIG - LOG_LEVEL = info
2009-11-12 06:14:10 -- info: CONFIG - BACKUP_LOG_OUTPUT = stdout
2009-11-12 06:14:10 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2009-11-12 06:14:10 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2009-11-12 06:14:10 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all

2009-11-12 06:14:15 -- info: Initiate backup for VCAP
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP_2.vmdk'...
Clone: 100% done.
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP_1.vmdk'...
Clone: 100% done.
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP.vmdk'...
Clone: 100% done.
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP-0.vmdk'...
Clone: 100% done.
2009-11-12 06:15:15 -- info: Backup Duration: 60 Seconds
2009-11-12 06:15:15 -- info: Successfully completed backup for VCAP!

2009-11-12 06:15:17 -- info: Initiate backup for VIMA
2009-11-12 06:15:17 -- info: Creating Snapshot "ghettoVCB-snapshot-2009-11-12" for VIMA
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SAS.Savvio/VIMA/VIMA.vmdk'...
Clone: 100% done.
2009-11-12 06:16:40 -- info: Removing snapshot from VIMA ...
2009-11-12 06:16:43 -- info: Backup Duration: 1.43 Minutes
2009-11-12 06:16:43 -- info: Successfully completed backup for VIMA!

2009-11-12 06:16:47 -- info: Initiate backup for vMA-2
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk'...
Clone: 100% done.
2009-11-12 06:18:14 -- info: Backup Duration: 1.45 Minutes
2009-11-12 06:18:14 -- info: Successfully completed backup for vMA-2!

2009-11-12 06:18:14 -- info: ============================== ghettoVCB LOG END ================================

Backup VMs based on individual VM backup policies and log output to /tmp/ghettoVCB.log

Log verbosity: info (default)
Log output: /tmp/ghettoVCB.log (default)

1. Create folder to hold individual VM backup policies (can be named anything):

[root@himalaya ~]# mkdir backup_config

2. Create individual VM backup policies for each VM that ensure each file is named exactly as the display name of the VM being backed up (use provided template to create duplicates):

[root@himalaya backup_config]# cp ghettoVCB-vm_backup_configuration_template VCAP
[root@himalaya backup_config]# cp ghettoVCB-vm_backup_configuration_template VIMA

Listing of VM backup policy within backup configuration directory

[root@himalaya backup_config]# ls
ghettoVCB-vm_backup_configuration_template  VCAP  VIMA

Backup policy for "VCAP" (backup only 2 specific VMDKs)

[root@himalaya backup_config]# cat VCAP
VM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=4
POWER_DOWN_TIMEOUT=5
SNAPSHOT_TIMEOUT=15
ENABLE_COMPRESSION=0
ADAPTER_FORMAT=buslogic
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
VMDK_FILES_TO_BACKUP="VCAP.vmdk,VCAP_2.vmdk"

Backup policy for VM "VIMA" (backup all VMDKs found)

[root@himalaya backup_config]# cat VIMA
VM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=4
POWER_DOWN_TIMEOUT=5
SNAPSHOT_TIMEOUT=15
ENABLE_COMPRESSION=0
ADAPTER_FORMAT=buslogic
VM_SNAPSHOT_MEMORY=1
VM_SNAPSHOT_QUIESCE=0
VMDK_FILES_TO_BACKUP="all"

Note: When specifying -c option (individual VM backup policy mode) if a VM is listed in the backup list but DOES NOT have a corresponding backup policy, the VM will be backed up using the default configuration found within the ghettoVCB.sh script.

Execution of backup

[root@himalaya ~]# ./ghettoVCB.sh -f vms_to_backup -c backup_config -l /tmp/ghettoVCB.log

Logging output to "/tmp/ghettoVCB.log" ...
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP_2.vmdk'...
Clone: 100% done.
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP.vmdk'...
Clone: 100% done.
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SAS.Savvio/VIMA/VIMA.vmdk'...
Clone: 100% done.
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk'...
Clone: 100% done.

Note: When specifying the -l option (log output to file), vmkfstools copy is also logged to stdout. This is done primarily for debugging purposes.

Log output from backup

[root@himalaya ~]# cat /tmp/ghettoVCB.log

2009-11-12 06:26:53 -- info: ============================== ghettoVCB LOG START ==============================

2009-11-12 06:26:56 -- info: CONFIG - USING CONFIGURATION FILE = backup_config/VCAP
2009-11-12 06:26:56 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2009-11-12 06:26:56 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2009-11-12 06:26:56 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2009-11-12 06:26:56 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2009-11-12 06:26:56 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2009-11-12 06:26:56 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2009-11-12 06:26:56 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4
2009-11-12 06:26:56 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2009-11-12 06:26:56 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2009-11-12 06:26:56 -- info: CONFIG - LOG_LEVEL = info
2009-11-12 06:26:56 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB.log
2009-11-12 06:26:56 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2009-11-12 06:26:56 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2009-11-12 06:26:56 -- info: CONFIG - VMDK_FILES_TO_BACKUP = VCAP.vmdk,VCAP_2.vmdk

2009-11-12 06:26:58 -- info: Initiate backup for VCAP
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP_2.vmdk'...
Clone: 100% done.
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP.vmdk'...
Clone: 100% done.
2009-11-12 06:26:59 -- info: Backup Duration: 1 Seconds
2009-11-12 06:26:59 -- info: Successfully completed backup for VCAP!

2009-11-12 06:26:59 -- info: CONFIG - USING CONFIGURATION FILE = backup_config/VIMA
2009-11-12 06:26:59 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2009-11-12 06:26:59 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2009-11-12 06:26:59 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2009-11-12 06:26:59 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2009-11-12 06:26:59 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2009-11-12 06:26:59 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2009-11-12 06:26:59 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4
2009-11-12 06:26:59 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2009-11-12 06:26:59 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2009-11-12 06:26:59 -- info: CONFIG - LOG_LEVEL = info
2009-11-12 06:26:59 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB.log
2009-11-12 06:26:59 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 1
2009-11-12 06:26:59 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2009-11-12 06:26:59 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all

2009-11-12 06:27:02 -- info: Initiate backup for VIMA
2009-11-12 06:27:02 -- info: Creating Snapshot "ghettoVCB-snapshot-2009-11-12" for VIMA
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SAS.Savvio/VIMA/VIMA.vmdk'...
Clone: 100% done.
2009-11-12 06:29:28 -- info: Removing snapshot from VIMA ...
2009-11-12 06:29:31 -- info: Backup Duration: 2.48 Minutes
2009-11-12 06:29:31 -- info: Successfully completed backup for VIMA!

2009-11-12 06:29:31 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2009-11-12 06:29:31 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2009-11-12 06:29:31 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2009-11-12 06:29:31 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2009-11-12 06:29:31 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2009-11-12 06:29:31 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2009-11-12 06:29:31 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2009-11-12 06:29:31 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2009-11-12 06:29:31 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2009-11-12 06:29:31 -- info: CONFIG - LOG_LEVEL = info
2009-11-12 06:29:31 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB.log
2009-11-12 06:29:31 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2009-11-12 06:29:31 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2009-11-12 06:29:31 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all

2009-11-12 06:29:35 -- info: Initiate backup for vMA-2
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk'...
Clone: 100% done.
2009-11-12 06:31:05 -- info: Backup Duration: 1.50 Minutes
2009-11-12 06:31:05 -- info: Successfully completed backup for vMA-2!

2009-11-12 06:31:05 -- info: ============================== ghettoVCB LOG END ================================

Debug backup mode

Log verbosity: debug
Log output: stdout

[root@himalaya ~]# ./ghettoVCB.sh -f vms_to_backup -c backup_config -d debug
2009-11-13 19:51:47 -- info: ============================== ghettoVCB LOG START ==============================

2009-11-13 19:51:47 -- debug: HOST BUILD: VMware ESX 4.0.0 build-164009
2009-11-13 19:51:47 -- debug: HOSTNAME: himalaya.primp-industries.com

2009-11-13 19:51:51 -- info: CONFIG - USING CONFIGURATION FILE = backup_config/VCAP
2009-11-13 19:51:51 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2009-11-13 19:51:51 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2009-11-13 19:51:51 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2009-11-13 19:51:51 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2009-11-13 19:51:51 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2009-11-13 19:51:51 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2009-11-13 19:51:51 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4
2009-11-13 19:51:51 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2009-11-13 19:51:51 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2009-11-13 19:51:51 -- info: CONFIG - LOG_LEVEL = debug
2009-11-13 19:51:51 -- info: CONFIG - BACKUP_LOG_OUTPUT = stdout
2009-11-13 19:51:51 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2009-11-13 19:51:51 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2009-11-13 19:51:51 -- info: CONFIG - VMDK_FILES_TO_BACKUP = VCAP.vmdk,VCAP_2.vmdk

2009-11-13 19:51:52 -- info: Initiate backup for VCAP
2009-11-13 19:51:52 -- debug: findVMDK() - Searching for VMDK: "VCAP_2.vmdk" to backup
2009-11-13 19:51:52 -- debug: findVMDK() - Found VMDK! - "VCAP_2.vmdk" to backup
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP_2.vmdk'...
Clone: 100% done.
2009-11-13 19:51:53 -- debug: findVMDK() - Searching for VMDK: "VCAP_1.vmdk" to backup
2009-11-13 19:51:53 -- debug: findVMDK() - Searching for VMDK: "VCAP.vmdk" to backup
2009-11-13 19:51:53 -- debug: findVMDK() - Found VMDK! - "VCAP.vmdk" to backup
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP.vmdk'...
Clone: 100% done.
2009-11-13 19:51:53 -- debug: findVMDK() - Searching for VMDK: "VCAP-0.vmdk" to backup
2009-11-13 19:51:54 -- info: Backup Duration: 2 Seconds
2009-11-13 19:51:54 -- info: Successfully completed backup for VCAP!

2009-11-13 19:51:54 -- info: CONFIG - USING CONFIGURATION FILE = backup_config/VIMA
2009-11-13 19:51:54 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2009-11-13 19:51:54 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2009-11-13 19:51:54 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2009-11-13 19:51:54 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2009-11-13 19:51:54 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2009-11-13 19:51:54 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2009-11-13 19:51:54 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4
2009-11-13 19:51:54 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2009-11-13 19:51:54 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2009-11-13 19:51:54 -- info: CONFIG - LOG_LEVEL = debug
2009-11-13 19:51:54 -- info: CONFIG - BACKUP_LOG_OUTPUT = stdout
2009-11-13 19:51:54 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 1
2009-11-13 19:51:54 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2009-11-13 19:51:54 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all

2009-11-13 19:51:56 -- info: Initiate backup for VIMA
2009-11-13 19:51:56 -- info: Creating Snapshot "ghettoVCB-snapshot-2009-11-13" for VIMA
2009-11-13 19:51:58 -- debug: Waiting for snapshot "ghettoVCB-snapshot-2009-11-13" to be created
2009-11-13 19:51:58 -- debug: Snapshot timeout set to: 900 seconds
2009-11-13 19:52:01 -- debug: Waiting for snapshot creation to be completed - Iteration: 0 - sleeping for 60secs (Duration: 0 seconds)
2009-11-13 19:53:03 -- debug: findVMDK() - Searching for VMDK: "VIMA.vmdk" to backup
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SAS.Savvio/VIMA/VIMA.vmdk'...
Clone: 100% done.
2009-11-13 19:54:27 -- info: Removing snapshot from VIMA ...
2009-11-13 19:54:32 -- info: Backup Duration: 2.60 Minutes
2009-11-13 19:54:32 -- info: Successfully completed backup for VIMA!

2009-11-13 19:54:32 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2009-11-13 19:54:32 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2009-11-13 19:54:32 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2009-11-13 19:54:32 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2009-11-13 19:54:32 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2009-11-13 19:54:32 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2009-11-13 19:54:32 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2009-11-13 19:54:32 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2009-11-13 19:54:32 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2009-11-13 19:54:32 -- info: CONFIG - LOG_LEVEL = debug
2009-11-13 19:54:32 -- info: CONFIG - BACKUP_LOG_OUTPUT = stdout
2009-11-13 19:54:32 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2009-11-13 19:54:32 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2009-11-13 19:54:32 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all

2009-11-13 19:54:35 -- info: Initiate backup for vMA-2
2009-11-13 19:54:35 -- debug: findVMDK() - Searching for VMDK: "vMA-2.vmdk" to backup
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk'...
Clone: 100% done.
2009-11-13 19:56:10 -- info: Backup Duration: 1.58 Minutes
2009-11-13 19:56:10 -- info: Successfully completed backup for vMA-2!

2009-11-13 19:56:10 -- info: ============================== ghettoVCB LOG END ================================

Dry run Mode (no backup will take place)

Log verbosity: drymode
Log output: stdout

[root@himalaya ~]# ./ghettoVCB.sh -f vms_to_backup -c backup_config -d dryrun

2009-11-12 06:32:57 -- info: ============================== ghettoVCB LOG START ==============================

2009-11-12 06:33:01 -- info: CONFIG - USING CONFIGURATION FILE = backup_config/VCAP
2009-11-12 06:33:01 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2009-11-12 06:33:01 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2009-11-12 06:33:01 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2009-11-12 06:33:01 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2009-11-12 06:33:01 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2009-11-12 06:33:01 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2009-11-12 06:33:01 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4
2009-11-12 06:33:01 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2009-11-12 06:33:01 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2009-11-12 06:33:01 -- info: CONFIG - LOG_LEVEL = dryrun
2009-11-12 06:33:01 -- info: CONFIG - BACKUP_LOG_OUTPUT = stdout
2009-11-12 06:33:01 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2009-11-12 06:33:01 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2009-11-12 06:33:01 -- info: CONFIG - VMDK_FILES_TO_BACKUP = VCAP.vmdk,VCAP_2.vmdk

2009-11-12 06:33:01 -- dryrun: ###############################################
2009-11-12 06:33:01 -- dryrun: Virtual Machine: VCAP
2009-11-12 06:33:01 -- dryrun: VM_ID: 2784
2009-11-12 06:33:01 -- dryrun: VMX_PATH: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP/VCAP.vmx
2009-11-12 06:33:01 -- dryrun: VMX_DIR: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/VCAP
2009-11-12 06:33:01 -- dryrun: VMX_CONF: VCAP/VCAP.vmx
2009-11-12 06:33:01 -- dryrun: VMFS_VOLUME: himalaya-local-SATA.RE4-GP:Storage
2009-11-12 06:33:01 -- dryrun: VMDK(s):
2009-11-12 06:33:01 -- dryrun:  VCAP_2.vmdk
2009-11-12 06:33:01 -- dryrun:  VCAP_1.vmdk
2009-11-12 06:33:01 -- dryrun:  VCAP.vmdk
2009-11-12 06:33:01 -- dryrun:  VCAP-0.vmdk
2009-11-12 06:33:01 -- dryrun: ###############################################

2009-11-12 06:33:01 -- info: CONFIG - USING CONFIGURATION FILE = backup_config/VIMA
2009-11-12 06:33:01 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2009-11-12 06:33:01 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2009-11-12 06:33:01 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2009-11-12 06:33:01 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2009-11-12 06:33:01 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2009-11-12 06:33:01 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2009-11-12 06:33:01 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4
2009-11-12 06:33:01 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2009-11-12 06:33:01 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2009-11-12 06:33:01 -- info: CONFIG - LOG_LEVEL = dryrun
2009-11-12 06:33:01 -- info: CONFIG - BACKUP_LOG_OUTPUT = stdout
2009-11-12 06:33:01 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 1
2009-11-12 06:33:01 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2009-11-12 06:33:01 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all

2009-11-12 06:33:01 -- dryrun: ###############################################
2009-11-12 06:33:01 -- dryrun: Virtual Machine: VIMA
2009-11-12 06:33:01 -- dryrun: VM_ID: 4064
2009-11-12 06:33:01 -- dryrun: VMX_PATH: /vmfs/volumes/himalaya-local-SAS.Savvio/VIMA/VIMA.vmx
2009-11-12 06:33:01 -- dryrun: VMX_DIR: /vmfs/volumes/himalaya-local-SAS.Savvio/VIMA
2009-11-12 06:33:01 -- dryrun: VMX_CONF: VIMA/VIMA.vmx
2009-11-12 06:33:01 -- dryrun: VMFS_VOLUME: himalaya-local-SAS.Savvio
2009-11-12 06:33:01 -- dryrun: VMDK(s):
2009-11-12 06:33:01 -- dryrun:  VIMA.vmdk
2009-11-12 06:33:01 -- dryrun: ###############################################

2009-11-12 06:33:01 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2009-11-12 06:33:01 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2009-11-12 06:33:01 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2009-11-12 06:33:01 -- info: CONFIG - ADAPTER_FORMAT = buslogic
2009-11-12 06:33:01 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2009-11-12 06:33:01 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2009-11-12 06:33:01 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2009-11-12 06:33:01 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2009-11-12 06:33:01 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2009-11-12 06:33:01 -- info: CONFIG - LOG_LEVEL = dryrun
2009-11-12 06:33:01 -- info: CONFIG - BACKUP_LOG_OUTPUT = stdout
2009-11-12 06:33:01 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2009-11-12 06:33:01 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2009-11-12 06:33:01 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all

2009-11-12 06:33:01 -- dryrun: ###############################################
2009-11-12 06:33:01 -- dryrun: Virtual Machine: vMA-2
2009-11-12 06:33:01 -- dryrun: VM_ID: 4960
2009-11-12 06:33:01 -- dryrun: VMX_PATH: /vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmx
2009-11-12 06:33:01 -- dryrun: VMX_DIR: /vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2
2009-11-12 06:33:01 -- dryrun: VMX_CONF: vMA-2/vMA-2.vmx
2009-11-12 06:33:01 -- dryrun: VMFS_VOLUME: himalaya-local-SAS.Constellation
2009-11-12 06:33:01 -- dryrun: VMDK(s):
2009-11-12 06:33:02 -- dryrun:  vMA-2.vmdk
2009-11-12 06:33:02 -- dryrun: ###############################################

2009-11-12 06:33:02 -- info: ============================== ghettoVCB LOG END ================================

Enable compression for backups:

To make use of this feature, modify the variable ENABLE_COMPRESSION from 0 to 1. Please note, do not mix uncompressed backups with compressed backups. Ensure that directories selected for backups do not contain any backups with previous versions of ghettoVCB before enabling and implementing the compressed backups feature.

Restore backups (ghettoVCB-restore.sh):

To recover a VM that has been processed by ghettoVCB, please take a look at this document: Ghetto Tech Preview - ghettoVCB-restore.sh - Restoring VM's backed up from ghettoVCB to ESX(i) 3.5 and 4.0+

Cronjob FAQ:

Please take a moment to read over what is a cronjob and how to set one up, before continuing

The task of configuring cronjobs on classic ESX servers (with Service Console) is no different than traditional cronjobs on *nix operating systems (this procedure is outlined in the link above). With ESXi on the other hand, additional factors need to be taken into account when setting up cronjobs in the limited shell console called Busybox because changes made do not persist through a system reboot. The following document will outline steps to ensure that cronjob configurations are saved and present upon a reboot.

Task: Configure ghettoVCB.sh to execute a backup five days a week (M-F) at 12AM (midnight) everyday and send output to a unique log file

Configure on ESX:

1. As root, you'll install your cronjob by issuing:

[root@himalaya ~]# crontab -e

2. Append the following entry:

0 0 * * 1-5 /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB.sh /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/backuplist > /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB-backup-$(date +\%s).log

3. Save and exit

[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# crontab -e
no crontab for root - using an empty one
crontab: installing new crontab

4. List out and verify the cronjob that was just created:

[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# crontab -l
0 0 * * 1-5 /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB.sh /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/backuplist > /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB-backup-$(date +\%s).log

You're ready to go!

Configure on ESXi:

1. Setup the cronjob by appending the following line to /var/spool/cron/crontabs/root:

0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh /vmfs/volumes/simplejack-local-storage/backuplist > /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-$(date +\%s).log

2. Kill the current crond (cron daemon) and then restart the crond for the changes to take affect:

On ESXi < 3.5u3

/bin/kill `ps | grep crond | cut -f 1 -d ' '`

On ESXi 3.5u3+

~ # kill $(pidof crond)
~ # crond

On ESXi 4.0

~ # kill $(cat /var/run/crond.pid)
~ # busybox crond

3. Now that the cronjob is ready to go, you need to ensure that this cronjob will persist through a reboot. You'll need to add the following two lines to /etc/rc.local (ensure that the cron entry matches what was defined above)

On ESXi 3.5

/bin/kill $(pidof crond)
/bin/echo "0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh /vmfs/volumes/simplejack-local-storage/backuplist > /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
crond

On ESXi 4.0

/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh /vmfs/volumes/simplejack-local-storage/backuplist > /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
/bin/busybox crond

Afterwards the file should look like the following:

~ # cat /etc/rc.local
#! /bin/ash
export PATH=/sbin:/bin

log() {
   echo "$1"
   logger init "$1"
}

#execute all service retgistered in /etc/rc.local.d
if [http:// -d /etc/rc.local.d |http:// -d /etc/rc.local.d ]; then
   for filename in `find /etc/rc.local.d/ | sort`
      do
         if [ -f $filename ] && [ -x $filename ]; then
            log "running $filename"
            $filename
         fi
      done
fi

/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh /vmfs/volumes/simplejack-local-storage/backuplist > /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
/bin/busybox crond

This will ensure that the cronjob is re-created upon a reboot of the system through a startup script

2. To ensure that this is saved in the ESXi configuration, we need to manually initiate an ESXi backup by running:

~ # /sbin/auto-backup.sh
config implicitly loaded
local.tgz
etc/vmware/vmkiscsid/vmkiscsid.db
etc/dropbear/dropbear_dss_host_key
etc/dropbear/dropbear_rsa_host_key
etc/opt/vmware/vpxa/vpxa.cfg
etc/opt/vmware/vpxa/dasConfig.xml
etc/sysconfig/network
etc/vmware/hostd/authorization.xml
etc/vmware/hostd/hostsvc.xml
etc/vmware/hostd/pools.xml
etc/vmware/hostd/vmAutoStart.xml
etc/vmware/hostd/vmInventory.xml
etc/vmware/hostd/proxy.xml
etc/vmware/ssl/rui.crt
etc/vmware/ssl/rui.key
etc/vmware/vmkiscsid/initiatorname.iscsi
etc/vmware/vmkiscsid/iscsid.conf
etc/vmware/vmware.lic
etc/vmware/config
etc/vmware/dvsdata.db
etc/vmware/esx.conf
etc/vmware/license.cfg
etc/vmware/locker.conf
etc/vmware/snmp.xml
etc/group
etc/hosts
etc/inetd.conf
etc/rc.local
etc/chkconfig.db
etc/ntp.conf
etc/passwd
etc/random-seed
etc/resolv.conf
etc/shadow
etc/sfcb/repository/root/interop/cim_indicationfilter.idx
etc/sfcb/repository/root/interop/cim_indicationhandlercimxml.idx
etc/sfcb/repository/root/interop/cim_listenerdestinationcimxml.idx
etc/sfcb/repository/root/interop/cim_indicationsubscription.idx
Binary files /etc/vmware/dvsdata.db and /tmp/auto-backup.31345.dir/etc/vmware/dvsdata.db differ
config implicitly loaded
Saving current state in /bootbank
Clock updated.
Time: 20:40:36   Date: 08/14/2009   UTC

Now you're really done!

If you're still having trouble getting the cronjob to work, ensure that you've specified the correct parameters and there aren’t any typos in any part of the syntax.

Ensure crond (cron daemon) is running:

ESX:

[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# ps -ef | grep crond | grep -v grep
root      2625     1  0 Aug13 ?        00:00:00 crond

ESXi:

~ # ps | grep crond | grep -v grep
5196 5196 busybox              crond

Ensure that the date/time on your ESX(i) host is setup correctly:

ESX(i):

[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# date
Fri Aug 14 23:44:47 PDT 2009

Note: Careful attention must be noted if more than one backup is performed per day. Backup windows should be staggered to avoid contention or saturation of resources during these periods.

FAQ:

1Q: I'm getting error X when using the script or I'm not getting any errors, the backup didn’t even take place. Oh what could be wrong?
1A: Please provide the entire output of a manual execution (debug & dryrun mode) or if you're logging the output withing \{code\} tags, a short description of your environment and the type of VM(s) you're trying to backup—I will try to provide some assistance.

2Q: I've sent you private message or email but I haven't received a response? What gives?
2A: I do not accept issues/bugs reported via PM or email, I will reply back, directing you to post on the appropriate VMTN forum (that's what it's for). If the data/results you're providing is truely senstive to your environment I will hear you out, but 99.99% it is not, so please do not messsage/email me directly. I do monitor all forums that contain my script including the normal VMTN forums and will try to get back to your question as soon as I can and as time permits. Please do be patient as you're not the only person using the script (100,000+ views), thank you.

3Q: Can I schedule backups to take place hourly, daily, monthly, yearly?
3A: Yes, do a search online for crontab.

4Q: I would like to setup cronjob for ESX(i) 3.5 or 4.0?
4A: Take a look at the Cronjob FAQ section in this document.

5Q: I want to schedule my backup on Windows, how do I do this?
5A: Do a search for plink. Make sure you have paired SSH keys setup between your Windows system and ESX/ESXi host.

6Q: I only have a single ESXi host. I want to take backups and store them somewhere else. The problem is: I don't have NFS, iSCSI nor FC SAN. What can I do?
6A: You can use local storage to store your backups assuming that you have enough space on the destination datastore. Afterwards, you can use scp (WinSCP/FastSCP) to transfer the backups from the ESXi host to your local desktop.

7Q: I’m pissed; the backup is taking too long. My datastore is of type X?
7A: YMMV, take a look at your storage configuration and make sure it is optimized.

8Q: I noticed that the backup rotation is occurring after a backup. I don't have enough local storage space, can the process be changed?
8A: This is primarily done to ensure that you have at least one good backup in case the new backup fails. If you would like to modify the script, you're more than welcome to do so.

9Q: What is the best storage configuration for datastore type X?
9A: Search the VMTN forums; there are various configurations for the different type of storage/etc.

10Q: I want to setup an NFS server to run my backups. Which is the best and should it be virtual or physical?
10A: Please refer to answer 7A. From experience, we’ve seen physical instances of NFS servers to be faster than their virtual counterparts. As always, YMMV.

11Q: I have VMs that have snapshots. I want to back these things up but the script doesn’t let me do it. How do I fix that?
11A: VM snapshots are not meant to be kept for long durations. When backing up a VM that contains a snapshot, you should ensure all snapshots have been committed prior to running a backup. No exceptions will be made…ever.

12Q: I would like to restore from backup, what is the best method?
12A: The restore process will be unique for each environment and should be determined by your backup/recovery plans. At a high level you have the option of mounting the backup datastore and registering the VM in question or copy the VM from the backup datastore to the ESX/ESXi host. The latter is recommended so that you're not running a VM living on the backup datastore or inadvertently modifying your backup VM(s).

13Q: When I try to run the script I get: "-bash: ./ghettoVCB.sh: Permission denied", what is wrong?
13A: You need to change the permission on the script to be executable, chmod +x ghettoVCB.sh

14Q: Where can I download the latest version of the script?
14A: The latest version is available on this page at the bottom.

15Q: I would like to suggest/recommend feature X, can I get it? When can I get it? Why isn't it here, what gives?
15A: The general purpose of this script is to provide a backup solution around VMware VMs. Any additional features outside of that process will be taken into consideration depending on the amount of time, number of requests and actual usefulness as a whole to the community rather than to an individual.

16Q: What are the different type of backup uses cases that are supported with ghettoVCB?
16A: 1) Live backup of VM with the use of a snapshot and 2) Offline backup of a VM without a snapshot. These are the only two use cases supported by the script.

Useful Links:

Detail instructions on how to configure/schedule ghettoVCB on Windows (Raj Perumal's The World Runs on Technology Blog):

Part 1
Part 2
Part 3

Change log:

11/17/09 - The following enhancements and fixes have been implemented in this release of ghettoVCB. Special thanks goes out to all the ghettoVCB BETA testers for providing time and their environments to test features/fixes of the new script!

Enhancements:

Individual VM backup policy
Include/exclude specific VMDK(s)
Logging to file
Timeout variables
Configur snapshot memory/quiesce
Adapter format
Additional logging + dryrun mode
Support for both physical/virtual RDMs

Fixes:

Independent disk aware

VMWare ESX 3.0.x - How to change the server name

Mon, 17 Nov 2008 21:21:21 GMT

1) Move off all VM's to another host, whether they are running or not.
2) From Virtual Center - put the host who's name is going to be changed in maintenance mode.
3) On the configuration tab for the selected host - release the licensing. ( I had trouble getting it back on one of mine where I didn't do this)
4) Under the DNS and ROUTING section, change the name of the host to what you want it to be.
5) REMOVE the host from VC.
6) Use the client to login to the server. REBOOT the server.
7) When the server comes up, you should be able to ADD HOST with VC with the new name.
8) Migrate your VM's back.
* You do not have to change the names of any DATASTORES.

Script stuff:
cp -f /etc/sysconfig/network /tmp/network.bak
cp -f /etc/hosts /tmp/hosts.bak
sed -e 's/oldhostname.localdomain/newhostname.localdomain/g' /tmp/network.bak >> /etc/sysconfig/network
sed -e 's/oldhostname.localdomain/newhostname.localdomain/g' /tmp/hosts.bak >> /etc/hosts

Virtual Center - Task and Event History

Thu, 06 Nov 2008 15:11:40 GMT

In ESX you can see recent events in task / events. But there appears to be a limit. since it's saved in a database, shouldn't this list go back as far as you need? Any way to see the ENTIRE task / event list?

This is from the VC not individual ESX hosts, how do we retrieve the list so we can see months or weeks ago?

Well it's not syslog, but I did figure out where this info is. And SQL does keep ALL the events, going back to the beginning, at least our database hasn't purge the old data yet, I have stuff going back to June (when I rebuilt the SQL table)

SQL : Schemas -> dbo -> Tables -> VPX_EVENT

You have to export this from SQL or use a viewer to get this info, but the events, tasks, everything (all details) are there. Now why can't VI simply display the entire table if we want it?

FYI for everyone, I contacted vmware about this and was confirmed to what rparker said...the ONLY way to get this info is to query the database...currently it is not possible to get this detailed historic data from VC...

This document was generated from the following thread: Task / Event History

Simple steps to use CA Arcserve bakcup agent on ESX 3.x

Tue, 21 Oct 2008 08:32:48 GMT

1- Fist of all, transfer your Arcserve Agent install files ( in a temporary folder on your ESX ), using VEAM sftp for example. You need to transfer the following files from the CD to the temporary folder: /agnts/linux

2 - Do a chmod 777 -R on all the copied file , tohave enough permissions to run the install procedure

3 - from this folder, run ./install

4 - After install is completed, run the agent: uagent start

5 - Enable service via Firewall:

esxcfg-firewall --openPort 6050,tcp,out,caagentd
esxcfg-firewall --openPort 6050,udp,out,caagentd
esxcfg-firewall --openPort 6051,tcp,in,caagentd
esxcfg-firewall --openPort 6051,udp,in,caagentd

6 - esxcfg-firewall -s should show you something like this:
Known services: activeDirectorKerberos caARCserve CIMHttpServer CIMHttpsServer CIMSLP commvaultDynamic commvaultStatic ftpClient ftpServer kerberos LDAP LDAPS legatoNetWorker LicenseClient nfsClient nisClient ntpClient smbClient snmpd sshClient sshServer swISCSIClient symantecBackupExec symantecNetBackup telnetClient TSM updateManager VCB vncServer vpxHeartbeats

7 - enable CA arcserve service: esxcfg-firewall -e caARCserve

8 - restart the firewall service: service firewall restart

9 - In order to make the /vmfs directory visible u need to modify the file /etc/mtab
and add this line
/vmfs /vmfs vmfs rw 0 0
and restart agent
caagent stop
caagent start

This is optional. It should be done automatically by the install procedure.

10 - Set up VMware ESX Server automatic pre and post scripts to enable online Vm backups:

From the CD , copy all files located in /agents/vmware to /opt/CA/BABuagent
, you must copy the pre_backup.pl pre script, the post_backup.pl post script, and the supporting files listed below to the BABuagent directory, and give execution permission to all the copied files.
Note: The permissions given should be similar to the permissions given to the Agent for Linux executable (labeled "uagentd") residing in the BABuagent directory.

cavm.cfg , env_var.pm , err_msg_set.pm , debug_msg.pm and the 2 .pl files

You need to give enough permissions to all these files to be excuted correctly ( for example, do a chmod 777 on all these files ).

11 - Modify the file: /opt/CA/BABuagent/uag.cfg : you need to add the following 3 lines at the end of the file

-P 0
-Prebackup /opt/CA/BABuagent/pre_backup.pl
-Postbackup /opt/CA/BABuagent/post_backup.pl

That's all. And the backup /restores work great. Even with online VMs

Hope this will help.

This document was generated from the following thread: Simple steps to use CA Arcserve bakcup agent on ESX 3.x

Steps for taking a XEN paravirtualized RHEL 5.X to VMware ESXi 3.5.X vm

Sat, 18 Oct 2008 14:56:36 GMT

Steps assume advanced VMware and Xen knowledge.

Xen -> VMware VM migration steps (Kernel step)

The kernel on the VM to be migrated must support fully virtualized operation. The kernels used for para-virtulized machines using RHEL 5 as a guest does not support fully virtualized operation by default. The best way to deal with this is to also install a standard kernel in the machine, port the machine and finally remove the Xen kernel.

1. Download a kernel with the same version number and architecture as the xen kernel, except it should be the generic kernel
2. Use RPM tools to install the kernel.
3. Modify /etc/modprobe.conf (this step is specific to RHEL 5 Xen VM because RHEL5 will not load LSI scsi modules during boot)

add:

alias eth0 e1000
alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptspi
alias scsi_hostadapter2 ata_piix

optionally remove:

alias scsi_hostadapter xenblk

4 Backup the old initrd file in /boot
5. Update initrd with the following command mkinitrd /boot/initrd-kernelversion.img /boot/kernelversion ex. kernelversion=2.6.18-92.el5
6. Test the new kernel by booting Xen in fully virtualized mode.
7. Port the disk over as outlined below.

Xen -> VMware VM migration steps (DISK step)

Packages

1. Download qemu from DAG repository. http://dag.wieers.com/rpm/packages/qemu/qemu-0.9.0-2.el5.rf.x86_64.rpm
2. Download VMware Server 2.0
3. Provision a real machine with RHEL5.X or Centos 5.X and install both rpms.

Steps

1. Convert raw .img file to .vmdk file using qemu-img. qemu-img convert testvm.img -O vmdk testvm.vmdk

The vmdk file will be the following format.

0 : single growable virtual disk (IDE, VM hardware type 4)
1 : growable virtual disk split in 2GB files
2 : preallocated virtual disk
3 : preallocated virtual disk split in 2GB files
4 : preallocated ESX-type virtual disk
5 : compressed disk optimized for streaming

Fast Steps (for testing)

A2. Convert .vmdk file to the proper format using vmware-vdiskmanager, vmware-vdiskmanager -r testvm.vmdk -t 4 testvmesx.vmdk

The resulting file(s) will be the following format.

0 : single growable virtual disk
1 : growable virtual disk split in 2GB files
2 : preallocated virtual disk
3 : preallocated virtual disk split in 2GB files
4 : preallocated ESX-type virtual disk (IDE, VM hardware type 4) Not supported by VMware ESX! but works..
5 : compressed disk optimized for streaming

A3. Provision a machine on ESX server and add the disk, VMware will warn the user that the disk geometry is IDE and its using a SCSI controller to access the disk.

Correct Steps

B2. Provision a VM on the VMware Server that can be used for disk imaging. VMware Server supports both IDE and SCSI drives. It is required to do the disk imaging inside a VM because the VM will not see the VMware disk metadata and will treat the disk as a regular block device.
B3. Create a SCSI disk of the same (virtual) size as the converted .vmdk disk.
B4. Add both SCSI disk and the converted IDE disk to the vm.
B5. Use the VM to dd / winimage the source converted IDE disk to the target SCSI disk. The SCSI disk will now have the data from the IDE disk.
B6. Convert the new .vmdk file to the proper format using vmware-vdiskmanager http://vmware-vdiskmanager -r testvmscsi.vmdk -t 4 testvmesx.vmdk

The resulting file(s) will be the following format.

0 : single growable virtual disk
1 : growable virtual disk split in 2GB files
2 : preallocated virtual disk
3 : preallocated virtual disk split in 2GB files
4 : preallocated ESX-type virtual disk (SCSI, VM hardware type 7) Not supported by VMware ESX!
5 : compressed disk optimized for streaming

B7. Open up the *.vmdk meta file. It will be the small file that doesn't have 'flat' as a part of the filename and change db.virtualHWVersion = "X" to 4. The resulting file is supported by ESX server.
B8. Provision a machine on ESX server and add the disk.
B9. If source machine was a XEN para-virtualized machine it will probably try to boot to the XEN kernel by default. If a boot manager is installed it will go back to the grub kernel selection screen where the non XEN kernel can be booted from.
B10. Remove the Xen kernel to streamline the boot process

This document was generated from the following thread: Steps for taking a XEN paravirtualized RHEL 5.X to VMware ESXi 3.5.X vm

ESXi and HP ProLiant ML350 G5 server

Fri, 17 Oct 2008 10:23:09 GMT

Hi all,

First time poster but hope to be in here for a long time coming after convincing my company to migrate to VMWare away from MS.

I can't seem to be able to download the Hardware List that ESXi server will install on. Can someone let me know if the following servers support the latest version (3.5?) of ESXi server:

ProLiant ML350 G5

ProLiant DL380 G4

ProLiant DL380 G5

Also before I install just a few questions on basic management of the ESXi server without buying VI. What sort of interface do you get with ESXi? Is it text driven or GUI? How easy is it to add in VMs/take them out?

Thanks a lot

Luke

virtual_networking_concepts

Mon, 06 Oct 2008 09:33:19 GMT

NFS Storage configuration

Wed, 24 Sep 2008 13:20:12 GMT

Im trying to set up NFS storage for our ESX servers

Not sure if I have my networking setup correct for it too
work.

vmnic0: Service Console on a
"legal"(129.242.x.x) address on vswitch0.

vmnic1: free

vmnic2: virtual machines on vswitch2

vmnic3: Vmkernel for Vmotion on a
"private"(10.0.4.x) address on vswitch1.

When i try to mount the NFS Storage in VIC i get the following error:

"ERROR DURING THE CONFIGURATION OF THE HOST: UNABLE TO GET CONSOLE PATH FOR MOUNT"

Routing issue?

Network config issue?

vSwitch issue?

Any help would be appreciated.

Thanx,

Roar

How to tweak the 3ware 9650SE SATA RAID controller driver into ESX3i

Sun, 21 Sep 2008 10:25:35 GMT

IMPORTANT: First of all please consider that following my instructions below to embed a 3rd-party driver
into ESX3i is and remain UNSUPPORTED forever. You will not get any help from the vmware stuff personnel
until the below mentioned driver will be officially integrated as an update into the main upstream distribution.

Be also aware that integrating 3rd party driver in this way could seriously damage or alter any data stored
in your datastore, if the driver has not passed VMware's strong quality regression,NFR, harness tests before.
Please consider also that using the oem.tgz file can be somedays overwritten without notice.
You are alone, be careful on that.

But I want give back something to this lovely community, giving me a lot of information and even VMware for
ESX3i a small-footprint OS that can run 24x7 from a USB-drive having a rock solid filesystem VMFS and
beeing a small subset of the industry proven ESX3. This will be the future of the next generation of computing
platform.

Embedding ESX3i into the BIOS of any server, laptop, desktop and workstation and you get "virtualization at
your fingertips"
Making things easier to maintain and handle even portable across systems, easier to backup and distribute.
Easier for the developer for buiding specialized appliances without the need using a full blown operating
system with all the security concerns in it.

I brought two months ago a 3ware 9650SE SATA-RAID Controller after reading in the 3ware forum that the
newest 3ware driver can run under ESX3i.
(See:http://www.3ware.com/KB/article.aspx?id=14922)

Where can I find the ESX3i driver?

Please go to the 3ware download support website (http://www.3ware.com/support/download.asp)
Select the 3ware 9690SA Series software product
Select the item "Complete 9.5.0.2 CD for VMware ISO" (*9.5.0.2-Codeset-Complete.iso* checksum: a2939603988521aa6b49d78597a0b39a)
Burn the iso file or use Winimage to open the ISO without burning (my favorite way:-)* )
Go to VMupdates/RPMS
Extract VMware-esx-drivers-scsi-3w-9xxx-2.24.08.014vm-00000.i386.rpm into a temp directory
From the temp directory use 7-Zip to open the rpm file in a Windows environment
Double click the rpm file, you will see VMware-esx-drivers-scsi-3w-9xxx-2.24.08.014vm-00000.i386.cpio.gz
Double click on the gz file, you will see VMware-esx-drivers-scsi-3w-9xxx-2.24.08.014vm-00000.i386.cpio
Double click on the cpio file, you will see a dot folder
Double click on the dot folder
Goto /usr/lib/vmware/vmkmod
extract the 3w_9xxx.o driver
upload this driver to the ESXi box into the /mod directory
check /sbin/vmkload_mod /mod/3w_9xxx.o

BTW here is my calculated MD5 checksum "cb3e6d0cc53b61833d3ba7194f9631fa 3w_9xxx.o"

But how do I enable this driver inside ESX3i?
I read a little bit around and downloaded the newest driver from 3ware, extracted the 3w_9xxx.o driver and
uploaded it with scp into my esx3i server into the /mod directory. Afterward from the unsupported shell I loaded
manually the driver into the ESX3i by executing /sbin/vmkload_mod /mod/3w_9xxx.o. I was very happy to
format the RAID5 with VMFS and see my RAID5 array up and running every time after a rescan while rebooting
the partition.
Testing it a while I could not find any show stopper or strange behavior, so I considered to add this driver into
the system.

But how the hell can I automate this stuff?
First of all is essentially to know the PCI-ID of the mentioned card after loading the driver manually into the
running kernel with /sbin/vmkload_mod /mod/3w_9xxx.o and executing lspci -p from the unsupported shell.
The output of lspci was ... 13c1:1004 13c1:1004 ... wonderful.

What next?
OK I discovered that /etc/vmware/simple.map
has a list of all supported devices with vendor-id/device-id sub-vendor-id/sub-device-id. So I inserted into
/etc/vmware/simple.map 13c1:1004 0000:0000 storage 3w_9xxx and saved the file

The little thing to know now is the way ESX3i loads this driver automatically. Looking inside
/vmfs/volumes/Hypervisor1 there are all the tgz compressed stuff to load after
booting the kernel.

I tried to be not invasive and exchanged the empty oem.tgz file with my generated oem.tgz file.
The name sounds reasonable to use it for this tweak!

Here are the steps:

- Press Alt-F1 on the DCUI-console and enter -> unsupported <- and the root password if set
- cd /tmp
- make mkdir -p /mod
- make mkdir -p /etc/vmware
- make mkdir -p /usr/share/hwdata
- cd /tmp/mod
- get the driver from another ssh server with scp user@host:/tmp/3w_9xxx.o .
- cd /tmp/etc/vmware
- copy simple.map from /etc/vmware in this directory
- vi simple.map
- insert 13c1:1003 0000:0000 storage 3w_9xxx for the PCI-X Card before the line
beginning with 14e4:1600
- insert 13c1:1004 0000:0000 storage 3w_9xxx for the PCIe Card
- save and quit (:wq)
- cd /tmp/usr/share/hwdata
- copy pci.ids from /usr/share/hwdata in this directory
- vi pci.ids
- search for 13c1 3ware
- insert the following lines
- 1003 3ware 9650SE-series SATA-RAID Controller (PCI-X)
- 1004 3ware 9650SE-series SATA-RAID Controller (PCIe)
- save and quit (:wq)
- cd /tmp
- chown -R 201:201 ./mod
- chown -R 201:201 ./etc
- chown -R 201:201 ./usr
- chmod -R 755 ./mod
- chmod -R 755 ./etc
- chmod -R 755 ./usr
- chmod 644 ./etc/vmware/simple.map
- chmod 644 ./usr/share/hwdata/pci.ids
- chmod 755 ./mod/3w_9xxx.o
- tar -cvzf oem.tgz etc mod usr

Now you have tweaked the oem.tgz file with the 3ware driver in it and simple.map.
Copy this file into /vmfs/volumes/Hypervisor1 and chmod 755 oem.tgz and
chown root:root oem.tgz it. Repeat the above step also for /vmfs/volumes/Hypervisor2

Cross your fingers and reboot. If every thing is in place the 3ware driver will
be loaded automatically.

My questions now to the vmware guys are:
1) At what time can I expect this driver in the upstream esx3i bundle?
2) The 3ware controller type is unknown in VIClient -> Configuration -> Storage
Adapters. Where can I change it?
3) Is there a chance to see an ssh server for maintenance purposes in the future?

Enjoy it and tell me if this advice was useful, please consider to give me some points/credits if
this topic helped you in one way or another.

NOTE:the oem.tgz file below contains new PCI ID's for ICH8 and ICH8M SATA controller!

This document was generated from the following thread: How to tweak the 3ware 9650SE SATA RAID controller driver into ESX3i

ESXi Lockdown Mode

rob@virtualrobwilson.com — Sat, 20 Sep 2008 20:25:27 GMT

ESXi Lockdown Mode

So finally got a chance to work with and figure out the ESXi lockdown mode. Once I actually saw it in person it make complete sense... Ways to access and ESXi host a) Using VirtualCenter and you AD credentials b) Using the VIC client direct to the ESXi host with the ESXi ID
c) Using the RCLI commands using the ESXi IDs d) standing in front of the server wtih direct console access (keyboard & mouse attached to server) and using the ESXi IDs
The chart below show the four way to access an ESXi host along with the user credentials used...
ESXi Lockdown Mode

Looking at this two thing jump out at me

Number 1 - if you are standing in front of you ESXi host and plan on making configuration changes you must have the 'root' password. No other ID will let you log in the console.

Number 2 - Lockdown mode really only disables the use of the actually 'root' ID from being used with either the VIC or the RCLI interface. Other users with 'root like' privileges that you create can still make changes to the ESXi host using these methods. Thus avoiding using VirtualCenter.

And since there is not a PAM module for ESXi if you do plan on creating users on each ESXi host you'll need to manage each host individually (IDs and Passwords), or go with generic account with 'root like' access which in that case you might as well just use the root ID.

Lockdow mode does make for a good idea if you don't have the need for any of the RCLI interfaces. This way you can keep the 'root' password in a safe, managed all the ESXi hosts via VirtualCenter and only break out the root password in the event you need to make changes to the ESXi host to fix a communiction issues with VirtualCenter.

Remediation steps for cold clone of Solaris x86

Wed, 10 Sep 2008 08:01:28 GMT

Here are some notes I created when trying to get a cold cloned Solaris 64-bit VM which originated on an HP BL685c G5 server to run. The main complication is that the SCSI/RAID controller needs to be updated in the ramdisk and paths change.

It is not possible to resize virtual disk and the underlying filesystems are not accessible for individual selection leading to long clone time and/or large virtual disk size. Once cloned verify that the guest OS has been correctly identified and that the devices are appropriate for the guest OS. Some NIC adapter options are only relevant for particular guest OS so it is often necessary to change the guest OS save that change and then change the hardware to match. If you change the SCSI adapter associated with a virtual disk you will receive a warning asking if you want to change the bus adapter type associated with the disk, it appears to be safe to do this. Boot VM OS instance into failsafe mode and allow it to mount the discovered OS instance at /a. Discover /devices path to root filesystem and remount read-write e.g.

‘df /a' gives block device name

‘ls -l /dev/dsk/c1t0d0s0' gives path to /devices path

edit bootpath property in /a/boot/solaris/bootenv.rc to reflect this path to the new root device. Reboot the system, you should see the boot_archive ram disk being updated to reflect the hardware changes. Allow the system to attempt to boot normally, it will fail to mount the root filesystem and should drop to maintenance mode. Log in and remount the root filesystem read-write e.g.

mount -o remount,rw /devices/pci@0,0/pci1000,30@10/sd@0,0:a /

run devfsadm to reprobe the hardware

run format to determine new /dev path to root filesystem and edit /etc/vfstab to reflect this new path.

In the event that the driver for the network card in the physical machine was different from that in the VM you will need to move /etc/hostname.'driver''instance' e.g.

mv /etc/hostname.bnx0 /etc/hostname.e1000g0

ZFS resources are not specified in /etc/vfstab they must be destroyed and then imported using the pool ID e.g.

zpool destroy export
zpool import -f 1640966619789446333 export

Reboot the system, once again you should see the boot_archive ram disk being updated. Install VMware tools and reboot one final time.

Automation Tools for Booting and Configuring VMware ESX Server

Tue, 02 Sep 2008 23:09:58 GMT

ESX Automated Configuration Midwife

Tue, 02 Sep 2008 22:43:58 GMT

ESXi Post-Boot Configuration Initiator

Tue, 02 Sep 2008 22:12:55 GMT

Is there any way to reduce Memory Overhead size for Virtual Machines?

Thu, 28 Aug 2008 13:28:36 GMT

I have ESX 3.5 with 8GB Memory. And I am running 90 VMs of 40MB each with 76MB Memory Overhead. Is there any way to reduce the Memory Overhead size , So, that I can run more VMs.

Welcome to the forums,

As far as I know this isn't possible. The memory overhead is calculated according to the memory size, number of cpu's and the fact if it's a 32 or 64 vm.

more info on why:
http://www.waldspurger.org/carl/papers/esx-mem-osdi02.pdf
and the following pdf, page 128:
http://www.vmware.com/pdf/vi3_301_201_resource_mgmt.pdf

Duncan
My virtualisation blog:
http://www.yellow-bricks.com

If you find this information useful, please award points for "correct" or "helpful".

Hello,

The only way I know of is to remove all non-required virtual hardware components and to use faster cores allowing the assignment of 1 vCPU in more VMs versus mutilple vCPUs which have more overhead.

Hello,

I am also facing same problem...Can we fool ESX somehow so that ESX doesn't take the Overhead memory into account??

Any Help appreciated!!

Thanks

No, if you read the links above you will see that this isn't possible. It just reserves the space for certain procedures. maybe in time the overhead will be reduced, who knows...

Duncan
My virtualisation blog:
http://www.yellow-bricks.com

If you find this information useful, please award points for "correct" or "helpful".

Hello,

Is there any way to enable/increase swap after ESX server is installed. Would it solve the problem of overhead memory?

Any help appreciated.

Thanks

This document was generated from the following thread: Is there any way to reduce Memory Overhead size for Virtual Machines?

Replicated SAN LUNs using Sun StorageTek 6140 with VI3.5: VMWare tries to format the LUN after DR...

Tue, 26 Aug 2008 14:34:42 GMT

I've got a DR environment with 2x Sun StorageTek 6140 Arrays and 3 LUNs replicated between.

ARRAY PROD ST6140 & ARRAY DR ST6140

VOL01_PROD is replicated with VOL01_DR

VOL02_PROD is replicated with VOL02_DR

VOL03_PROD is replicated with VOL03_DR

When I do a disaster recovery and I promote the disaster recovery array as the primary storage, I can see correctly the LUNs from ESX but it wants to format the LUNs....

Do you have any ideas about why VMware tries to reformat the replicated LUNs?

Thanks in advance.

Jacques Neves

VMware ESX Server 3i 3.5.0 install error

Fri, 22 Aug 2008 18:18:02 GMT

Hi,

I'm getting the following message when installing VMware ESX Server 3i 3.5.0:

" Unable to find a supported device to write the WMware ESX Server image to ".

Any ideas?

Thanks,

pete

Monitoring ESXi with Python script

Wed, 20 Aug 2008 14:53:34 GMT

Vista Security Concerns

Thu, 07 Aug 2008 15:14:56 GMT

Host: ESX 3.5 - 64607
Guest OS: Windows 2003 Server – Standard Edition

Greetings,

We have a software vendor that has added a feature to their latest software release that stops the application if it detects that it is running on a virtual machine. Our software vendor tells us that they needed to disable this ability because of Vista security concerns. It seems that they have had difficulty with Vista running as a guest OS and disabled the application across the board due to this problem. Instead of identifying the guest OS and disabling if it finds Vista, they go strait to the platform and disable the application if they detect that it resides on a guest OS.

Perhaps I misunderstand virtualization, but are the guest VMs not autonomous? What security issues could they be talking about with Virtualized Vista? BTW, we have no plans to migrate to Vista.

Has anyone else run into applications that actively thwart hosted operating systems? Suggestions?

Thank you,

Curt

Recovering the Virtual Machines

Wed, 06 Aug 2008 20:01:07 GMT

I had 2 logical drive in my single esx 3.5 host. I have stored all the vm in the second logical drive. The first one contained ESX 3.5 OS. However my primary drive which contained the OS crashed and I had to replace that. I have installed fresh ESX 3.5 in the new drive now. The second logical drive where all the data about the VM stored is untouched. Can I get back all my previous VM's now?? Also how to see the data which is stored in the datastore.

Cheers.

Extracting ESXi from the installable ISO image

Wed, 06 Aug 2008 18:00:12 GMT

ESXi 3.5 Installable Virtual Appliance

cshanklin@vmware.com — Wed, 16 Jul 2008 00:50:47 GMT

I created an ESXi Virtual Appliance that I'm using for my own testing, hopefully others will find it useful as well.

This appliance requires ~~c-2767~~ or better (currently in Beta).

Additionally, you must download the ESXi installable ISO image. Later you will mount this ISO image as a virtual CD-ROM drive.

As if that weren't enough, your system must support VT Extensions and they must be enabled.

To get started, download and extract the attached zip file. Add the VM to Workstation using File -> Open and supplying the VMX file. Mount the ESXi installable ISO image you downloaded as a virtual CD-ROM drive. Then press play and watch ESXi boot!

Once you've booted, point your VI Client or other favorite management tool (I know you've been dying to try the VI Toolkit for Windows) at it. The login is root and the password is empty.

Please note that if you reboot, VMs will survive reboots on the datastore, but will not be registered on the ESXi system. If this happens it's pretty easy to re-register everything using a script.

Good luck, and let me know what you think.

Problem with network connectivity within virtual machines

Tue, 24 Jun 2008 19:01:55 GMT

Hello.. I have just installed ESX server and also installed Virtual Center in a vm, a linux virtual machine, and imported a windows 2003 system using converter. The virtual center machine can browse the web, ping, and ftp out to the internet. The other 2 boxes cannot ftp or browse web pages on the internet, but they can ping by name. THe network configuration is the same! No firewall setup, same router and dns servers. Does anyone have any idea what this may be? I am baffled.

esxtop CPU over 100% for a vm

Wed, 18 Jun 2008 13:32:33 GMT

Hello,

i' have on vm that taking approximately 150% of %USED of CPU when i run esxtop. how can i do for decrease this average.

( vm : windows 2000 server SP4 with SQL 2000 )

size : bi-cpu and 2 Go of ram

thanks

esx 3.01

Can i mix ESX 3.5 and ESXi 3.5 servers

Fri, 13 Jun 2008 11:56:19 GMT

Hi

We have a cluster running ESX 3.5 servers. We would like to buy new servers with ESXi 3.5 Embedded.

Can ESX 3.5 and ESXi 3.5 run in the same cluster without loss of function?

Regards

yes they can exist together in the environmen and run int he same DRS cluster as long as they have compatible cpus - this is a requirment fomr VMware for vmotion -

I haven't tried it so take this as an uninformed opinion... I'd say yes. You're probably limited by the VMotion constraints more than anything else.

Hello Brian, welcome to the VMware Community forums. HA would not be supported in a mixed cluster.

Details

VirtualCenter 2.5 Update 1 extends support for VMware High Availability (HA) to ESX Server 3i hosts, but currently requires some additional restrictions: swap space must be enabled on individual ESX Server 3i hosts (KB 1004177), and only homogeneous (non-mixed) clusters are supported at this time.

Solution

Homogeneous (non-mixed) clusters are fully supported when composed entirely of non-ESXi hosts, or entirely of ESXi hosts. More specifically:
Homogeneous cluster of ESX Server 3.0.x hosts or ESX Server 3.5 hosts or ESX Server 3i hosts are supported.
Heterogeneous cluster of ESX Server 3.0.x and ESX Server 3.5 is supported.
Heterogeneous cluster of ESX Server 3.0.x, ESX Server 3.5, and ESX Server 3i are currently NOT supported.

This document was generated from the following thread: Can i mix ESX 3.5 and ESXi 3.5 servers

Path failover on HP blade with Emulex HBAs

Thu, 12 Jun 2008 19:29:36 GMT

I'm having SAN reliability issues running ESX 3.5.0.1 on all my HP bl480c blade servers, each have two Emulex LPe1105 HBAs. The HBAs are hardwired to an HP Virtual Connect module, which is plugged in my SAN on a Silkworm. The luns are mapped from an EVA8000 which has active/active controllers. All firmware and software revisions are recent.

To make a long story short, I tested failover scenarios by unplugging the HBAs, one at a time, using the Virtual Connect. The link does go down but path failover fails to work as expected: it switches once, but the failed HBA becomes unusable, even after it's been reconnected for a while. Doing rescans won't help... although there is a link up, the luns cannot be rediscovered. Only resetting the card using HBAnyware, or rebooting the ESX server, makes it functional again. If I do similar tests on the exact same hardware, but with Win2003, it works well. So I'm thinking this might be an issue with the lpfc driver.

Does anybody have a similar setup and have tested this? I would be glad to hear from you.

I did open a call on this, but it's been lagging so that's why I'm poking around to see if I'm alone in this boat.

Thanks

Welcome ot the forum - Have you changed the failover policy for each LUN from the default MRU (Most Rectly Used) to Fixed? Also, when they are reconnected can you manually switch paths?

Check out http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_3_server_config.pdf for more information -

Path policy is set to Fixed. And esxcfg-mpath doesn't consider the paths as OK when I plug back the HBA so I cannot switch back. Running esxcfg-rescan once the HBA is plugged back in does not make them come back either, as a matter of fact it removes them, as if they were no longer visible at all.

Thanks

Use emulex firmware version 2.70A5

RHCE, VCP
Blog: http://computing.dwighthubbard.info

I said to myself "You've got to be kidding".... but I gave it a try with firmware 2.70a5 and it now works. I think it's the first time I actually have to downgrade a shipping firmware.

Kudos to Dwight. You made my day.

Thanks

That was exactly my reaction when VMware support told us that would fix the issue.

RHCE, VCP
Blog: http://computing.dwighthubbard.info

This document was generated from the following thread: Path failover on HP blade with Emulex HBAs

hardware CPU => Hyperthreading enabled (Not Active)

Mon, 09 Jun 2008 12:59:33 GMT

in bios hyperthreading enabled

=> what mean "Not Active"

thanks

~~mailto:jeanmarc.dierstein@orange-ftgroup~~

regards

ESX Host Time Differences / HA Cluster

Mon, 02 Jun 2008 21:02:40 GMT

I have a question in regards to if differences in time between two host can cause a issue in the midst of an attempted host failover? I have read somewhere that they recommend leveraging NTP for time sync, etc, but am just looking for a confirmation.

Thanks.

How to upgrade Qlogic HBA FW and BIOS on ESX 3.5

Thu, 29 May 2008 13:35:49 GMT

Problems with NFS

Wed, 28 May 2008 22:51:16 GMT

I am trying to share a directory on Windows 2003 using NFS to an ESXi 3.5 server. I get the error "Cannot open volume: /vmfs/volumes/...." I believe this is a problem with not having user name mapping setup on my windows 2003 machine. I have read other comments that have been posted about copying the password file from the ESX machine to the Windows 2003 server but with ESXi 3.5 I do not know how to copy files over.

You can use this: http://winscp.net/eng/index.php

Or this: http://www.bitvise.com/tunnelier

Or upload them via the datastore (browse datastore, upload / download links are at the top of that window).

What file should I be uploading or downloading? When I open my datastore all I see are virtual machines.

Hi Jason, if this is a test system, then you can login at the ESXi console and copy the files to a vmfs datastore on the host. You can then browse the datastore and get the files with the VI client.

1) At the ESXi console, press ALT-F1
2) The screen will switch to show some text. Type in unsupported and press enter. You won't see the text as you type it. You should then be prompted for the root password.
3) Enter cd /etc
4) Run ls and you'll see the files you want. You can copy them with a command like this - cp passwd /vmfs/volumes/<datastore name>/passwd
5) You'll now be able to see them with the datastore browser.

Now that I have the passwd file on my windows machine when I add it to the Microsoft Services for NFS and click the List UNIX Users I get <unmapped> UID = -2. It does not show any of the other accounts. When I open the file I see all the default accounts. I still receive the same error stated before.

Would it be possible to just use active directory to access NFS share on Windows 2003 by using this document? http://www.vmware.com/pdf/esx_authentication_AD.pdf-----
I just tried on my system and the other accounts show up OK. I'm running Windows Services for Unix 3.5 and my origial passwd file came from ESX 3.0 but I just copied over the file from 3i b82664. I followed the process above to get the file. Do you see 5 accounts when you open it on Windows?

The AD authenication is for inbound connection - i.e. with the VI client. Don't think that would help you here as the connection from ESX to NFS is made with the root account. ESX 3.5 has the Virtual Machine Delegate option which you can use to specify the account that will be use to access NFS shares, but that option seems to be missing in 3i.

I have attached some screen shots of what I get. I do not see the 5 user names. If I open the passwd file in notepad I do see the accounts listed.

I think I figured out the problem, I had to have the passwd file in both the group and the user box..

So now that I have this working on one ESXi 3.5 server will it not work on the other ones due to different passwd files on each ESXi 3.5 servers?

You'd need to have the root pasword set to the same thing.

I have the password file in both the group and user box but I don't see all the ESX names. I still have <unmapped> -2. Please help

Nevermind this link explains the process in great detail.

http://www.astroarch.com/wiki/index.php/Setting_up_Windows_Services_For_UNIX_(SFU)_NFS

This document was generated from the following thread: Problems with NFS

Fixing ESX boot loader problem

Tue, 27 May 2008 09:52:15 GMT

Fixing ESX boot loader problem

After a ghost clone to another disk, my ESX host in the lab came up with the much appreciated "GRUB" message at the boot loader prompt. Without an option to do anything. Turns out the GRUB MBR record is damaged, you cannot rerun the upgrade ISO CD image for this as it will not refresh that bit unless you re-install instead of upgrade.

So i found myself a Red Hat 9 install CD and performed the following:

Boot into rescue mode

linux rescue

Click defaults until the final screen where it tells you that it will not mount the drive as it didn't find any linux, but you are given the prompt that you need, click "Continue" and here you go a linux prompt.

Now suppose your boot disk is /dev/hda and the boot partition is /dev/hda1 and the root partition is /dev/hda2 (You can check this with fdisk -l for yourself.

mkdir /mnt/sysimage
mount /dev/hda2 /mnt/sysimage
chroot /mnt/sysimage

Ok, so now we are back in our system, but we still don't have access to our boot partition and the grub installer will need that.

mount /dev/hda1 /boot

Check that our boot folder isn't empty anymore

ls -lh

Now if everything went well you can put back the MBR record by issuing the following command.

grub-install /dev/hda

If it doesn't complain then you can now reboot the host and boot again from your normale storage.

PS: It stores info in /boot/device.map, check with cat if it is correct if you have issues.

Must OS of Windows Cluster reside on ESX local disk?

Sat, 10 May 2008 04:14:24 GMT

I was recently told by an integrator that if I build a Windows 2003 R2 Cluster across physical ESX hosts, I must store the Windows OS vmdk files on ESX local disk and not on the SAN.

Has anyone ever heard/read of this configuration?

Has anyone ever implemented a Windows Cluster in this manner across physical ESX hosts?

Thanks.

With Update 1 VM booting form SAN is now supported - http://www.vmware.com/support/vi3/doc/vi3_esx35u1_vc25u1_rel_notes.html

Hi weinstein5,
I was not referring to the ESX OS. I was referring to the Windows Guest OS. Sorry if I did not explain the situation clearly enough.

So, with that in mind.. any thoughts?

Thanks.

I have also heard this before but its not really relevent, if you read the following guide all is explained... http://www.vmware.com/pdf/vi3_35/esx_3/vi3_35_25_u1_mscs.pdf.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

Prior to ESX 3.5 Update 1m VNware only supported Microsoft Clusters in that configuration - where the VMs booted from systems disks stored on local VMFS volumes - with ESX 3.5 Update 1 VMware now supports the VMs booting from SAN LINs -

Support for Microsoft Cluster Service (MSCS)

VMware ESX Server 3.5 Update 1 supports Microsoft Cluster Service. Support is similar to ESX Server 3.0.1 with the following additions:

Both 64 bit and 32 bit Windows 2003 guests are supported with MSCS.
Boot from SAN for VMs using MSCS is now supported.
Majority Node Set clusters with application-level replication (for example, Exchange 2007 Cluster Continuous Replication (CCR) is now supported.

Hi alanrenouf,

I read that document some weeks ago, it didn't answer my specific question. We've been running a windows cluster for file and another windows cluster for exchange 2003 on ESX 2.5 for over three years with all guest OS vmdk files up on the san. Never had a problem.

Hi weinstein5,
That's very strange. We've been running a windows cluster for file and another windows cluster for exchange 2003 on ESX 2.5 for over three years with all guest OS vmdk files up on the san. Never had a problem.

If putting the guest OS vmdk files on the SAN for windows clusters was not supported in previous versions of ESX, did that really stop/deter most companies from running windows clusters that way?

key word in my explanation is 'supported' by VMware - does not mean it will not work - and no I do not think that stiooed people form doing it -

I agree, its always been a support issue until Update 1

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

The problem appears to be related to disk timeouts. While it worked previously about 98.5% of the time, there is a scenario in which the node boot disk is located on a SAN, along with the quorum/data shared disks. In that scenario, the boot disk connection is "lost" from the SAN, triggering a cluster failover to the passive node, but the connection returns to the boot disk, in which the master tries to read/write to disks it "knows" to be mastered on it. This is now a split-brain scenario which can cause many an issue, as some will know if they've encountered it in the physical world. This why Update 1 includes timeouts related to MSCS that "fixes" this scenario, so the limitation for disks to be local is now gone.

Hope that makes it clear,

-KjB

This document was generated from the following thread: Must OS of Windows Cluster reside on ESX local disk?

Vi3.5 VM Backup Guideline

Fri, 09 May 2008 10:02:45 GMT

Can I combine two etherchannel "pipes" onto one vswitch?

Sun, 04 May 2008 14:25:59 GMT

I am planning to have two dual port Intel PCI NICs in an ESX Server. The server only has 4 PCI slots, and the other two slots will be used by single port HBA adapters for HA reasons.

Initially I was just going to have port1 from NIC1 plugged into physical switch1, port2 from NIC2 plugged into physical switch2 and have both ports on the one vswitch with IP HASH based load balancing. Easy and simple with HA in place on the physical side of the network. I would just use External Switch Tagging (EST) so no special config required on ESX.

However someone mentioned why not use etherchannel for a bigger "pipe".

My question has two parts:

1. If I have port1 from NIC1 plus port1 from NIC2 both plugged into physical switch1 and etherchannel them together, and then I have port2 from NIC1 plus port2 from NIC2 both plugged into physical switch2 and etherchannel them together, can I put all this (effectively just two big "pipes") on the one vswitch?
2. Can I then use several VLANS on these ethernal channel "pipes"?

I've never used etherchannel before.

Has anyone actually done this in practice, or know of some official doco that explains how this is both possible and supported with VMware ESX Server?

Thanks in advance.

There is some really good information about this topic in this discussion: http://communities.vmware.com/message/902563#902563

Yes you can - you would create a Nic Team on a virtual switch - check out the networking section of http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_3_server_config.pdf

The link http://communities.vmware.com/message/902563#902563 simply takes me to a VMware Outlook Web Access page (and my logon for this forum does not work on that page).

Are you able to provide a different link to the same info?

Thanks.

Yes I have read (and again just now re-read) the Advanced Networking chapter of vi3_35_25_3_server_config.pdf. I understand it is really only outlining the basics of what can be done.

However it seems to imply you can only create one team on a vswitch or port group. I understand that scenario, but the scenario I'm asking about has two separate teams on the one vswitch or port group. By that I mean, I only want each VM to have one NIC. If I didn't explain the scenario feel free to ask me to elaborate.

I still don't know if this is possible. It would be great to hear from someone who has done this in the past, if indeed anyone has.

Also, that doc makes no mention, at least not that I could see, if you could etherchannel NICs together and then VLAN ontop of that. It was suggested to me that if you etherchannel NICs together then you can only use them on one VLAN due to the logic on the physical switch side needed to maintain the etherchannel on those ports.

Looking forward to replies from anyone that knows networking inside out.

Thanks.

I've copied it here for you to read::8}

I would like to clear up some misconceptions surrounding link aggregation and ESX. One of my colleagues, Dan Whitman, wrote up this very nice summary of our stance regarding link aggregation. Hooray for Dan! Seriously, thanks Dan for the clear and concise summary.

Unfortunately, we don't document this very well but we do in fact support 802.3ad in specific configurations. We have to be careful when we refer to LACP generically because there are two modes which can be employed: Static and Dynamic and both are in the 802.3ad IEEE standard. While the whole premise of the LACP standard is to enable dynamic "routing" of Layer 2 traffic, there is a facility built into the standard to allow the forcing of static paths. Interestingly enough, the little documentation we have says that while we support 802.3ad, we do not support LACP. The appropriate statement should be that ESX doesn't support the dynamic aspect of the standard but does support static mode in the 802.3ad specification.

I have worked through this conundrum with several customers and the configuration below has been proven to work in single switch and multi-switch environments. Note that while spanning-tree is not needed simply because there is no way to link vSwitches together (without doing extreme networking in the VMs), enabling spanning-tree is the only way I've been able to find that allows the enablement of portfast which trims off 30secs of downtime during port failovers.

At the end of the day, ESX 3.x does support 802.3ad and LACP in STATIC configurations. Below are the configurations of both the Cisco switch (6500 in this case) and peer vSwitch in ESX to support Link Aggregation Control Protocol (802.3ad) and port trunking/grouping (Cisco Fast EtherChannel - FEC).

Supporting links

http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf

Cisco switch example commands to group 2 physical ports in 1 trunk group

interface Port-channel10

description ESX Server 1

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

spanning-tree portfast trunk

interface GigabitEthernet3/1

description ESX Server 1 NIC vmnic0

speed 1000

duplex full

switchport

switchport mode trunk

spanning-tree portfast trunk

channel-group 10 mode on

interface GigabitEthernet3/2

description ESX Server 1 NIC vmnic1

speed 1000

duplex full

switchport

switchport mode trunk

spanning-tree portfast trunk

channel-group 10 mode on

vSwitch example screenshot showing the necessary configuration to accommodate the Cisco port configuration above

dan whitman - system engineer - air force team - vmware

Hi cpqarray,

Thanks for the explanation about the static and dynamic aspects of 802.3ad (etherchannel). I was not aware of that before.

I have downloaded and read the virtual_networking_concepts.pdf document, along with the info you provided, and although it is good to know about the simple scenario of just one etherchannel team going to a single port group on a vswitch, which seems to be the only example in any doco I have read or any tech I've conversed with, it still doesn't answer my initial question, which is:

Can I put two separate etherchannel teams (the reason for two etherchannel teams is team1 goes to physical switch1 and team two goes to physical switch1 - only because I need physical HA and I read some VMware doco that says you should not etherchannel across different physical switches, or maybe it said it's just not possible) onto the one port group on a vswitch inside ESX Server?

Looking forward to your reply.

PS. The virtual_networking_concepts.pdf doco didn't make it clear whether or not I can still use multiple VLANs across an etherchannel team - do you know if I can?

This thread should not be in the VCP community. Moving to appropriate product community.

---
Badsah Mukherji
Senior Community Manager, VMware Communities

Hi,

You can not place two NIC teams which are on separate trunks on the same vswitch portgroup they will need to be all on the same trunk/team or all separate 802.1q vlan ports on the same team.

Yes you can have multiple VLAN's on the FEC trunk but I would suggest you change the native vlan to something other than 1 if you have not already.

Just to clarify 802.3ad Link Aggregation is not the same as FEC (cisco Fast Ether Channel)

802.3ad is an IEEE protocol standard and FEC is a cisco proprietary protocol. Cisco can do both of them.

Do you really need the trunk?

If none of your VM's have more than a single 1G vNIC per portgroup then it is not required and is more complex.

You can cross separate physical switches with a trunk the above example will work

This is a great helpfull ppt

http://www.vmware-tsx.com/download.php?asset_id=41

Message was edited by: mike.laspina - word omitted - portgroup and added one more answer and link.

Hi Mike,
Thanks for clarifying that. So it appears it's a no go. The main idea for the 802.3ad Link Aggregation was simply to give the VMs (which only have one vNIC each) more bandwidth. However I'm also required to provide multiple paths across different physical switches - so it does appear I cannot do both. Darn. Looks like it will have to be just one port per physical switch, in which case I may as well stick with the default port based load balancing.

You mentioned I can trunk across different physical switches - so for that I would plan to use one port per physical switch (different ports than those used for the VM network) and I would have 3 VLANS on this vswitch (vmkernel vmotion, service console and heartbeat for our Microsoft Clusters). We only plan to use FC SAN (no iSCSI or NFS) so no need for two separate vmkernel networks (vmotion network separate from iSCSI network).

So can you confirm ESX 3.5 does not support etherchannel, but it does support 802.3ad Link Aggregation?

Also, are you aware of anyone who has used two physical switches for the VM network, and yet has also teamed NICs together for a larger pipe? If not, does that mean that every instance of NICs teamed for a single large pipe has always been with just one physical switch, meaning they have a central point of failure? That doesn't strike me as best practice, unless I'm missing part of the picture somewhere...

Looking forward to your reply.

Thanks.

You can achieve what you are looking for by using 802.1q port trunking and NIC teaming and you will have the 2G bandwidth over the team.
2 Adapters for VM traffic teamed across the two physical switches

2 Adapters for SC VMotion teamed across the two physical switches

It is possible to do this with 802.3ad but it's a complexity that would just give you difficult trouble shooting and you don't really need it.

I have this type of config on HP Procurve, just more of and at a larger scale and I have some 802.3ad static trunk configurations working as well.

I have 802.3ad trunks across the switches so there are no single points of failure.

ESX 3.5 works on static FEC and 802.3ad configurations it does support(use) LACP and PAgP dynamic protocols on the teamed NICs.

Hi Mike,
Please forgive my ignorance, but I thought if I use only 802.1q port trunking and NIC teaming (without any link aggregation or fast etherchannel) then I will not have a single 2G bandwidth over the team, but rather I'll have two separate 1G bandwidths, ie the most bandwidth any one machine could ever use at any point in time is just 1G - or is that not correct?

Thanks in advance.

ServerAdmins wrote:
Hi Mike,
Please forgive my ignorance, but I thought if I use only 802.1q port trunking and NIC teaming (without any link aggregation or fast etherchannel) then I will not have a single 2G bandwidth over the team, but rather I'll have two separate 1G bandwidths, ie the most bandwidth any one machine could ever use at any point in time is just 1G - or is that not correct?

Thanks in advance.

You are correct. The only way to possibly get more than one pNIC's worth of bandwidth out of a single VM is to use IP Hash as your load balancing mechanism and have your pSwitch configured for 803.3ad trunking. In that case, each IP conversation could - possibly - use a different pNIC. My question is do you really have a VM that is using one pNIC worth of network? I would be surprised if you do. Also, consider your pSwitch infrastructure - what is the connectivity between your pSwitches? What is the utilization on those links? I doubt their saturated. If your ISL is not pushing significantly more than one pNIC's bandwidth then you probably don't need to complicate your environment with link aggregation to your ESX hosts.

Ken Cline
Technical Director, Virtualization
Wells Landers
VMware Communities User Moderator

With the port ID policy the load balancer with try to spread the VM across the available adapters and this will allow you to use the 2G sum over multiple VM's. A single VM will only get a maximum of 1G (More like 500MB in the real world).

Hi Mike,
Thanks for the explanations. I like to know my options so I can make an informed decision.

One more question in this Load Balancing (LB) area:

From what I understand when I have two NICs trunked together on the one vswitch, if I use port based LB then a VM will choose a NIC when it powers on, and will stay with that NIC till it powers off or is moved to another host. However, if I use IP based LB then each time a VM needs to talk to a machine external to the ESX host on which it lives, it could choose either of those two trunked NICs for that particular conversation, and only stay with that NIC for that conversation. In other words the VM has the capability to choose either NIC of those two trunked NICs each time it starts a new conversation. This sounds like much more even use of the two NICs.

Is this correct? If not, can you please explain why?

Thanks.

Yes that is correct, portID policy will always use the same physical path unless a failover event occurs. The use of MAC and IP hash are not recommended unless you configure 802.3ad static based trunking on the physical switches. Keep in mind that hashing will have additional CPU load on the ESX server, but it is usually not an issue. As well hashing allows you to control outgoing traffic but not incoming. 802.3ad over to separate switches will be more complex and is possible as I have indicated earlier. You would need to carefully configure the policies to control portgroups in a manner that does not allow it to split across the physical switches. I have done this and it works. Issues on a portgroup will occur during a failed state if you do not prevent the path split. If one switch goes bad due to reasons other that complete failure is when you have the big issues.

NB. Awarding points is like saying thanks.

Here is some good info on it.

http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf

Thanks for the note about awarding points. Correct answer and 10 points definitely going your way for your help on this thread.

Where can I find out what the little icons/symbols mean that are displayed next to most of the names of people that post on this forum? I noticed I have a flag and you have a crown How many icons are there?

Thanks.

This document was generated from the following thread: Can I combine two etherchannel "pipes" onto one vswitch?

Auto Rebooting of ESX Server & Vservers

Thu, 01 May 2008 14:05:05 GMT

I know in Windows Server 2005 you could schedule the individual virtual servers to reboot and then finally, after a set number of seconds, have the main box reboot. Is there a way to do this with ESX? We have 6 virtual servers running on our box; I need the individual servers to reboot and then the main box reboot automatically at a set time every night.

Is this possible?

You could reboot the box with the shutdown command I believe. For example if you wanted to reboot ESX at 8:00

shutdown -r 8:00

Anyway to automate that? Also; do you have to shut down the vservers first? Our end result needs to be this: The box needs to reboot automatically and come back on; also, the vservers need to start back up automatically.-----
Sure you could create a cron job that did it for you in your cron daily tab you could put an entry that would call a script.

crontab -e

0 20 * * * ~/myshutdownscript -h now

Then write a script to shutdown the virtual machines and reboot the box (Oh gosh now I have to try and write a script but here goes:)

To shut down the VMs

for vm in `vmware-cmd -l` ; do
#echo "VM: " $vm
for VMstate in `vmware-cmd "$vm" getstate` ; do

If the VM is power ON

if ; then
echo " "
echo "Found this VM: " $vm
echo "it is stille on but now i will turn it off"
vmware-cmd "$vm" stop trysoft

fi
done
done

shutdown -r now

(go here for more examples http://www.tooms.dk/?page=http%3A//www.tooms.dk/forum/topic.asp%3FTOPIC_ID%3D131

The following thread has a script for shutting down VMs either hard or soft:

http://communities.vmware.com/thread/62864

At the end of it you could put the ESX server shutdown command.

As far as automation goes, put the script into the cron. "man crontab" for more info.

I have a script that powers down all VM's on an ESX host then shuts down the ESX server, you can modify this script to reboot the ESX host after all vm's are powered off. Then create a scheduled task to "Change the power state of a virtual machine" to power on your vm's. I have not tried to schedule my power down script, if you can figure that out I think you can accomplish what you want.

This document was generated from the following thread: Auto Rebooting of ESX Server & Vservers

How to inlcude an MD5 hashed password in your VMware ESX installation script

rdiphoorn@vituality.com — Fri, 25 Apr 2008 05:58:47 GMT

If you want to add a user from an automated installation of a VMware ESX server, you will have to include an hashed password.

To generate this password, just login to an existing VMware ESX server, and follow the next steps:

Type: phyton (this will start up the python interpreter);
Type: import crypt; print crypt.crypt("password","salt")

This step will create an hashed password; copy the output in your installation script.

It will look something like this:

ESX-server with EMC mirrorview

Wed, 23 Apr 2008 12:35:53 GMT

Hello,

I have a special configuration issue!
My intention is to mirror LUN's, stored on EMC Clariion with Mirror view to a backup Clariion system.
The LUNS are containing all data and configuration files from virtual machines running on ESX-3.5 server.

If the ESX server or the storage should fail, the Idea is to assign the mirrored LUNs to a backup ESX server
and activating the LUN'S on this server. The pure assingment of Luns is not the problem,
But I have no Idea how to activate (import) the virtual machines on the backup server.

Is this scenario realisable and how can I do this

in advance many thanks for every constructive answer

Lucksch

ESX hung after SCSI Reservation Conflicts

Mon, 14 Apr 2008 20:34:17 GMT

Hi, My ESX Server got hung after too many SCSI conflict errors. I am not even able to take putty seesion at that time. Reboot solved the problem but logs not even genearted for that specific time before reboot. Is it possible that ESX got hung due to many SCSI conflict errors ?

Configuration : NTP

Fri, 11 Apr 2008 08:39:29 GMT

Teaming NICs in ESX - how to choose a switch?

lkubin@coma.cz — Tue, 01 Apr 2008 21:50:50 GMT

By default, ESX server balances all outgoing traffic based on IP address pair through multiple NIC ports configured in a single vSwitch. You don't need any switch support for this feature to work.

You need the switch-level support however to let both the outgoing and incoming traffic to be balanced and thus receive increased overall throughput.

Read the full article at Kukacz Notes blog.

Creating a scripted ESX 3.5 server build

Tue, 01 Apr 2008 08:02:30 GMT

Enable Syslog

Mon, 31 Mar 2008 17:57:48 GMT

How do I enable logging on ESX 3.5.0 and redirect all messages to my existing kiwi syslog server?

how to re-construct disk descriptor file?

xiaoyu@bestinfo.com.cn — Sat, 29 Mar 2008 14:48:49 GMT

as you know, every vmdk consists of 2 files, one is xxxx.vmdk, the other is xxxxx-flat.vmdk.

the former is disk descriptor file, the later is the disk include the real data.

if for some reason, user delete the descriptor file, how to restore it from the xxxxx-flat.vmdk?

Just use the VI client to reattach the file back to the VM.

You can restore it from the log and you can restore it by "calculating" its contents.

your method does not work, if there's only flat file without the descriptor file, when vi client browse the directory, it will display no vmdk files.

agree with you, can you provide the detail approch how to do this.

i read the ppt from TSX 2007, "top support issues and how to solve them, part 2", it says use "grep -i rw xxxx.vmdk" to get the size, but when i use it, nothing useful displayed.

Oh right I see what you mean. The following steps will guide you to recreate your vmdk's:

Determine the hard disk sizes of your original VM - this information should be in the logs files mentioned by previous poster.
Create a new VM with the same number of hard disks as your old VM, and the exact same sizes using the log info.
Once created, use Putty or some tool to navigate to the directory of new VM.
Copy the newly created vmdk files to your existing directory
Edit the new VMDK's with the existing flat.vmdk file names.
Load the VM in your VirtualCenter. You should now be able to add the flat.vmdk to your VM

Thanks for the post. Apologies for not reading your original post more closely.

thank you and your method is very easy to understand and implement. i successfully do a test, let me add some notes to your steps.

1. Determine the hard disk sizes of your original VM - this information should be in the logs files mentioned by previous poster.

just use ls -l to determine the disk size, in my example, i have 2 disks, one is 6457893888 bytes, the other is 5368709120

2. Create a new VM with the same number of hard disks as your old VM, and the exact same sizes using the log info.

when you create a new VM, the key is disk size and guest os type. the guest os type you can get it from vmware.log, or you can ask the user who use it.

for disk capacity, just use the size get from step 1, and divide it with 1024*1024*1024, for 6457893888, the result is:6158.7275390625

for 5368709120, the result is just 5. notice the unit is MB, so type the exact value in the input box.

3. Once created, use Putty or some tool to navigate to the directory of new VM.
4. Copy the newly created vmdk files to your existing directory

this should be: copy the vmdk flat files in your existing directory to the newly created VM dir
5. Edit the new VMDK's with the existing flat.vmdk file names.
6. Load the VM in your VirtualCenter. You should now be able to add the flat.vmdk to your VM

just power on the VM in virtualcenter

This document was generated from the following thread: how to re-construct disk descriptor file?

Working Backup Solution via ESX 3.0.1 with HP MSL2024 Tape Library

Thu, 27 Mar 2008 10:20:58 GMT

I have a slight problem where I've been assigned to look into creating a virtual backup media server (to run with W2K3 Standard Edition and Symantec Backup Exec) to connect to a directly attached HP StorageWorks MSL2024 Tape Library (1 x Ultrium 960 tape drive) - the physical ESX 3.0.1. host will be running on an HP ProLiant DL380 G5 server with the SCSI HBA being an HP Single Chanel Ultra320 (PCI Express).

Unfortunately until I get onsite to look at it (at least another two weeks) I'm stuck with no hardware to play with the same configuration and I was just wanting to see if anyone else has managed to get this working successfully AND if so what steps were made to get it working.

Any info you can provide would be greatly appreciated and accepted as I'm not a full fledged VMware ESX administrator plus there is several posts that show varying results for other vendors tape drives/libraries.

Hello,

I would NOT connect the tape library to your ESX server. I would use a remote physical box to perform backups. The reasons are really two fold.

1) If the passthru scsi device craters (which is is want to do) then
the ESX server SC goes with it.

2) I do not like the overhead this puts on the ESX server.

I have done it both ways and a remote server works best. I use a DELL PowerVault 128T and it is very similar to the MSL libraries (it is actually an HP library rebranded as DELL).

Best regards,
Edward

I agree for our backups we send them to a seperate backup server which has the tape library attached to it. I don't like attaching the tape library directly to the ESX host mainly for the fact if you gave problems with the device and a server reboot is necessary you are now effecting all of your guests.

Also for our guest backups we use esXpress.

This is what worked for us. You may need to get an Adaptec 29320LPE SCSI card

The problem:

The new breed of HP (and probably other makers) LTO Auto-changer tape libraries are now multi LUN on the SCSI bus – that is both the tape driver and the media changer have the same SCSI ID with different LUNs.

Our installation:

HP Proliant DL380 G5 (only supports PCI Express)
HP 1/8 Ultrium 920 G2 Tape Autoloader
VI3 ESX 3.0.1 (under test, yet to test 3.0.2)
Virtual Centre 2.1
Veritas / Symantec Backup Exec 11

The two basic configuration restrictions on ESX 3 are:

1. There is no support for multi LUN SCSI devices on SCSI pass-through devices (tapes).

2. Only Adaptec SCSI cards are supported for pass-through devices. (see VMware HCL)

For a few days we thought that we ‘could not get there from here!’

The first part of the solution came when we realised that ESX internally does recognise multi LUN SCSI devices when you install the appropriate Adaptec card. It creates two device files, one for each LUN on the SCSI adapter.

When ESX maps SCSI devices to the guest virtual adapter it is maps to device files not physical adapter devices. That is ESX is quite happy to map the two device files (same ID different LUN) to two separated virtual SCSI IDs on the virtual adapter in the guest.

The result is the guest gets to see both devices but now they have different SCSI IDs – virtual that is.

The second part came in the form of the latest version and patches of Backup Exec which has drivers for the new HP library devices.

The solution:

1. Purchase an Adaptec 29320LPE SCSI adapter – supported on ESX and supports multi LUN devices.

2. Install the adapter and media library, power on the tape library and boot the ESX server. Note it boots, finds the new hardware and re-boots.

3. Verify that the both library devices have been found and the ESX SCSI devices created.

On the ESX console logon as root.

cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 04 Lun: 00
Vendor: HP Model: Ultrium 3-SCSI Rev: D22W
Type: Sequential-Access ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 04 Lun: 01
Vendor: HP Model: 1x8 G2 AUTOLDR Rev: 1.30
Type: Medium Changer ANSI SCSI revision: 05

Note the two SCSI devices –

ID = 4 LUN = 0 – tape drive
ID = 4 LUN = 1 – media changer

ll /proc/vmware/scsi/vmhba1
total 0
-rw-r--r-- 1 root root 0 Sep 24 09:14 4:0
-rw-r--r-- 1 root root 0 Sep 24 09:14 4:1
-rw-r--r-- 1 root root 0 Sep 24 09:14 stats

Note the two SCSI device files – 4:0 and 4:1.

On the HP library you can use the Web management interface to change the SCSI ID of the library but not the LUNs, the tape drive is always LUN 0 and the media changer LUN 1.

4. In VI Client add the SCSI devices to the Guest VM. The VM should be shutdown at the time.

Select the VM guest
Edit settings
Add

SCSI Device
Set - Tape – “HP “ – to device to SCSI(0:4)
Set - Media – “HP “ – to device to SCSI(0:5)

Note the lines added to the .VMX file for this guest –

scsi0:4.present = "true"
scsi0:4.deviceType = "scsi-passthru"
scsi0:4.fileName = "/vmfs/devices/generic/vml.0201000000500110a00090d7ed556c74726975"
scsi0:4.allowGuestConnectionControl = "false"
scsi0:5.present = "true"
scsi0:5.deviceType = "scsi-passthru"
scsi0:5.fileName = "/vmfs/devices/generic/vml.0208010000500110a00090d7ec317838204732"
scsi0:5.allowGuestConnectionControl = "false"

5. Boot the VM and verify that Windows sees the new devices – Device Manager should have both the Tape and the Media Changer.

6. Install Backup Exec build 7170 plus Hot Fix 16 or later.

7. Verify access to the tape and media library.

Note –

If the tape library is powered off when ESX boots, attempts to power on the guest OS will fail with .VMX file errors on the virtual SCSI devices.

A SCSI pass through tape and library can only be mounted to ONE VM guest OS.

This document was generated from the following thread: Working Backup Solution via ESX 3.0.1 with HP MSL2024 Tape Library

HP tape library perf slow in ESX 3.x setup

Thu, 27 Mar 2008 10:19:04 GMT

Hi ,

I have two esx 3.0.1 servers setup with HP MSL 2024 tape library which is recently connected to one of esx servers.

We firing the backup from VM through Veritas backup software. we are facing slow performance with backup.

Pls guide me to troubleshoot the same.

I have a few questions to start off.

1 - Is the Tape Library connected via a non-RAID Adaptec controller?

2 - Are there any other devices connected to the same controller as the Tape Library?

3 - How many VMs are connected to this Tape Library?

Also, run esxtop in batch mode to gather performance data when backups are running. While this is happening use Remote Performance Monitor to gather data from inside the VM running the backup software as well.

Compare the data output from it and see if the data points to an obvious bottleneck. From there you can focus on that component for configuration.

Faisal

Hi,

Also, what disks are being used as backup source, and what is the tape standard of this library (LTO2?). If you cannot keep the buffer filled up in the tape unit, it will continuously rewind and resync, which will dramatically impact performance.

I run a similar setup, with an LTO1 HP tape library (8slots). Two VMs, one carries Symantec Backup exec, the other is a Windows 2003 file server. I get about 900MB/min backup&verify speed if I run a full backup (differential backups run slower off course)

Please post the CPU loads on all affected VMs, config of these VMs (opsys, assigned memory, number of vCPUs), how fast the backup actually runs ("slow performance": How slow is slow?), any bottlenecks (for example network). Config of your ESX hosts (memory, number of CPUs, numebr of NICs, NIC setup)

The tape library is SCSI attached to the ESX host and you are presenting the device through to the VM right?

Don't try and trouble shoot it. Find another machine and run the backup of that. It is not recommended to run backup to a local device. There are some circumstance where its okay but as you have seen the load can be high and performance low. Likewise for running the backup server in the VM. Have a look through the Virtual Machine Backup Guide.

Have you

Checked you are running a supprted SCSI controller. VMware supports attaching SCSI drives to the ESX Server using Adaptec SCSI adapters. Using other adapters, such as LSI MPT‐Fusion SCSI, is not supported.
If you are using a tape drive library (versus using a stand‐alone tape drive), the library must be multitarget, and not multi‐LUN.
Set the tape drive’s virtual target ID in the virtual machine’s configuration to be the same as the physical target ID.
Check the SCSI terminators on the tape drive, that can often cause them to go slow.

Considering awarding points if this is of use

This document was generated from the following thread: HP tape library perf slow in ESX 3.x setup

ESX 3.0.2 Patch loading for dummies

Mon, 17 Mar 2008 18:05:31 GMT

This is the procedure we used to update all our 3.0.2 hosts, dont ask why we are not on 3.5 IBM LS20's dont support 3.5!!!
Uploaded all patches to SAN

Go into VMware Infrastucture Client
Click on the down arrow next to Inventory and select "DataStores"
Right Click on SanStorage-VMFS00-Tempate and select Browse
Double Click 302-Patches
Click the Upload button and upload all required patches.

Putty into any ESX Server and to the following (Example used as we updated servers)

cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches

(Unzipped all patches)
tar -xvvzf ESX-1002424.tgz
tar -xvvzf ESX-1002434.tgz
tar -xvvzf ESX-1002974.tgz
tar -xvvzf ESX-1003364.tgz
tar -xvvzf ESX-1002425.tgz
tar -xvvzf ESX-1002435.tgz
tar -xvvzf ESX-1002975.tgz
tar -xvvzf ESX-1003365.tgz
tar -xvvzf ESX-1002426.tgz
tar -xvvzf ESX-1002965.tgz
tar -xvvzf ESX-1002976.tgz
tar -xvvzf ESX-1003366.tgz
tar -xvvzf ESX-1002427.tgz
tar -xvvzf ESX-1002966.tgz
tar -xvvzf ESX-1003175.tgz
tar -xvvzf ESX-1003374.tgz
tar -xvvzf ESX-1002428.tgz
tar -xvvzf ESX-1002967.tgz
tar -xvvzf ESX-1003179.tgz
tar -xvvzf ESX-1003513.tgz
tar -xvvzf ESX-1002429.tgz
tar -xvvzf ESX-1002969.tgz
tar -xvvzf ESX-1003359.tgz
tar -xvvzf ESX-1003514.tgz
tar -xvvzf ESX-1002430.tgz
tar -xvvzf ESX-1002970.tgz
tar -xvvzf ESX-1003360.tgz
tar -xvvzf ESX-1003515.tgz
tar -xvvzf ESX-1002431.tgz
tar -xvvzf ESX-1002971.tgz
tar -xvvzf ESX-1003362.tgz

Done Preping the patches for installation

(Applying patches)
No putty into the server you wish to patch

First check what patches are loaded on the server
type
esxupdate query

Now proceed to install patches
(Take note we are installing all patches in accession and not rebooting until the last patch has been loaded)
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002424
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002431
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002435
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002434
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002426
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002430
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002428
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003175
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002976
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002975
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002974
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002971
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002970
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002969
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002967
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002966
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002965
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1002427
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003374
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003179
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003366
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003365
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003364
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003362
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003360
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003359
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003515
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003514
esxupdate --noreboot update
cd /vmfs/volumes/SanStorage-VMFS00-Template/302-Patches/ESX-1003513
esxupdate --noreboot update

Once completed verify all patch instalations
at root type

esxupdate query

--root@VMSX21 ESX-1003513--# esxupdate query
Installed software bundles:

Name

Install Date --- --- Summary ---

3.0.2-61618 21:56:25 03/17/08 3.0.2 Update 1 of VMware ESX Server
ESX-1002424 22:06:38 03/17/08 VMotion RARP broadcast to multiple vmnic
ESX-1002431 22:07:45 03/17/08 Incorrect ports to LSI Loigic driver.
ESX-1002435 22:09:06 03/17/08 Update VI client to the same as VC202u1.
ESX-1002434 22:10:23 03/17/08 Update WebCenter to the one of VC202u1.
ESX-1002426 22:11:18 03/17/08 vdf -h produces incorrect results.
ESX-1002430 22:12:21 03/17/08 vmxnet is not loaded by default.
ESX-1002428 22:13:29 03/17/08 Qlogic firmware update.
ESX-1003175 22:14:24 03/17/08 Updated the ESX Update Utility
ESX-1002976 22:15:25 03/17/08 util-linux security update
ESX-1002975 22:16:33 03/17/08 Samba security update
ESX-1002974 22:17:37 03/17/08 I/O failures due to excessive reservatio
ESX-1002971 22:18:44 03/17/08 Perl security update (RHSA-2007:0966-01)
ESX-1002970 22:19:57 03/17/08 Patches remote root exploit in OpenPegas
ESX-1002969 22:20:56 03/17/08 Updated OpenSSL packages for security fi
ESX-1002967 22:21:55 03/17/08 tzdata enhancement, with timezone update
ESX-1002966 22:22:57 03/17/08 COS kernel's SCSI layer may lead to Oops
ESX-1002965 22:23:59 03/17/08 Megaraid2 driver fix for UNISYS platform
ESX-1002427 22:25:02 03/17/08 Fix the firmware of bnx2 (BRCM 5709) dri
ESX-1003374 22:25:59 03/17/08 Tools installer update to support RHEL5.
ESX-1003179 22:27:04 03/17/08 Remote-console black-out resolved
ESX-1003366 22:28:27 03/17/08 H/W iSCSI: System PSOD
ESX-1003365 22:28:35 03/17/08 VM hangs on Harwich and Foxecove
ESX-1003364 22:29:40 03/17/08 Autostart for VM works intermittently
ESX-1003362 22:30:35 03/17/08 Security fix for aacraid driver vulnerab
ESX-1003360 22:31:27 03/17/08 Python security update
ESX-1003359 22:32:27 03/17/08 Samba security update
ESX-1003515 22:33:24 03/17/08 Fix for trunking VLANs with igb driver
ESX-1003514 22:34:31 03/17/08 tg3 driver updates
ESX-1003513 22:36:59 03/17/08 Fixed issue of vpxa crashing during reco
For a differential list of rpms, use the -l/--listrpms option.

Once you have verified the installation of the patches reboot the server

type reboot and press enter

After the load of all the patches i found that we were unable to reconnect the machines to the VI console, with the error
"Unable to access the specified host. either does not exist, the server software is not responding, or there is a network problem"

To fix this i had to putty into the ESX box
Log on as root
Run "rpm -qa | grep vpxa" to see what vpxa installation was done
Example
root@VMSX01 root--# rpm -qa | grep vpxa
VMware-vpxa-2.5.0-64192

run "rpm -e <Iput return from rpm -qa here>" to uninstall the software
Example
root@VMSX01 root--#rpm -e VMware-vpxa-2.5.0-64192
Then restart the service
run "service mgmt-vmware restart"

I had some machine i had to to this twice and make sure you have removed the ESX machine from VI completely before you run above and reconnect.

recommanded hardware requiremet for esx server version 3.5

Thu, 13 Mar 2008 11:14:44 GMT

Could any body mail me recommande hardware requirement for esx server version 3.5

gurbachan.singh@tcs.com

Virtual Center 2.5 and Oracle 10.2.0.3 (64bit) compatibility

Wed, 12 Mar 2008 19:12:33 GMT

Does anyone know what the hold up is on certifying Virtual Center 2.5 and Oracle 10.2.0.3 64bit? Was looking to upgrade to 3.5/2.5, but we only run 64bit Oracle in our Production environment.

*
In this document

http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_installation_guide.pdf

all supported Databases are listed.... (Page 19)

*

Oracle 10g Standard Release 2 (10.2.0.1.0) Oracle 10g Enterprise Release 2 (10.2.0.1.0)

First apply patch 10.2.0.3.0 to the client and server. Then apply patch 5699495 to the client.

Regradless of 32 or 64 bit installation or platform its supported. This is because your SQL command returns the same values redardless of the underlying hard and software architecture. -> means .... VC even use the same scripts... if it is 9i or 10g.

But please read the release notes too... There are some hints how to configure the schema.... (priviliges because CONNECT ROLE changed and so on)

Regards,

I'm already running 10.2.0.3 in my Virtual Center 2.x environment and it's fully patched. While I agree that 64bit "should" work, there's obviously a reason that the compatibility matrix below has "NO" for 10.2.0.3 64bit and Virtual Center 2.5. My question is when will it officially be supported by VMware, my company does not run unspported configurations for critical applications. Thanks.
See Page 5 - Table 6 (continued)

http://www.vmware.com/pdf//vi3_35/esx_3/r35/vi3_35_25_compat_matrix.pdf

You are absolute right. No support for 64bit atm. I'll find out if 64bit will be supported in the future and post the answere here.

Regards,

Hi Divintas,

Did you have news about 64bit support ?

Thanks

The only response I can get from VMware Support is that they "hope" to support 64 bit Oracle in the future releases, not very promising, so I'm probably going to be moving over to SQL Server in the next month or so if nothing comes out, seems like this is their primary DB platform for VC anyway.

This may be one reason VM Ware doesn't want to support 64-bit just yet:

When 32-bit Oracle is acceptable

You might want to stay on a 32-bit server if any of these conditions are true:

Linear processing: You do not need multiple-CPU SMP processing (Oracle parallel query) for large-table, full-table scans.
No need for large data buffers: If you do not have large working sets (e.g., an OLTP database) then 32-bit may be the right choice.
External bottleneck: A 32-bit architecture is fine if your bottleneck is not in the Oracle database. In an ERP system, the bottleneck may be in the app servers, Web caches, or network, and a faster database will not help.
High buffer invalidations: If your application performs frequent data purges, data truncations or makes high-volume use of temporary tables, then you may not find large RAM regions suitable.
Not computationally intensive: If your bottleneck is in the network or disk I/O, then the faster 64-bit CPUs will not improve your overall performance.

While a 64-bit server is not a panacea, there are several well-documented reasons for moving to a 64-bit server. If any of the following conditions are true, then you may want to consider a 64-bit solution:

High transactions processing rates: Systems with more than 200 disk I/O's per second may see dramatic improvement in speed and scalability. By caching large amounts of data, disk I/O is reduced and performance skyrockets.
Declining performance: As systems grow, the 32-bit limitations prevent continued growth.
Anticipating rapid growth: For systems that require uninterrupted growth and scalability, the 64-bit architecture allows almost infinite scalability. Many large ERP systems have been able to scale successfully on Windows 64 platforms.
Computationally-intensive system: If your Oracle database is CPU-bound or if you perform lots of parallel full-table scans, then the faster processors in a 64-bit architecture are very appealing.

This document was generated from the following thread: Virtual Center 2.5 and Oracle 10.2.0.3 (64bit) compatibility

ESX Installation Times

Mon, 10 Mar 2008 16:26:12 GMT

I'm an advocate of rebuilding ESX servers rather than spending hours of troubleshooing time trying to find a needle in a hay stack. Depending on the response time you're getting from VMware, HP, or wherever you're getting your VMware support from, rebuilding starts to look attractive rather than spending hours on the phone or days of email log shipping back and forth with the support technicians. Of course, rebuilding would only be a logical decision if there were no underlying hardware issues that were the root cause of the host failure - an ESX host rebuild won't resolve hardware problems.

I have heard from many people who agree, supporting their opinion with claims that "I can rebuild an ESX server in X number of minutes". I've performed many deployments and I had a pretty good idea of what my deployment times per box were but I've never timed myself to put my own money where my mouth is. I decided to run through a build with a stopwatch. Following are my results.

Hardware:
HP Proliant DL580G2
4x P4 XEON 2.5GHz processors (512KB L2, 1MB L3 cache)
12GB RAM
Embedded Smart Array 5i disk controller (Read/Write cache present and enabled)
2x72GB Ultra320 10kRPM drives in a hardware RAID1 mirror
4x Broadcom Gb NICs

Software:
ESX 3.5.0 build 64607 (new and improved 2/20/08 edition)

The stopwatch begins running when the server begins booting the ESX 3.5.0 CD

0m: Boot from CD, select keyboard, mouse, manual disk partitioning, time zone selection, etc.

5m: File copy stage begins.

14m: Above file copy stage completed. Reboot.

17m: Server is booted up. Set date/time. Enable root SSH login. Manually create VMKernel vswitch using VIC. Run 166 lines of post install configuration scripts including installation of Proliant Essentials 7.9.1 agents.

27m: Scripted configuration stage above complete. Reboot

31m: Server is booted up. Remaining configuration done with VIC: Add host to Datacenter. Double check proper licensing. Configure bandwidth throttling on 2 portgroups. Increase virtual switch port count on VM switch. Configure swISCSI adapter and connect to ISCSI target. Add host to Vizioncore vRangerPRO. Move host from Datacenter into Cluster.

34m: VIC configuration stage above complete. Reboot.

37m: Server is booted up and ready minus patching.

At the 37 minute mark, the server is up and ready for action, minus patching. There are currently 9 patches for ESX 3.5.0 which will take an additional amount of time to apply using VMware Update Manager.

37m: VMware Update Manager remediation applied. Host enters maintenance mode and VMotions off one running VM

38m: Patching begins. 9 patches to install.

44m: 9 patches installed. Reboot.

47m: Server is booted up and thinks about the idle life for 8 minutes before exiting maintenance mode.

55m: Exit maintenance mode. Server is patched and ready for action.

Conclusion: On slower hardware with some scripted automation, ESX server can be completely rebuilt in under an hour. Efficiencies to decrease the total build time would be newer servers with faster bus speeds and processors, 15kRPM disk spindles, faster VirtualCenter server hardware, advancing the post install scripted configuration, selectively installing only need patches rather than all patches, using a kickstart.cfg script and/or automated deployment tool such as Altiris/HP RDP to complete the initial installation stage, capturing a host installation with patches and Proliant Essentials agents already installed, etc.

I'd be interested in hearing about your build times and automation methods.

Jason Boche
VMware Communities User Moderator

Jason -

Nice article about the install times. I have seen similar times with installs myself, although on different hardware minus the post install scripts. Since I am not a scripting guru I have always had to do it manualy. I would be interested in what installs you are automating with the scripts?

I will conclude that the theory of rebuild vs. troubleshoot extends to many areas in I.T., for example workstations, especially when you have a standard image you can deploy. I have had tech's spend 4-5 hours on a problem when a rebuild / restore data would have taken at the most 2 hours... Now, some will say that you are never finding the root cause of the problem and that is true, but in todays world, some problems are single instance and probably user created. For that type, I will take the lesser time.

Regards...

Hey Jas,

I am getting about the same from the time I kick off the altiris job to when the script ends, which is right before joining Virtual Center. I usually measure this to a lunch break so I do not have the exact time but we are in the same ballpark.

Scripts Rule!!!!

Steve Beaver
VMware Communities User Moderator

**Virtualization is a journey, not a project.**

jamieorth, here's an example of the automated configuration scripts I run. A lot of the lines are comment or redundant, but they are there for my sanity.

#Temporarily open all ports through the ESX firewall:
#Paste the following into PuTTY:
esxcfg-firewall -allowIncoming
esxcfg-firewall -allowOutgoing

#Configure switches and port groups:
#Open a PuTTY session with the server.
#Paste the following into PuTTY to create the remaining vswitches, port groups, and VLANs:
esxcfg-vswitch -a vSwitch2
esxcfg-vswitch -L vmnic2 vSwitch2
esxcfg-vswitch -L vmnic3 vSwitch2
esxcfg-vswitch -A 192.168.110.0_network vSwitch2
esxcfg-vswitch -A 1.544mbps_192.168.110.0_network vSwitch2
esxcfg-vswitch -A 10.0.1.0_network vSwitch2
esxcfg-vswitch -A 10.0.2.0_network vSwitch2
esxcfg-vswitch -A 10.0.3.0_network vSwitch2
esxcfg-vswitch -A 10.0.4.0_network vSwitch2
esxcfg-vswitch -A 1.544mbps_172.16.0.0_network vSwitch2
esxcfg-vswitch -A 172.16.0.0_network vSwitch2
esxcfg-vswitch -A 192.168.0.0_network vSwitch2
service mgmt-vmware restart

#Enable services through the ESX firewall:
#Paste the following into PuTTY:
esxcfg-firewall -e swISCSIClient
esxcfg-firewall -e sshClient
esxcfg-firewall -e ntpClient
esxcfg-firewall -e snmpd
esxcfg-firewall -e smbClient

#If you need the ability to establish an SMBFS connection from the COS to a Windows share, then perform the following three steps:
#On the COS:
#esxcfg-firewall -e smbClient
#On the Windows machine, configure the following two security policies (requires Windows reboot to take effect):
#Microsoft network server: Digitally sign communications (always) disabled
#Microsoft network server: Digitally sign communications (if client agrees) disabled

#Modification to display full path in COS:
#Paste the following into PuTTY:
mv /etc/bashrc /etc/bashrc.old
sed -e "s/
h \\\W/
h \\\w/g" /etc/bashrc.old > /etc/bashrc

#Add .boche.mcse to domain suffix search order:
#Paste the following into PuTTY:
echo "search boche.mcse" >> /etc/resolv.conf

#Configure time zone and NTP:
#Paste the following into PuTTY:
cp /etc/ntp.conf /etc/ntp.org
ln -sf /usr/share/zoneinfo/US/Central /etc/localtime
echo "restrict obiwan.boche.mcse mask 255.255.255.255 nomodify notrap noquery" >> /etc/ntp.conf
echo "restrict jabba.boche.mcse mask 255.255.255.255 nomodify notrap noquery" >> /etc/ntp.conf
echo "server obiwan.boche.mcse" >> /etc/ntp.conf
echo "server jabba.boche.mcse" >> /etc/ntp.conf
echo "obiwan.boche.mcse" >> /etc/ntp/step-tickers
echo "jabba.boche.mcse" >> /etc/ntp/step-tickers
esxcfg-firewall -e ntpClient
chkconfig --level 345 ntpd on
service ntpd restart
hwclock --systohc

#Ensure /etc/sysconfig/clock:
#cat /etc/sysconfig/clock should show:
#ZONE="America/Chicago
#UTC=true
#ARC=false

#Add some additional error logging on the consoles:
#Paste the following into PuTTY:
cp /etc/syslog.conf /etc/syslog.org

Three lines below: we want to see several more severe log entries on TTYs too.

echo "# " >> /etc/syslog.conf
echo "# Comment-out 3 lines below to protect tty10-tty12" >> /etc/syslog.conf
echo "*.=crit /dev/tty12" >> /etc/syslog.conf
echo "*.=err /dev/tty11" >> /etc/syslog.conf
echo "*.=warning /dev/tty10" >> /etc/syslog.conf

The line below: restart system logging daemon to activate above additions.

/etc/init.d/syslog restart

#Set SSH banner text:
#Paste the following into PuTTY:
echo $bannertxt1 > /etc/ssh/banner
echo " Legal Notice" >>/etc/ssh/banner
echo $bannertxt2 >> /etc/ssh/banner
echo " WARNING: USE OF THIS PRIVATE COMPUTER SYSTEM IS YOUR " >> /etc/ssh/banner
echo $bannertxt3 >> /etc/ssh/banner
echo " CONSENT TO BEING MONITORED AND RECORDED. UNAUTHORIZED " >> /etc/ssh/banner
echo $bannertxt4 >> /etc/ssh/banner
echo " USE IS PROHIBITED. WE RESERVE THE RIGHT TO SEEK ALL " >> /etc/ssh/banner
echo $bannertxt5 >> /etc/ssh/banner
echo " REMEDIES FOR UNAUTHORIZED USE. EVIDENCE OF SUSPECTED " >> /etc/ssh/banner
echo $bannertxt6 >> /etc/ssh/banner
echo " ILLEGAL USE MAY BE GIVEN TO LAW ENFORCEMENT. " >> /etc/ssh/banner
echo $bannertxt7 >> /etc/ssh/banner
echo "banner /etc/ssh/banner" >> /etc/ssh/sshd_config
service sshd restart

#Unload the VMFS-2 module to improve LUN and volume scan speed and improve overall performance:
#Paste the following into PuTTY:
vmkload_mod -u vmfs2

#Modification to prevent vmfs2 module from loading to improve LUN and volume scan speed and improve overall performance:
#Paste the following into PuTTY:
mv /etc/init.d/vmware /etc/init.d/vmware.old
sed -e "s/echo \"vmfs2 vmfs2\"/\#echo \"vmfs2 vmfs2\"/g" /etc/init.d/vmware.old > /etc/init.d/vmware
chmod 744 /etc/init.d/vmware

#SAN multipathing best practice:
#Paste the following into PuTTY:
#esxcfg-advcfg -s 1 /Disk/UseLunReset
#esxcfg-advcfg -s 0 /Disk/UseDeviceReset
#service mgmt-vmware restart

#Set Disk.MaxLUN to 25 to reduce rescan time:
#Paste the following into PuTTY:
esxcfg-advcfg -s 25 /Disk/MaxLUN
service mgmt-vmware restart

#Set Disk.SchedNumReqOutstanding to 64 to increase number of requests each VM can have against a single LUN at any given time:
#Paste the following into PuTTY:
#esxcfg-advcfg -s 64 /Disk/SchedNumReqOutstanding
#service mgmt-vmware restart

#Increase service console RAM allocation to 512MB:
#Paste the following into PuTTY:
mv -f /etc/vmware/esx.conf /etc/vmware/esx.conf.old
sed -e 's/boot\/memSize = \"272\"/boot\/memSize = \"512\"/g' /etc/vmware/esx.conf.old >> /etc/vmware/esx.conf
mv -f /boot/grub/grub.conf /boot/grub/grub.conf.old
sed -e 's/uppermem 277504/uppermem 523264/g' -e 's/mem=272M/mem=512M/g' /boot/grub/grub.conf.old >> /boot/grub/grub.conf

#Create VirtualCenter Agent temp install directory to prevent VC Agent install failures during future upgrades:
#Paste the following into PuTTY:
mkdir -p /tmp/vmware-root/

#Install HP Insight Management Agents 7.9.1:
#Paste the following into PuTTY:
esxcfg-firewall -allowOutgoing
cd /tmp
lwp-download http://www.boche.net/esxupdate/hpmgmt-7.9.1-vmware3x.tgz
tar -xzvf hpmgmt-7.9.1-vmware3x.tgz
cd hpmgmt/791/
lwp-download http://www.boche.net/esxupdate/hpmgmt.conf
./installvm791.sh --silent --inputfile hpmgmt.conf
esxcfg-firewall -blockOutgoing

#Remove HP Insight Management Agents 7.9.1 installation files:
#Paste the following into PuTTY:
cd /tmp
rm -f hpmgmt-7.9.1-vmware3x.tgz
rm -f -r hpmgmt

#Install ESX patches with web repository:
#This section is now obsolete with VMware Update Manager in VirtualCenter 2.5

#Ensure the firewall is enabled and running before final build completion:
#Paste the following into PuTTY:
service firewall start
esxcfg-firewall -blockIncoming
esxcfg-firewall -blockOutgoing

#Inject install completion date/time stamp into Message Of The Day:
#Paste the following into PuTTY:
dateTime=`date '+%c'`
echo "Built on "$dateTime" by Jason Boche." > /etc/motd

reboot

Jason Boche
VMware Communities User Moderator

Message was edited by: jasonboche

FYI, the VMware forum WYSIWYG editor really garfed the formatting and syntax of these scripts so if you want the unmamed version of the scripts, contact me via email and I'll send you the script file.

I have found in the past, although not personally responsible for this, with the use of some form of deployment server over PXE boot.. can cut these deployment times mentioned in half. 20 mins to install and then run said scripts.

Can save a lot of time this, and also means that with the right configuration you don't have to actually go and stick a CD in the physical machine!

I do also agree with most issues that arise, with the nature of ESX server and the fact you can just take a server offline without any hassle that it is just easier to rebuild as opposed to screaming at a dead host.

P.

Jason,

Send me a copy I like to collect these!!!

Steve Beaver
VMware Communities User Moderator

**Virtualization is a journey, not a project.**

I'll show you mine if you show me yours...

Jason Boche
VMware Communities User Moderator

This document was generated from the following thread: ESX Installation Times

reconnecting virtual machine files

Fri, 07 Mar 2008 08:17:28 GMT

Question: Is there anyway to re-link or reconnect virtual machine files from separate ESX 3.5 datastore to a new ESX 3.5 install?

I recently purchased a new larger drive for my test ESX 3.5 server at home. I installed a fresh ESX 3.5 install on this new drive. I added the old drive to it and was able to see and move files to the new datastore, but of course the new install does not show these files as virtual machines.

Does this have to be done from the Virtual Center or can it be done from VI client?

Answer: You need to register the vm's to the VC then only you can power them on. Select the datastore click on the .vmx file and it add to inventory.

This document was generated from the following thread: reconnecting virtual machine files

Tech: How to enable passthrough authentication in VMware VirtualCenter 2.5

jason@boche.net — Mon, 03 Mar 2008 16:04:41 GMT

Saw a cool article cross my RSS reader today on How to enable passthrough authentication in VMware VirtualCenter 2.5.

I just tested it; it works.

Source: http://www.virtualization.info/2008/03/tech-how-to-enable-passhrough.html Thank you Stuart Radnidge and Alessandro Perilli!

To use it, simply add -passthroughAuth -s vchostname to the end of the shortcut used to launch the VI 2.5 client.

By default it uses the Negotiate SSPI provider, however since they have fully implemented the interface you can change that behaviour to use Kerberos by adding the following within the node in the vpxd.cfg file on the VC server:

<sspiProtocol>Kerberos</sspiProtocol>

HP Proliant and Compaq MPS Table BIOS Settings for ESX Server

jason@boche.net — Mon, 03 Mar 2008 03:12:24 GMT

HP Proliant and Compaq MPS Table BIOS Settings for ESX Server

For those of you who use VMware ESX and Compaq/HP Proliant servers, I came across a helpful entry on Vincent Vlieghe's blog: http://virtrix.blogspot.com/2006/07/hp-proliant-and-compaq-mps-table-bios.html

This basically has to do with how to optimize the server's BIOS configuration for running VMware ESX Server. Most options in the BIOS may be easily interpreted and safe irregardless of the configuration, however, two configuration parameters stand out as important.

Thank you Vincent Vlieghe for doing the homework on this.

donderdag, juli 27, 2006
HP Proliant and Compaq MPS Table BIOS Settings for ESX Server
I read an interesting article on ESX on proliant servers:

Summary

HP ProLiant servers (and pre-merger Compaq ProLiant servers) require specific BIOS settings in order to run VMware ESX Server. These settings ensure that the physical hardware can be addressed properly and consistently by the VMkernel. Use of BIOS settings with values other than those identified below may result in operational instability.

Discussion

On HP ProLiant servers (and pre-merger Compaq ProLiant servers), the BIOS may not fully populate the PCI interrupt routing entries in the MP Configuration Table (part of the Intel MultiProcessor Specification) if the MPS Table Mode setting within the BIOS is incorrect. An incomplete MP Configuration Table may result in failure of an initial installation of ESX Server, failure to complete the boot process, or instability during normal operation.

For stable operation on these systems, ESX Server requires a BIOS MPS Table Mode setting of Full Table APIC. With the exception of the specific systems referenced below, the following BIOS settings must be applied in order if available:

System Options > OS Selection: Select Windows 2000.

Advanced Options > MPS Table Mode: Select Full Table APIC.

When presented with multiple Windows options (Windows 2000, Windows Server 2003, Windows .NET, and so on) select Windows 2000. If both BIOS settings are available and can be modified, both must be set correctly. You should confirm these settings after any BIOS upgrade operation.

For the HP ProLiant DL 740 and DL 760 servers specifically, set the OS Selection BIOS setting to Linux to allow for proper operation when hyperthreading is enabled. The remainder of the BIOS settings, and the order in which they are applied, are as specified above.

If any BIOS setting is incorrect, you may see one or more messages in /var/log/messages or /var/log/vmkwarning on the Service Console similar to the following:
May 11 22:36:30 esx101 vmkernel: 0:00:00:00.00 ALERT: Chipset: 303: no PCI entries - Check BIOS Settings

May 11 22:36:30 esx101 vmkernel: 0:00:00:00.000 cpu0) ALERT: Chipset: 433: no PCI entries in MPS table - check BIOS settings

May 11 22:36:30 esx101 vmkernel: 0:00:00:00.000 cpu0) WARNING: IOAPIC: 986: no PCI entry for busID 2 busIRQ 8 - trying ISA irq 15

You may also see unnecessary hardware interrupt sharing, which is explained in detail in knowledge base article 1290 at www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=1290.

You may need to use the ROM-Based Setup Utility (RBSU), SmartStart CD, or other BIOS configuration tool to make these adjustments. Hewlett-Packard's Web site includes extensive documentation on how to adjust BIOS settings on HP and Compaq systems, including generalized RBSU guides which may be found at search.hp.com/query.html?qt=title%3A%22ROM-Based+Setup+Utility+User+Guide%22.

The "OS Selection" section of the HP RBSU User Guide notes that, in certain circumstances, adjusting the OS Selection BIOS setting may result in an automatic change of the MPS Table Mode BIOS setting (emphasis added):

The OS Selection option allows you to select the primary OS for the server. A list of supported OSs for the server displays on the menu, with the ROM defaulting to Microsoft Windows 2000 when the server supports it. Default server Multi Processor (MP) settings and PCI Hot Plug reservation settings are automatically set based on the OS selected.

Although an automatic change may occur, the individual BIOS settings should be confirmed explicitly if you intend to use this system with VMware ESX Server. For additional assistance in making these changes, please contact HP Technical Support.

Shortcut Guide for Setting Up VCB 1.1 and BackupExec

Thu, 07 Feb 2008 12:21:47 GMT

Configuring Windows on the VCB 1.1 Proxy

Reference: Virtual Machine Backup Guide (pg 34.)

To disable assignment of drive letters
1.) Shutdown Windows.
2.) Disconnect the VCB proxy from the SAN
3.) Boot the proxy and login as admin
4.) CMD - diskpart
5.) diskpart - automount disable
6.) diskpart - autmount scrub
7.) Shutdown Windows

Configuring SAN

1.) Create a SAN zone for each initiator to communicate with the proper disk array port
2.) Configure the disk array to allow the VCB proxy R/W access to all appropriate VMFS LUNs
3.) Reconnect VCB to SAN
4.) Boot Windows.
5.) Verify that the VCB Proxy has access to the VMFS LUNs in the disk management MMC.

Configuring Network on the VCB Proxy

Reference: Virtual Machine Backup Guide (pg 35.)

1.) If firewall between VCB/VC Server open port TCP/IP 443

2.) Establish TCP/IP ports 902 and 443 for all ESX server hosts.

esxconfig-firewall -q returned the following:
Incoming and outgoing ports blocked by default.
Enabled services: CIMSLP aam VCB CIMHttpsServer vpxHeartbeats LicenseClient sshServer CIMHttpServer symantecBackupExec
Opened ports:
vcbssh : port 443 tcp.in tcp.out udp.in udp.out
vcbssh : port 902 tcp.in tcp.out udp.in udp.out

Configuring the ESX 3.5 Clients Firewalls

Reference: Firewall Configurations for Backup Clients on the ESX Server 3 (pg 1.)
Only required if using BE to back up the ESX hosts

1.) Select the ESX Host
2.) Configuration then Security Profile under software
3.) Click Properties
4.) Enabled the Symantec Backup Exec Agent - Opens TCP Ports 10000-10200 for incoming connections

Configuring Symantec Backup Exec 11d for Windows Server 2003

Reference: Firewall Configurations for Backup Clients on the ESX Server 3 (pg 3.)

1.) Open Symantec Backup Exec 11D
2.) Tools - Options
3.) Click Network and Security
4.) Enable remote agent TCP dynamic port range and enter "10001 and 10200"

Configuring Firewall Ports or Port Ranges on the Service Console

Reference: Firewall Configurations for Backup Clients on the ESX Server 3 (pg 3.)
Only required if using BE to back up the ESX hosts

1.) Log into service console with root permissions
2.) esxcfg-firewall -0 command to open up the correct ports for the backup products.
3.) Restart services: service mgmt-vmware restart

Configuring SSL Verification

Reference: Virtual Machine Backup Guide (pg 40.)

Configuring VMware Consolidated Backup

Reference: Virtual Machine Backup Guide (pg 36.)

A user account should be created for VCB to communicate with Virtual Center. This can be a local user on the VC server or an AD user. This user should be assigned the VCB role with the follwoing permissions:

VirtualMachine/Configuration/DiskLease
VirtualMachine/State/CreateSnapshot
VirtualMachine/State/RemoveSnapshot
VirtualMachine/Provisioning/Allow Virtual Machine Download

C:\Program Files\VMware\VMware Consolidated Backup Framework\config\config.js

1.) Specified all non default entries (HOST, USERNAME, PASSWORD)
Here is what my config.js file looks like and I created a C:\mnt directory

BACKUPROOT="E:
mnt";
HOST="VirtualCenter.FQDN.com";
//PORT="443";
USERNAME="VCBUser";
PASSWORD="XXXXXX";
//TRANSPORT_MODE="san";
//LOGLEVEL=6;
//SNAPSHOT_POLICY="automatic";
//VM_LOOKUP_METHOD="ipaddr";
PREEXISTING_MOUNTPOINT="delete";
PREEXISTING_VCB_SNAPSHOT="delete";
//MAX_RETRIES=0;
//BACKOFF_TIME=10;

Configuring a backup job in Symantec Backup Exec 11d

Reference: README-backupexec.html

1.) create a new backup job in symantec
2.) choose any directory for the time being ex C:\temp
3.) Choose a type of backup - I choose full
4.) Uncheck Use the windows change jounral if available.
5.) Settings/Advanced options then check Back up files and directories by following junction points
6.) Frequency/Schedule and select Submit job on hold, then click run now.
8.) Configuring the GUI selection list.
9.) Open a command prompt CMD and go to the the backupexec dir that has the browse-start/end batch files.
10.) run the batch file - browse-start-bat (backupjobname) (FQDN of guest VM to backup)
11.) Go back to SymantecBackup Exec
12.) Uncheck the folder in step 2 ex C:\temp
13.) If left default in the config.js the mounting point will be C:\mnt\(FQDN of guest VM)
14.) Select the files to backup from the guest VM
15.) Go to the Settings/Pre/Post Sripts
16.) Pre & post scripts type the path to & use pre-backup.bat (jobname) (FQDN VM)
17.) Make user all the following boxes are check

Run job only if pre-job command is successful
+ run post-job command only if pre=job command is successful+
+ run post-job command even ifjob fails+
+ all pre and post commands to be succesfful only if completed with a return code of zero+
+ Run these commands is set to On each server backed up.+

18.) Go back to CMD and run browse-end.bat (jobname)

VMware Communities : Document List - VMware Infrastructure™

P2V using the same hardware

Has anyone figured out VCB 1.5 custom quiescing scripts?

vmware-vdiskmanager –x and avaiable space in FreeBSD virtual machine

IETF X.509 Certificate Signature Collision Vulnerability

Sample ftp script (python) for ESXI 4

ESXi 3.5

How to expand the ESX Datastore on SAS RAID pools using CLI on IBM BCS

Ghetto Tech Preview - ghettoVCB-restore.sh - Restoring VM's backed up from ghettoVCB to ESX(i) 3.5 and 4.0+

Table of Contents:

Description:

Requirements:

Setup:

Usage:

Sample Execution:

Change Log:

Known Issues:

Kill PID process

Script : Listing of all datastores and extents

HP DL380 G6 Processors

Fax hardware for vm's?

How to Increase the Hard Disk Size of Guest OS

Buslogic to Lsi

Troubleshoot ESXi 3.5 installation on IBM HS20

When installing ESXi on IBM Blade HS20, after you've accepted the license agreement, you get the following message:

Here are some steps that can help you in order to install ESXi on this machine:

how to create encrypted password to add users

How-to Setup Internal routing on VI3i Host with Vyatta Virtual Router

after insert a hot-plugable Disk into my proLiant , How to use max capacity

VMware VCB frontend script for Windows / ESX

ghettoVCB with log to file

VMWare ESXi Hardisk Space

How to deploy VM from template in ESXi (3.5U2)

ESX upgrade from 3.02 to 3.5 - Migrate fails, operation timed out

Exchange Server 2007 Design Considerations

Virtualizing Microsoft Exchange Server 2007

Installing ESX 3.5 on Workstation

Hp and Vmware

Migrate ESX 2.5.X vm's to ESX 3.5.X server

"general fault cauesd by" after copying vm's between storage

Slow disk performance with Mapped Raw LUN (RDM) in ESXi 3.5.0 U3

Suggested configuration for RAID level

ghettoQuickMigrate.sh - "Quick" Migration for VM(s) running on ESXi 3.5u2+

Description:

Requirements

Usage

Setup

Example execution

vmware esxi on dell optiplex 745 cannot be completed

Can't Add Harddisk capacity 500 GB

DualCPU w/ different CPUID & Microcode Level

ghettoClone.sh - Automate cloning VM(s) for ESX/ESXi 3.5u2+ utilizing VMware VIMA: RCLI + VI Perl Toolkit

Description

Requirements:

Usage:

Use cases

Option 1 - Deploy clones from source VM by specifying a cloned VM naming convention and amount (start/end parameter) of clones.

Option 2 - Deploy clones from source VM by specifying a subset of VM names through an input file. The amount of cloned VMs will directly correlate with the amount of display names present in the input file.

Prerequisite

Example execution

Environment

Option 1

Option 2

How to configure ESXi to shutdown using an APC SmartUPS (with lamw scripts)

VMware server and ESX server at a glance

VMFS Best Practices

Linked Clones script for ESXi

update child resource configuration constantly scrolling in the VI client

my-vmware-cmd.sh - Custom management script for administering a large amount of virtual machines on ESX 3.x and ESXi

purge

Scenario: Purge Linked Clones 1-16 on local ESX Host

Scenario: Purge Linked Clones 17-32 from remote VIMA host

mac

Scenario: Extract MAC Addresses for the 32 Linked Clones and output in a generic form.

Scenario: Create DHCP IP reservation file for the 32 Linked Clones on Network: "172.30.200", starting from Host: "50" and increment to the last VM.

vnic

Scenario: Change 16 of the 32 Linked Clones from "IsolatedNetwork" to "labs.90-172.30.90-23" network

Known Issues:

Linked Clones script for ESX 3.x

Example Execution of all 3 Use cases: