As the subject says, this webserver is now serving the v6 Internet. At home, I am working on my v6 network with a 6in4 tunnel to Hurricane Electric. I have a Vyatta router which is my tunnel end point and a /48 for everything inside.
I am hoping to put together a post about my journey, but I suspect it will end up like the post I have been working on for my Vyatta router build.
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.
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.
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 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..