Apparently Dell’s TPM VT Trusted Execution is incompatible with 64bit virtual guests. You must go into the BIOS and disable the VT Trusted Execution in the virtualization settings to get it to work. Alternative is to disable TPM since it is highly unlikely you are using it anyway. (DISCLAIMER: Be sure your corporate WDE does rely on it.) If you go this route, you must actually POWER OFF for the changes to take effect.
As a follow up to last weeks post on NTFS-3G performance issues, I stumbled across this VMWare KB article today with some further tweeks that can reduce I/O operations by utilizing more system memory.
Same as last time. Power-off the VM, close it in VMWare application, and edit the .vmx file.
Add the following:
MemTrimRate = "0"
mainMem.useNamedFile=false
sched.mem.pshare.enable = "FALSE"
prefvmx.useRecommendedLockedMemSize = "TRUE"
I haven’t tested it much so far, but I am willing to give anything a try to improve the performance of the VM.
Another VMWare issue I started having is Unity mode wouldn’t start. Click the button, the unity menu pops up and the VMWare window minimizes, but the unity app never displays.
This is also a common problem with a very simple fix. Apparently, sometime in the past, I added a line to my /etc/vmware/config file to problem fix or enable some other feature. This line and Unity just don’t mix.
The fix, per this thread and ultimately this blog post, is to remove the following line from your /etc/vmware/config file.
xkeymap.nokeycodeMap = true
Keep reading the VMWare Communities post for additional details if you added that line to address some key mapping issues.
Like many Linux users of VMWare, I live in a mixed world where not everything I need or want can be done in Linux so I have to resort to dual boots and virtual machines. Combine that with the sad state of EXT2/3 FS drivers for Windows and you have a situation where you have make concessions just to get by. For this particular story I am referring to having NTFS formated external hard drives. I like to run my virtual machines on separate physical disks especially when the physical machine is an under-powered laptop. So I have my VM on an NTFS external drive, trying to run it form my Linux desktop and I am getting terrible performance. TERRIBLE. Like the window graying out cause it is unresponsive and having to kill -9 processes just to get anything moving again. Looking at the processes the FUSE ntfs-3g driver is pegged at 100% even after killing the vm.
It turns out that this is a known problem in the ntfs-3g driver and is being ‘worked on’. I say ‘worked on’ cause the problem has apparently been around for a long time. So long in fact, that it has made it to the FAQ on the ntfs-3g.org website here. With all of that said, the solution is to simply add a line to your .vmx file. Note: This is a per-VM setting, so you will have to do it on all of them.
Edit your .vmx file and add the following.
mainMem.useNamedFile=FALSE
Do note as the state on the website that your /tmp dir must be on a non-ntfs-3g partition or else you could cause additional performance issues.
I guess I missed it.. RC2 was released on the 19th. As I am writing this, I am downloading the latest and greatest from VMWare. The first thing I notice is HOLY BATBYTES. The thing is 532MB. Last I looked, ESX wasn’t 532MB and it is a LOT more server. It is a freaking OS AND server. What the hell are they including in this thing? Now, I agree, that a lot of that size could be symbols and other debuging stuff since this is an RC. But jebus, 532MB!!!
Anyway.. the download is complete. Lets proceed with the update!
Download Update- check
unpack update- check
stop vms- check
get cold sweat from the thought of dealing with the WebUI- check
The install is just like all of the others. Very straight forward and nothing new. One nice perk though, it didn’t have to compile any modules for my Ubuntu Server.
First complaint.. it did not keep my certificate settings. It renamed them, but did not retain what I had already. So this acted more like a reinstall than an upgrade. :/
Odd.. it did keep some of my other configuration changes though.
A new ‘feature’ to be a gotcha.. everytime they update the plugin for the remote console, you will have to restart your browser. Nothing like being forced to restart your browswer because you upgraded VMWare on a different box. At least the console worked after an upgrade.
You lose another point VMWare.
Here is a CRAZY idea.. you already created a browser plugin.. give me the ability to power-on/off, restart, and upgrade vmware tools from it. Maybe that would be an acceptable compromise to forcing us to use Apache, Tomcat, and a crappy web interface/browser plugin. GRRR
On the tools upgrade.. I didn’t have to compile the modules. I know.. that will last probably 2-3 more weeks till the next kernel patch for Ubuntu comes out.
A new feature – VMWare Sync. A backup solution of some sort.. it states go look at the KB for more info.. LOOKING….. Nothing found.. That also brings up another interesting point..
Per the release announcement, this is the final RC and it will contain
The RC2 build primarily incorporates fixes that we have incorporated since RC1 was released on July 1. So, no new features…….
It clearly states during the tools install.. this is a new beta feature. I think someone is confused.
The damn prompting for a client certificate is still there. WTF, over?
All in all.. a smooth update. They didn’t fix anything that was apparently broken aside from the Remote Console plugin now works with Fx 3.0.1. How long till it has to be fixed again?
The number one take away is.. Don’t forget to update your console plugin before you get too far into the upgrade.
A few months ago, I spent many days working on getting a smartcard reader to do USB passthough with VMWare Workstation 6.5 Beta. The original post can be found here.
The setup was a Ubuntu 8.04 desktop install, running VMWare 6.5 Beta 1 (at the time) and I needed to get a USB smartcard reader to be recognized by a XP SP2 (again, at the time) guest.
The final solution was to install a few apps, set a few flags in the .vmx file, and upgrade to Beta 2 when it was finally released. The following should be a summarization of how to get the passthough working.
For VMWare to recognize a USB device, the host has to recognize it to a degree. To accomplish this, I installed the following packages.
libccid
libpcsclite1
libpcsclite-dev
libpcsc-perl
pcscd
pcsc-tools
My card reader was an SCM Microsystems, Inc. SCR331-LC1 SmartCard Reader. I installed the drivers I found from there site. Specifically:
SCR331 CCID USB Driver – scmccid_5.0.4_linux.tar.gz
To enable the CCID passthrough functionality, I added the following lines to the guest .vmx file.
sb.ccid.useSharedMode = “TRUE”
When I look at it like this, it amazes me how much work I put into it to result in a half-dozen commands to get it functioning.
et another item that I do not like about the new VMWare Server 2. The process name. In SErver 1.x you could identify which vm a specific process represented from either a ps or top. It would display something like
/usr/bin/vmware-vmx myvm.vmx
and continue on with some other stuff. With the upgrade to Server2, the process names have changed and now require extra effort to see which VM is which when the process is running.
My monitor’s resolution is 1680×1050 and this is all I can see of the process line when running top.
“/usr/lib/vmware/bin/vmware-vmx -# product=2;name=VMware Server;version=2.0.0;buildnumber=101586;licensename=VMware GSX Server for Linux;licensever”
Running ps aux shows a few characters less.
This is the full text of the command string.
/usr/lib/vmware/bin/vmware-vmx -# product=2;name=VMware Server;version=2.0.0;buildnumber=101586;licensename=VMware GSX Server for Linux;licenseversion=3.0 build-101586; -@ pipe=/tmp/vmhsdaemon-0/vmxf0587f70a704b094;readyEvent=58 /srv/vmware/host.example.com/host.example.com.vmx
As you can see.. the bit of info that is needed to identify the vm is at the very end.
VMWare, please rearrange the construction of the command that launches the virtual machines to have the configuration file listed at the beginning so we can easily see which VM is which.
NOTE: The easiest workaround is to run “ps aux | grep vmx”, unfortunately, this doesn’t work in top.
After 20 minutes of searching the history files, I finally found the posting I was looking for.
It is the instructions on how to complile vmware-tools when they won’t due to kernel updates.
Install the needed packages.
sudo apt-get install build-essential xinetd linux-headers-$(uname -r)
sudo apt-get install libproc-dev libdumbnet-dev xorg-dev libgtk2.0-dev (Only need if using X)
Change to /tmp to do the install.
cd /tmp
Browse over to the SourceForge Open VM Tools project page and grab the link to download the latest version.
Which as of 8/6/2008 is http://mesh.dl.sourceforge.net/sourceforge/open-vm-tools/open-vm-tools-2008.07.01-102166.tar.gz
Grab a copy.
wget http://mesh.dl.sourceforge.net/sourceforge/open-vm-tools/open-vm-tools-2008.07.01-102166.tar.gz
Grab a copy of the vmware tools.
Untar/gzip them.
tar xzvf VMware*.gz
tar xzvf open-vm-tools*.gz
Build some modules.
cd open-vm-tools-2008.07.01-102166/
./configure && make
cd modules/linux/
Tar them up.
for i in *; do mv ${i} ${i}-only; tar -cf ${i}.tar ${i}-only; done
Copy them over the included modules.
cp -f *.tar /tmp/vmware-tools-distrib/lib/modules/source/
CD into the VMWare tools dir and run the install.
cd /tmp/vmware-tools-distrib
sudo ./vmware-install.pl
I posted a reply on the vmware community forums regarding backing up your VMWare Virtual Machines and thought it would be good to do something more thorough.
The first consideration you need to make when planning your backup strategy is to know what you are trying to protect yourself from.
This, for the most, boils down to Hardware failure or Software Corruption.
The simple solution to protect against hardware failure is a RAID 1 or higher setup. This creates, in a RAID 1 setup, a exect mirror of the drive. If one goes down, you can rebuild the mirror off of the still working drive.
This however, does not protect you from software corruption. Because the mirroring process is near real-time (write caching delays, etc.) if your OS is corrupted, chances are both copies on the mirror are going to have the same corruption.
To protect against software corruption you have a variety of choices which all depend on your particular setup and budget. I am going to focus on the likely scenario of a home user with limited funds to purchase hardware/software and happen to be running a linux host. (BTW.. if you are running Windows, you are throwing away a serious chunk of your hardware resources to your host OS.)
Since the files that represent your virtual machines are in use cause your VM is powered on, you can not copy them directly. Doing so would dramatically increase the risk of corruption due to write caching in the VM as well as when you bring your backup online the guest will think it did not have a proper shutdown.
This means you need to have the files NOT in use. Since a good backup is one that runs automatically, a GUI is not going to be a good choice. The good people at VMWare thought of that and provided a console tool to manage VMs called “vmrun”.
vmrun can perform the majority of tasks, if not all, I have not really looked into it too much, that you can from a GUI or the craptastic WebUI of Server 2.
The command you are looking for in particular is:
vmrun -h https://hostname:443/sdk -T server -u user -p "password" suspend /path/to/myvm/myvm.vmx
to suspend it and
vmrun -h https://hostname:443/sdk -T server -u user -p "password" start /path/to/myvm.vmx
to bring it back up. Running this command places your VM in a safe state to copy the files that make up its virtual environment.
NOTE: If your password has special characters in it, be sure to include the double quotes around it.
Next we need to think about where you are going to store these files. Because in this scenario, we are talking about protecting vs. software corruption, it does not necessitate that these be stored on a separate machine. Though, by doing so, you can have a pretty good alternative to using a RAID solution.
If you are going to do a local solution. You simply want to perform a copy.
cp -R /path/to/myvm/* /path/to/backup/dir/
Now, the inclination of some would be to tar up the contents of the myvm directory first. You do not want to do this. Remember, you suspended your VM. To tar or compress the files takes time which means you have to wait longer for your VM to come up. Simlpy copy the files, then issue the vmrun start command to bring your VM back online.
Once you have done that, you can tar to your hearts content on the backup dir. You could do something like this:
tar -jcf /path/to/backup/dir/myvm.backup-$(date +%Y-%m-%d-%H.%M.%S).tar.bz2 /path/to/myvm
This will create a bz2 compressed tar of your entire myvm directory with the date and time of the backup in the file name.
If you were taking the path of storing the file on a separate box, this is the point at which you should copy it. Because we put the date into the file name, we have to be able to pull it back out. Since this will be in a script, you would simply move date into a var and do an expansion for the filename.
BACKUPDATE=`date +%Y-%m-%d-%H.%M.%S'
The tar command would become:
tar -jcf /path/to/backup/dir/myvm.backup-$BACKUPDATE.tar.bz2 /path/to/myvm
Now you can perform the copy. I would recommend you use FTP if you are not crossing a public network, otherwise, use SSH. I say FTP due to the performance differences. In FTP you do not have all of the encryption overhead for the network and processor.
For FTP you would do something like.
ftp -n $HOST <<EOS
quote USER $USER
quote PASS $PASSWD
put myvm.backup-$BACKUPDATE.tar.bz2
quit
EOS
Or for something a little more complex. This allows for error handling.
global FTP
spawn ftp $HOST
set ftp $spawn_id
expect "name"
send "$USER\r"
expect "Password:"
send "$PASSWD\r"
expect "ftp>"
send "put myvm.backup-$BACKUPDATE.tar.bz2\r"
expect "ftp>"
send "quit\r"
SFTP is a much simpler option in terms of syntax.
sftp /path/to/myvm.backup-$BACKUPDATE.tar.bz2 sshuser@host.example.com:/path/to/store/backup
To provide authentication, you simply setup public key authentication for SSH.
From here, you can delete the directory with a simple rm -rfd /path/to/myvm. Just be sure that the compressed copy you just created is not in the directory you are about to delete.
Through out this, you could add in a vairety of checks and error handling to make it much more robust.
— wow this was a lot of thought.. I am currently working on a script to semi-generically do this. Stay tuned.
Because I hate making SSL exceptions in Firefox, I decided to change the keys. It was suprisingly simple
They are located in /etc/vmware/ssl I replaced mine by using the existing names. Renaming the originals to .old or something descriptive like that.
Alternatively, you could edit the hostd/config.xml file and update the values in the <privatekey> and <certificate> attributes and then update /etc/vmware/locations file. Do a search for “rui”. There are two places to update as well.
The number following some of the files is the create date in Epoch. Mine currently does not match and I am able to access the WebUI with out any SSL errors. I suspect it has to do with the uninstall process. If the times do not match, the uninstall script will not remove it.
I found a Unix Epoch converter.
I don’t know what kind of management is going on over at VMWare that they can pass this joke of a management interface be shown to the public. I have had nothing but capital P problems with this POS.
All of the problems I mentioned before as well as the interface just not working.
I was installing Solaris10-x86 to do IdM developement on my laptop. I kept running into a timing issue where the clock on the virtual solaris hardware is running fast to the degree that minutes were passing faster than a real second. Several hours of digging for a solution, I decided to try it on my “Brand New” VMWare Server 2 install. The only good news that came out of this entire ordeal was the timing issue went away. Though, I suspect that is due to kernel differences vs. software improvements. I had the same kind of speedy behaviour out of Workstation 6.5 Beta 1 and 2.
Anyway.. back to the Solaris install.. So the install goes smoothly much to my suprise. It wasn’t until after the reboot that the management interface problems started showing themselves. There were not specific issues as a result of the VM or Guest OS install process. It was more the resultant behavior of a system that has a run-away process. Namely, a VM of Solaris that will not die.
When the CPU/Memory load of the host server was high due to the Solaris VM, the management interface started flaking out. Little sections stopped responding leaving “loading” notices for minutes as if.. gasp.. a jsp applet timed out and doesn’t realize it!! Never returned any errors or gave any suggestions for how to ‘fix’. At one point the system was denying me access to perform functions on the virutal machines though I am explicitly an administrator on the application. I would stop the VM, it would report it was stopped at the bottom in the little events section but the top section would ‘grey’ out as if it was still processing my request. These quirks were resolved by either doing a full page refresh (shift+F5) or cycling the management process on the host. sudo /etc/init.d/vmware-mgmt restart
The biggest issue I ran into though, was at one point I could not get the webAccess compontent to actually stop. vmware-mgmt stop would say it completed correctly but doing a process list showed it running.
Bit of warning if you have to manually kill the webAccess process. There is a separate watchdog process that will reload the service automatically. It acts like it retains the session problems details through the watchdog restarts. I had to manually kill both the watchdog and webAccess processes at the same time to get them to actually stop. Sounds a bit like a virus, eh?
At this poing I am ready to throw VMware Server 2 out the F’in window, but I noticed a little line indicating the virtual hardware version. Server 2 bumps this up to version 7 which is not backwards compatible with Server 1.0x or Workstation 6. (Maybe 6.5 beta?)
In all fairness to VMWare, I do see what they are tyring to accomplish. They are trying to unify their interfaces between the products. I am sure it was some kind of PITA to maintain the seperate apps for each of the different programs and I can respect that. But for the love of all that is Good and VMWare.. Give Me Back my Linux GUI!!!
Another side note: On the forums I found that the VirtualInfrastructure Client can be used to connect to Server 2 rather painlessly. The only problem with this is.. it is written in .Net and no one has managed to get it to run in WIne yet. So.. this basically means I am forced to either A. used the F@#$! POS web interface and all of its issues or B. run windows in a VM or somewhere to connect to the Server with a GUI.
I saw this article this morning from Ars on virtualization and itmade mention that VMWare Workstation 6 contains the ability to run a linux guest in paravirtualized mode. So I started digging around to see if Server offered this ability. Much to my chagrin, the functionality it is only in Server 2 which is still in RC1.
My biggest issue with Server 2 is the Server Console application we all know and love has been replaced by a crap-tastic web interface running on a stripped down/modified Apache/tomcat service provided by the install. In short.. teh suck.
I let my geek tendancies run and went ahead with the upgrade??? to Server 2. So far.. I am NOT impressed. The performance of the web interface is pathetic compared to the console.
First issue I ran into was it was prompting me to select a client certificate to authenticate myself. Apparently this is a bug that hasn’t been resolved yet. I had to backup and delete my client certificates to login. This is not going to fly..
Second issue, it doesn’t automatically accept those who can run sudo commands as authorized users of the system. I had to reset the root login and give the admin group that administrator role.
Third issue.. the HGFS module does not compile. At least I do not need shared folders on here.
Forth Issue..The remote console plugin for Firefox does not work with 3.0.1. I had to adjust it manually so it would.
Fifth Issue..the performance really sucks. Slow, buggy.. a couple of times I got an error that said my console session was rejected. No Permission To View The Console.. WFT. I restarted the vmware services on the host and it started working.
Sixth Issue.. Shutting down the guest did not power off the VM until the tools were upgraded. – I don’t mind they don’t fully function, but I would consider that one to be pretty important. I had to manually kill the process before the web interface would let me do anything.
NOTE: Before the paravirtualization option can be enabled (from the advanced options tab in the vm configuration) you have to have the upgrade tools installed and running and then shutdown the guest. So.. install, reboot, shutdown.
NOTE 2: The server is using self-signed certificates for SSL encryption. This means an exception will have to be made in Firefox to get to the site.
After all of this fun, I finally enabled the paravirtualization option and powered back on. Much to my dismay the kernel was checking every SCSI ID on the device to see if it could find anything. 10-15 seconds per ID and 15 usable IDs on a wide SCSI chain.
At this time.. I just powered off and turned off the option. I will build a new VM to try out the setting and migrate it over as the ‘prod’ box if I am happy with the performance.
I am definitely not happy about the resource usage of the web interface either.. formery console access used zero resources on my server.. now the web interface is using 1% CPU and 3% MEM. While this isn’t much, I wasn’t giving up anything previously. This is a serious step backwards..
I was perusing the interweb a few days ago and I stumbled across an interesting statement. (I don’t have the link anymore.). The gist was, you could bridge VMWare Guest NIC to a host adapter that has no IP address. The security implications are what caught my attention. So I started digging a little further and I found it was true and then I managed to work a little bit of magic to make it happen!
Here is the scenario..
ServerLAN is an Ubuntu Server host running VMWare Server. 2 physical NICs bound to 2 bridged networks. NIC1 is attached to the private LAN, NIC 2 is attached to the DMZ. These networks are isolated by a firewall.
ServerDMZ is an Ubuntu Server guest Virtual Machine. 1 Virtual NIC
The idea is to isolate ServerDMZ from the private network and ServerLAN from the DMZ.
I had all of this working with a public IP on the ServerDMZ virtual NIC, DMZ private IP on NIC 2, and the LAN Private IP on NIC1. The problem with this setup is, my host was accessible from the DMZ. With proper blocking.. namely drop all traffic to and from that interface, it wasn’t much of a concern. But the IP was still there. So I did a little Ubunutu /etc/network/interfaces magic.
mapping eth0 eth1
script /etc/network/get-mac-address.sh
map 01:23:45:67:89:01 NIC1
map AB:CD:EF:GH:IJ:KL NIC2
iface lo inet loopback
iface NIC1 inet static
address 192.168.1.2
broadcast 192.168.1.255
netmask 255.255.255.0
network 192.168.1.0
gateway 192.168.1.1
metric 100
iface NIC2 inet manual
up ifconfig $IFACE up
down ifconfig $IFACE down
To break this down..
mapping eth0 eth1
script /etc/network/get-mac-address.sh
map 01:23:45:67:89:01 NIC1
map AB:CD:EF:GH:IJ:KL NIC2
This section is protection verses kernel updates causing my NICs from being brought up in a different order. The script get-mac-address.sh basically greps the interface for the MAC and then assigns the label NIC1 or NIC2 depending on the MAC returned.
iface lo inet loopback
This brings up the loopback interface.
iface NIC1 inet static
address 192.168.1.2
broadcast 192.168.1.255
netmask 255.255.255.0
network 192.168.1.0
gateway 192.168.1.1
metric 100
This brings up my private network NIC. Does all of the necessary mappings.
Side Note:If you have two NICs with gateways listed, you can supply the metric line to give one a priority. If they are the same, your system will be unable to decide which route to take and take none.
iface NIC2 inet manual
up ifconfig $IFACE up
down ifconfig $IFACE down
This final section is how you bring up the interface with out an IP address. It also allows you to set permiscious mode, etc.
Instructions for the interfaces file can be found file:///usr/share/doc/ifupdown as well as the get-mac-address.sh script from the examples sub-folder.