VMware Communities : Document List - VI: VMware ESXi™ 3.5

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

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

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

HP DL380 G6 Processors

Wed, 15 Jul 2009 14:51:20 GMT

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.

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 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 !

"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

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

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

Thu, 08 Jan 2009 12:26:26 GMT

Linked Clones script for ESXi

Wed, 17 Dec 2008 18:47:49 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 ESXi host. The script is very capable in deploying a large VDI environment in a relatively short amount of time.

Compatiable with:
VMware ESXi 3.5 Installable Update 3
VMware ESXi 3.5 Installable Update 2
VMware ESXi 3.5 Installable Update 1
VMware ESXi 3.5 Installable

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.

The only supported case is the "Default case" in ghetto-esx-linked-clones.sh.

~ # ./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}
~ #

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

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

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.

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

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

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.

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

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