vmkfstools -i /vmfs/volumes/datastore1/somehost/somehost.vmdk /vmfs/volumes/datastore1/somehost/somehost-thin.vmdk -d 'thin' -a lsilogic
# adjust vmx and away you go.
Showing posts with label vmware. Show all posts
Showing posts with label vmware. Show all posts
Tuesday, May 18, 2010
Sunday, December 6, 2009
add virtual hard disk to linux
#in vmware workstation | vm settings
add virtual hard disk to vm
#in vm
fdisk /dev/sdb
n
[ENTER][ENTER]
w
mkfs -t ext3 /dev/sdb1
mkdir /newdir
mount -t ext3 /dev/sdb1 /newdir
echo "/dev/sdb1 /software ext3 defaults 1 1" >> /etc/fstab
See: http://www.matttopper.com/?p=25
add virtual hard disk to vm
#in vm
fdisk /dev/sdb
n
[ENTER][ENTER]
w
mkfs -t ext3 /dev/sdb1
mkdir /newdir
mount -t ext3 /dev/sdb1 /newdir
echo "/dev/sdb1 /software ext3 defaults 1 1" >> /etc/fstab
See: http://www.matttopper.com/?p=25
Wednesday, October 7, 2009
resize a mounted lvm-managed disk in linux
I have found many overly-complex and incorrect and/or unnecessary instructions all over the web. So, I made this reference for me, but it may work well for you too. I typically use RHEL4/5 in my data center implementations, so these steps cover lvm managed disk space (which is decent for a simple LAMP stack).
I tend to do the following a lot in vmware products (workstation/esx/esxi).
First, check and note the size of your disks and partitions in your target vm.
Then, go into the settings of your vm (e.g. through the vi client) and either add another virtual hard disk or increase the size of the existing disk. In my case i simply extended the existing virtual disk from 8G to 16G.
Reboot.
Check to see that the size of /dev/sda has increased.
/* If you increased the size of your existing disk, its probably easiest to boot from the gparted-live disk and create a new primary partition in the newly free space, format ext3. */
wget http://downloads.sourceforge.net/project/gparted/gparted-live-stable/0.4.6-1/gparted-live-0.4.6-1.iso?use_mirror=softlayer
reboot
/* check for /dev/sda3, your new parition */
/* create the lvm pv reference */
/* extend the lvm vg reference */
/* note the free space for your upcoming `lvextend` command */
/* extend the lvm vg reference */
/* resize the volume group while its still mounted */
check the following
now, go on with your life.
I tend to do the following a lot in vmware products (workstation/esx/esxi).
First, check and note the size of your disks and partitions in your target vm.
[root@host]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
5.8G 665M 4.9G 12% /
/dev/sda1 99M 9.1M 85M 10% /boot
none 506M 0 506M 0% /dev/shm
[root@host]# sfdisk -s
/dev/sda: 8385898
/dev/sda1: 104391
/dev/sda2: 8281507
/dev/dm-0: 6160384
/dev/dm-1: 2031616
Then, go into the settings of your vm (e.g. through the vi client) and either add another virtual hard disk or increase the size of the existing disk. In my case i simply extended the existing virtual disk from 8G to 16G.
Reboot.
Check to see that the size of /dev/sda has increased.
[root@host]# sfdisk -s
/dev/sda: 16777216
/dev/sda1: 104391
/dev/sda2: 8281507
/dev/dm-0: 6160384
/dev/dm-1: 2031616
[root@host]# sfdisk -l
Disk /dev/sda: 2088 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/sda1 * 0+ 12 13- 104391 83 Linux
/dev/sda2 13 1043 1031 8281507+ 8e Linux LVM
/dev/sda3 0 - 0 0 0 Empty
/dev/sda4 0 - 0 0 0 Empty
/* If you increased the size of your existing disk, its probably easiest to boot from the gparted-live disk and create a new primary partition in the newly free space, format ext3. */
wget http://downloads.sourceforge.net/project/gparted/gparted-live-stable/0.4.6-1/gparted-live-0.4.6-1.iso?use_mirror=softlayer
reboot
/* check for /dev/sda3, your new parition */
[root@host]# sfdisk -s
/dev/sda: 16777216
/dev/sda1: 104391
/dev/sda2: 8281507
/dev/sda3: 8385930
/dev/dm-0: 6160384
/dev/dm-1: 2031616
/* create the lvm pv reference */
[root@host]# pvcreate /dev/sda3
/* extend the lvm vg reference */
[root@host]# vgextend VolGroup00 /dev/sda3
/* note the free space for your upcoming `lvextend` command */
[root@host]# vgdisplay
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 2
Act PV 2
VG Size 15.84 GB
PE Size 32.00 MB
Total PE 507
Alloc PE / Size 250 / 7.81 GB
Free PE / Size 257 / 8.03 GB
VG UUID L7woQB-ymCv-NeWL-i47M-b5Ua-fOHQ-hM0DXI
/* extend the lvm vg reference */
[root@host]# lvextend -L+8.03G /dev/VolGroup00/LogVol00
/* resize the volume group while its still mounted */
[root@host]# ext2online /dev/VolGroup00/LogVol00
check the following
[root@host]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
14G 668M 13G 6% /
/dev/sda1 99M 9.1M 85M 10% /boot
none 506M 0 506M 0% /dev/shm
[root@host]# sfdisk -l
Disk /dev/sda: 2088 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/sda1 * 0+ 12 13- 104391 83 Linux
/dev/sda2 13 1043 1031 8281507+ 8e Linux LVM
/dev/sda3 1044 2087 1044 8385930 83 Linux
/dev/sda4 0 - 0 0 0 Empty
now, go on with your life.
Wednesday, July 22, 2009
ESXi 4.0 not booting off DVD ISO or Host CD/DVD Device with DVD's
I had some problems with booting off DVD iso's on nfs shares and DVD's in the Host system CD/DVD reader (which, incidentally is a SATA device, also problematic with ESXi according to some forums I've read). But I was able to get it to boot off the DVD media by burning the DVD iso to a physical disk and placing the disk in my client system DVD reader. Then, I set the boot options to delay by 5000ms, set the boot order in the VM's bios as removable,network,cdrom,hard drive, and then i started the vm. while it was sitting there trying to boot off the network, i used the little CD button above the vm console window to connect my local DVD drive to the vm through the VI4 client. This worked, it was slow but it worked and I was so happy!
Friday, February 20, 2009
Running VMware ACE Player as a Windows Service
First, read this. I wasnt able to use the resource kit tools because Macrosh@ft wont allow you to redistribute their tools. So, we instead bought a tool that offered an OEM license. If you dont know what ACE is, its vmware's option pack for VMware Workstation. Its basically a bunch of security features and packaging options, meaning, you can build vm and then package it up and install it on another system. I wanted to use it because I wanted to make sure the server could not be copied and run somewhere else by anyone except the people I choose and authorize.
One of the features in an ACE policy is that allows you to run a script or executable instead of enter a password when the vm is started. The VMware ACE Player, interestingly enough, will accept a string from STDOUT of this script or exe in order to attempt the decryption of the encrytion key thats used to read the vmdk files as the vm runs. Using FireDaemon and the FireDaemon features of Pre-Post Service commands, I was able to use vmrun.exe stop command to shut down the vm when the host system is rebooted. I also made lanmanworkstation a service that the Firedaemon service depends on. This way, the vm is not started until the network is full up on the host system...other people have mentioned using this technique and it seemed like a good one.
The executeable, written in VC++ STL, accepts two args, a meaningful 9 digit number and a secret. If either of these args fail a number of tests performed on them, the exe quietly exits. If the args pass, a SHA512 hash (using openssl) is performed and a 64 character string is printed out to STDOUT. Its this string that the vmplayer.exe uses to encrypt/decrypt the AES keys that encrypt/decrypt the vmdk's when the vm starts.
These files, the exe and the openssl libs (dll's) and the VC manifest and their dll's and any other script and stuff you want to use in the Firedaemon service configuration, reside in the "ACE Resources" directory, under the parent directory of the vm Master.
Also, i got snagged by this: each time a package is built, the packager drops an ace.sig file into the "ACE Resources" directory of the package it generates. Make sure this ace.sig file doesnt get copied back into the Master "ACE Resources" directory. If it does, all the packages that you make will have this invalid file in there. Its easy to get into this situation when you delete the files in that directory in order to make a test package that may be updated with a policy update package, which would contain the authentication module and scripts. VMware should fix this by checking for this file and deleting it from within the Master's dir structure each time the packager runs, but it doesn't at this time. Anyhow, there is a policy option called Resource Signing that does check this file, and if its set to check it, which it is by default, the activation of the package (or policy update) will fail.
There was one more terribly annoying thing with setting up the service. When I attempted to shutdown or reboot the host system (unforced), the vmplayer.exe would abort the shutdown/reboot operation and display a modal dialog box that says "virtual machine is in use." I got around this by using AutoIT, a freeware application that allows you to create a simple script to operate windows and applications. So far its been a breeze and a very sensible and intuitive scripting language. Good docs help a lot too. Anyhow, this script ran as a Firedaemon pre-service and sits there waiting for that stupid dialog box to activate. It checks for this window every 250ms. Then, when the shutdown sequence starts, it gets rid of the dialog box and reboots the host system. Pretty slick.
Its too bad vmware says they wont support ACE vm's anytime soon on ESX or VMware Server. It would be pretty simple to get this working and I think that vm volumes that remain encrypted on-disk at all times solves a very difficult security challenge in operating system virtualization. no longer can someone make a copy of your entire filesystem and mount it somewhere else.
One of the features in an ACE policy is that allows you to run a script or executable instead of enter a password when the vm is started. The VMware ACE Player, interestingly enough, will accept a string from STDOUT of this script or exe in order to attempt the decryption of the encrytion key thats used to read the vmdk files as the vm runs. Using FireDaemon and the FireDaemon features of Pre-Post Service commands, I was able to use vmrun.exe stop command to shut down the vm when the host system is rebooted. I also made lanmanworkstation a service that the Firedaemon service depends on. This way, the vm is not started until the network is full up on the host system...other people have mentioned using this technique and it seemed like a good one.
The executeable, written in VC++ STL, accepts two args, a meaningful 9 digit number and a secret. If either of these args fail a number of tests performed on them, the exe quietly exits. If the args pass, a SHA512 hash (using openssl) is performed and a 64 character string is printed out to STDOUT. Its this string that the vmplayer.exe uses to encrypt/decrypt the AES keys that encrypt/decrypt the vmdk's when the vm starts.
These files, the exe and the openssl libs (dll's) and the VC manifest and their dll's and any other script and stuff you want to use in the Firedaemon service configuration, reside in the "ACE Resources" directory, under the parent directory of the vm Master.
Also, i got snagged by this: each time a package is built, the packager drops an ace.sig file into the "ACE Resources" directory of the package it generates. Make sure this ace.sig file doesnt get copied back into the Master "ACE Resources" directory. If it does, all the packages that you make will have this invalid file in there. Its easy to get into this situation when you delete the files in that directory in order to make a test package that may be updated with a policy update package, which would contain the authentication module and scripts. VMware should fix this by checking for this file and deleting it from within the Master's dir structure each time the packager runs, but it doesn't at this time. Anyhow, there is a policy option called Resource Signing that does check this file, and if its set to check it, which it is by default, the activation of the package (or policy update) will fail.
There was one more terribly annoying thing with setting up the service. When I attempted to shutdown or reboot the host system (unforced), the vmplayer.exe would abort the shutdown/reboot operation and display a modal dialog box that says "virtual machine is in use." I got around this by using AutoIT, a freeware application that allows you to create a simple script to operate windows and applications. So far its been a breeze and a very sensible and intuitive scripting language. Good docs help a lot too. Anyhow, this script ran as a Firedaemon pre-service and sits there waiting for that stupid dialog box to activate. It checks for this window every 250ms. Then, when the shutdown sequence starts, it gets rid of the dialog box and reboots the host system. Pretty slick.
Its too bad vmware says they wont support ACE vm's anytime soon on ESX or VMware Server. It would be pretty simple to get this working and I think that vm volumes that remain encrypted on-disk at all times solves a very difficult security challenge in operating system virtualization. no longer can someone make a copy of your entire filesystem and mount it somewhere else.
Friday, November 14, 2008
Migrating from VMWare ESX 3.5 to VMWare Server 2.0 with VMWare Converter 3.0.3
The following is a brief account of how I got my vm's up and running in VMWare Server 2.0 that were originally running in ESX.
Short Story: I was able to load the vm into Workstation 5.5.5, fix the problems and bring it up in VMWare Server 2.0. Read on if you want a tiny bit more detail, there's not much to it.
In many cases I have encountered, sometimes you can't convert a ESX vm straight to VMWare Server 2.0. Some post-conversion modification is necessary. A number of VMWare forum threads elude to this fact, but I have found no further information on what it specifically entails. The OS's I have had the most problems with are CentOS and OpenBSD. The test image that I initially did when I was reviewing the possibility of this migration was a Win2k3 Standard image, and I was able to convert and run it with no problems.
In the specific conversion I attempted, the conversion process of the CentOS vm appeared successful. What I mean by this is that a vmx and vmdk file were generated. However, when I was going through the wizard, I encountered the following "Warning: Cannot configure the source image.". The vmdk file size seemed reasonable and the vmx file seemed like it was missing a few lines. I transferred these files from the win2k3 VMCS server, where I ran the VMWare Converter 3.0.3 software, to their new home, a win2k3 server with VMWare Server 2.0. I "Added a Virtual Machine to Inventory" in the VMWare Server 2.0 interface and the vm was reported to have been registered Successfully, but the vm showed up as "Unknown" in the inventory list, the controls to start the vm were greyed out, and no errors appeared to be logged or displayed anywhere.
Frustrating.
So, I tried bringing the vm up on another system that had VMWare Workstation 5.5.5 on it. An error was thrown, stating that the ide reference was incorrect and it thoughtfully suggested a change, which I made and worked. Then I was able to bring the image up and successfully reconfigured it for the new network environment it would call home. I shut the image down, copied it back the target host with VMWare Server 2.0 and successfully registered and ran the image. One last thing I needed to do was answer a question from the VMWare Server 2.0 before startup would occur. It was hidden on a pop-down on the Console tab, and wanted to know whether I had "moved it" or "copied it".
Tips:
Be sure to delete any snapshots the vm had, otherwise there may be problems later. Though, I have converted images successfully ignoring this step. The other bit that might be useful to know is that I was not able to successfully migrate any vm to VMWare Server 2.0 when selecting VMWare Workstation 6.x as the destination image format using VMWare Converter 3.0.3.
Another solution would be to avoid all these gui tools and export the VMDK with vmkfstools, then transfer the vmdk and create a new VM pointing to the VMDK. :)
Short Story: I was able to load the vm into Workstation 5.5.5, fix the problems and bring it up in VMWare Server 2.0. Read on if you want a tiny bit more detail, there's not much to it.
In many cases I have encountered, sometimes you can't convert a ESX vm straight to VMWare Server 2.0. Some post-conversion modification is necessary. A number of VMWare forum threads elude to this fact, but I have found no further information on what it specifically entails. The OS's I have had the most problems with are CentOS and OpenBSD. The test image that I initially did when I was reviewing the possibility of this migration was a Win2k3 Standard image, and I was able to convert and run it with no problems.
In the specific conversion I attempted, the conversion process of the CentOS vm appeared successful. What I mean by this is that a vmx and vmdk file were generated. However, when I was going through the wizard, I encountered the following "Warning: Cannot configure the source image.". The vmdk file size seemed reasonable and the vmx file seemed like it was missing a few lines. I transferred these files from the win2k3 VMCS server, where I ran the VMWare Converter 3.0.3 software, to their new home, a win2k3 server with VMWare Server 2.0. I "Added a Virtual Machine to Inventory" in the VMWare Server 2.0 interface and the vm was reported to have been registered Successfully, but the vm showed up as "Unknown" in the inventory list, the controls to start the vm were greyed out, and no errors appeared to be logged or displayed anywhere.
Frustrating.
So, I tried bringing the vm up on another system that had VMWare Workstation 5.5.5 on it. An error was thrown, stating that the ide reference was incorrect and it thoughtfully suggested a change, which I made and worked. Then I was able to bring the image up and successfully reconfigured it for the new network environment it would call home. I shut the image down, copied it back the target host with VMWare Server 2.0 and successfully registered and ran the image. One last thing I needed to do was answer a question from the VMWare Server 2.0 before startup would occur. It was hidden on a pop-down on the Console tab, and wanted to know whether I had "moved it" or "copied it".
Tips:
Be sure to delete any snapshots the vm had, otherwise there may be problems later. Though, I have converted images successfully ignoring this step. The other bit that might be useful to know is that I was not able to successfully migrate any vm to VMWare Server 2.0 when selecting VMWare Workstation 6.x as the destination image format using VMWare Converter 3.0.3.
Another solution would be to avoid all these gui tools and export the VMDK with vmkfstools, then transfer the vmdk and create a new VM pointing to the VMDK. :)
Wednesday, October 29, 2008
Exporting vm's from ESX to VMWare Server 2.0
Well, I hate to say it, but VMWare Server 2.0 is a little clunky. I don't get a lot of confidence using Internet Explorer to admin my vm's, but I can live with it. I also don't like how the vm admin service runs as a network service. It seems like it should be an optional install, in case IT policy allows remote administration of virtual environments. It just seems like its just one more thing to manage and watch for, an unnecessary increase in network attack surface with an application that may be very easily subverted.
What I can't live with is the mouse control, or lack of it, at the console of a windows OS running in VMWare Server 2.0...and it's running on a system with 4GB ram, a decent proc and win2k3 Std R2. Using the vm over RDP is reasonable and works well.
I was able to successfully import a ESX 3.5 image with Converter 3.0.3 to a VMWare Workstation 5.x compatiable image into VMWare Server 2.0. It didn't work with a VMWare Workstation 6.x compatiable image.
I wonder if VMWare has a security group that tries to crack its own apps?
What I can't live with is the mouse control, or lack of it, at the console of a windows OS running in VMWare Server 2.0...and it's running on a system with 4GB ram, a decent proc and win2k3 Std R2. Using the vm over RDP is reasonable and works well.
I was able to successfully import a ESX 3.5 image with Converter 3.0.3 to a VMWare Workstation 5.x compatiable image into VMWare Server 2.0. It didn't work with a VMWare Workstation 6.x compatiable image.
I wonder if VMWare has a security group that tries to crack its own apps?
Thursday, October 23, 2008
VMWare Server 2.0 installation error
Today I built a new Windows Server 2003 R2 (@patch-level) production server and attempted to install VMWare Server 2.0 and I ran into the following error.
I found a few discussions on the web that lead me to this patch:
http://support.microsoft.com/kb/925336
I installed it, rebooted and completed my work.
I found a few discussions on the web that lead me to this patch:
http://support.microsoft.com/kb/925336
I installed it, rebooted and completed my work.
Sunday, July 15, 2007
Saturday, July 14, 2007
Thursday, July 12, 2007
Subscribe to:
Posts (Atom)