05.23.07
Posted in VMware at 1:24 pm by Michael
There is a new document up on vmware’s site on how to tune performance in VMware Workstation 6.0.
http://blogs.vmware.com/performance/2007/05/getting_the_bes.html
I found the document to be helpful and informative, with a large amount of information to digest. Workstation 6.0 was a fairly big update, and this doc answered some questions for me on how to get the maximum performance out of the software.
Not much going on in Virtualization right now. KVM is in the stable Linux kernel, and people are not talking much about it from what I can see. Not sure if this is a good or a bad thing. I did some reading today about performance and it turns out Xen is still kicking KVM’s ass on that front… This will be interesting to see unfold in the next 6-12 months. Personally I don’t like either solution as much as VMware but then I have access to all this cool hardware specifically engineered to work with VMware.
I’ll come up with something to write about in the next day or two, but for now just wanted to point out this great document I found.
Permalink
01.05.07
Posted in VMware, Ubuntu at 2:19 pm by Michael
I had some issues making xrdp work correctly in my standard Ubuntu Server install. I figured other people might have the same problems I did so I’m writing this article to show you how to make this awesome software work in Ubuntu. I use the Ubuntu server install iso to install a linux server. It’s a good way to get a lightweight box that can handle VMware Server. I install fluxbox and xorg onto the server just in case we have network issues, we can still run the VMware Server console from the local machine to make any changes we need.
The first step to making xrdp work is to be sure you have xorg and a window manager installed (I use fluxbox since it’s very light on resources). From the command line type:
sudo aptitude install xorg fluxbox fluxconf vnc4server
This will install xorg, fluxbox, and the vnc server that xrdp uses for it’s magic. Once those are all installed, you need to install the development tools and a few library files, to compile xrdp. From the command line:
sudo aptitude install build-essential libpam0g-dev libssl-dev
That should take care of everything you need for compiling xrdp. I only actually do this step on one server, and then I just make a tarball of the final compiled program to distribute to the rest of the servers. I don’t need a compiler and all that devel stuff on all the servers, just the 1 I use to compile. There are a couple steps to making xrdp work correctly that I illustrate below.
Fix up the font directory. For some reason Xvnc is set to look for fonts in the wrong path, but this is easily fixed with this command:
sudo ln -s /usr/share/fonts/X11 /usr/share/X11/fonts
Also because the newest Ubuntu uses dash instead of bash as the default shell, the scripts included with xrdp give me errors. You have to edit the files with a text editor and set them to use bash instead of the default /bin/sh:
sudo nano /usr/local/xrdp/*.sh
In each file change the top line from:
#!/bin/sh
To:
#!/bin/bash
Save the first one and it should automagically open the second and third files you need to edit. Make the change in all the files and be sure to save them. Now there is one more change you need to make for things to work correctly. The startwm.sh script doesn’t have support for fluxbox in it. What I do is make a backup of the original file, then make a new file with just the commands I need for fluxbox, I couldn’t seem to get it working correctly until I did this. Commands:
cd /usr/local/xrdp
sudo mv startwm.sh startwm.sh.orig
sudo nano startwm.sh
Now make this file look like this:
#!/bin/bash
/usr/bin/startfluxbox
exit 0
That’s it, save the file and try starting xrdp:
sudo /usr/local/xrdp/xrdp_control.sh start
Once xrdp is started, try connecting with rdesktop or Remote Desktop Connection in windows. You should be able to login using your normal username and password and get an xdesktop. As long as that works, you can now link the xrdp_control.sh into your /etc/init.d directory and start it like any other service:
sudo ln -s /usr/local/xrdp/xrdp_control.sh /etc/init.d/xrdp
And to have it start up at boot you want to create the links in the proper places:
sudo update-rc.d xrdp start 98 2 3 4 5 .
That should do it. xrdp should load on boot and start fluxbox for you.
Permalink
12.22.06
Posted in VMware, Mac at 5:11 pm by Michael
With the release of the VMware Fusion Beta, I am in the process of evaluating it on my Macbook. So far as initial releases go, it’s interesting. I have installed and configured Ubuntu Linux onto a 5 gig virtual disk using Fusion. It’s comparable to Parallels Desktop, but this is obviously a beta. Things don’t look quite as nicely polished as they do on Paralells, but I expect by the time VMware releases Fusion most of that will be fixed. Performance seems good so far, though I’m not doing anything terribly demanding of the system. Just a simple LAMP setup to test things out. As a caveat anyone wanting to install the Ubuntu Server version will need to make an adjustment to grub’s config file. On the initial reboot after I installed Ubuntu Server, I got a kernel panic on an acpi component. I simply edited the grub config file at /boot/grub/menu.lst and added the “noacpi” kernel parameter to the line for my kernel. Once I did that it booted up successfully and no problems since.
Fusion seems to cause the fans on my Macbook to go into overdrive when compared to Parallels. It happens whenever I get any sort of load going on the Ubuntu server. I will have to create the same setup in parallels and test things. So far, running Windows XP, using Parallels, my Macbook’s fans don’t seem to run as much as they do once I have Ubuntu booted on Fusion. Running both at the same time keeps the fans on at the highest setting, pretty much non-stop. Obviously I’m putting a strain on the system, but you’d think it would alternate the fans a little… I only have 2 virtual machines going, and I was hoping to be able to run 4 at a time on a regular basis. The fans will be a bit of a let down, but I still love my Macbook.
I am going to change the blog around a bit, I want to get a custom design for the site, but with the holidays and work, I’m lucky to get time to post articles, much less change things around.
Permalink
11.02.06
Posted in VMware at 3:46 pm by Michael
Virtualization is the process of taking a physical server and turning it into a virtual server. A virtual server can then be run in a special environment where multiple virtual servers share physical memory and cpu. The process takes some time to master, but once you do, it reduces your cost of ownership on a server by quite a bit. The main problem with physical servers is space, they take up real (usually expensive) space. With a virtual server, you can pack multiple servers onto a single physical machine and save that space. It’s also handy to be able to deploy a virtual server to test things out before you do a widespread release. This applies to patches and software mainly, but it is nice to be able to load several different OSes, have them all running, and test things from each one.
The best benefit comes from the ease of maintenance after you virtualize. Once you have virtual servers running, administration becomes very easy. I use VMWare on the IBM Bladecenter. With this setup, you can log into the virtual server console, and control any of your virtual servers from a single software interface. This makes rebooting, and troubleshooting on multiple servers much easier than if you have to connect to each machine seperately, using the network, or even the local console (keyboard and mouse connected to the physical server). This means if you need to work with many servers, you save quite a bit of time if they are all virtual servers.
The main problem I run into while working with legacy physical servers is determining if they can be virtualized or if they must be migrated. Virtualizing entails running some software to get an exact copy of the physical servers hard drive, and transferring that image to a virtual machine with a virtual hard drive. This process means you inherit every problem that the physical machine may or may not have. The physical machine could have countless problems that aren’t apparent from a cursory inspection. A virus might be live on it, there could be legacy applications that hurt performance running in the background, or it could just have been initially setup incorrectly. Migrating a server entails installing a new OS into a virtual machine, and then installing the applications in use on the physical server, and finally moving the data from the physical server to the virtual server. Once you migrate a machine, most of the legacy issues I typically find in production go away. Knowing how to correctly do an initial OS setup in crucial to having a migration work correctly.
Virtualizing can bring many benefits to an Administrator’s day-to-day activities. Anything that can save you time will make you more effective when it comes to the things that matter. I highly recommend anyone interested in virtualization to get and install VMWare Server. It’s free for Windows and Linux, and can give you a small taste of the ease and effectiveness of Virtualization. I myself prefer the Linux version, because you can strip a Linux box down to bare essentials, you can make better use of the resources (cpu, memory) in your machine. The Windows version runs adequately, but Windows entails more overhead from the GUI than you might like on a virtual server. You can strip Windows down pretty well, but not quite as well as you can a machine running Linux. Windows forces you to use the GUI, and that is ram and cpu being used that could be better spent on a virtual machine.
The Enterprise level of VMWare Server is called VMWare ESX Server. ESX is very useful when you are going to use many virtual servers in production. I can attest it is the fastest, and easiest to use software of this level I’ve seen so far. It is expensive, but if you are going to be using virtual servers in production, it’s worth having. If you install multiple copies of ESX, you can aggregate the administration into a single interface using VMWare VirtualCenter. VirtualCenter connects to multiple ESX servers and allows you to administrate any virtual server on any ESX server from a common software interface. It’s quite powerful for large deployments of virtual servers, especially when you consider the cost of building the same sort of infrastructure for physical machines.
Virtualization can save you time and money. It can also simplify your daily administration and maintenance tasks. Using a single interface to control many machines is effective and efficient. You can easily modify and revert changes to virtual machines using the tools included with VMWare. I’ll get into that a little more in a later article, this one is for the “big picture” benefits. Patching, Rebooting, and remote trouble-shooting are all simplified on a virtual server platform, simply from having every machine “at your fingertips” so to speak. I cannot stress enough how much of a difference this makes in the amount of time I spend at normal administration. It has saved me literally weeks of time since I started using virtual servers instead of physical servers.
Virtualization is here to stay, and I’ll be blogging my various trials and tribulations as I learn to master this technology. I have quite a bit of experience with it already, but now I’m using the big tools, like ESX and VirtualCenter, rather than the smaller free versions. I’ve spent countless hours playing with VMWare Server and have found it to be the most robust, and easiest to use of the free solutions available. Don’t just take my word for it, download VMWare Server and try it for yourself.
Permalink