1. Prepare a Xen VM with a minimal install of CentOS/RHEL 5 (64bit or 32bit).
    1. Make sure you have set your host name and IP Addressing etc. The VM should have internet access (obviously).
  2. Install HyperVM following these instructions.
    1. Be sure to append [–virtualization-type=openvz] (omit the square brackets) to the install command.
  3. At the end of the installer, don’t reboot!
    1. The default OpenVZ kernel installed by the HyperVM installer won’t work inside of a Xen VM (it will work on a normal bare metal server). Download the proper kernel for your architecture: 32bit (i686) or 64bit (x86_64). At the time of writing, the current OpenVZ kernel was 2.6.18-384.4.1.
    2. You are specifically looking to download and install the kernel that starts with: ‘ovzkernel-xen’ anything else will likely install, but will not boot!
    3. Install using this command [# rpm -ivh ovzkernel-xen-*.rpm] – Don’t use [# rpm -Uvh] you will upgrade the installed kernel instead and you will lose the ability to roll back to a known working kernel should things go wrong.
    4. Open your /boot/grub/grub.conf file (in vi or nano) and make sure you are able to differentiate between the existing kernel and the ovzkernel-xen kernel. Perhaps append something to the title line, like ‘OpenVZ-Xen’. I saw three kernels in mine, the original CentoS 5 kernel, the OpenVZ kernel (installed by the HyperVM installer) and the OpenVZ-Xen kernel.
  4. Now it’s time to reboot. How you perform this step will be dependant on a couple of things.
    1. If you have console access to your VM (it may be via an alternate SSH connection or applet if your hosting provider has one), I suggest not editing your grub.conf file just yet. Connect to the console and reboot the VM. You can then catch the grub boot loader and choose the OpenVZ-Xen kernel (not to be confused with the similar named OpenVZ kernel). If all goes well, you can edit the grub.conf file later and set grub to boot from the OpenVZ-Xen kernel by default. If things break, you’ll either be able to reboot and choose a different ‘known working’ kernel, or your VM won’t boot at all. In this case you’ll have to ask your hosting provider to switch your default kernel back to the original kernel. If you have Dom0 access (you’ll know what this if you do) you can edit grub.conf via pyGrub and try again.
    2. If you don’t have console access, you’ll need to edit the grub.conf file first and set the OpenVZ-Xen kernel as the default kernel and reboot, hoping all goes well. As above, if all does go well, you’ll be able to login via SSH and also to the HypeVM control panel. If things break and you lose access to your VM, you’ll have to contact your hosting provider and have them investigate for you. You can assist them be asking them to configure grub to boot from the standard normal CentOS kernel again. Afterwards, when you have access, you can try again ūüėČ
  5. By default, HyperVM wants to use the ‘Xen driver’ as the virtualisation method. This won’t work, you can’t run xen VMs inside of a Xen VM. Why Xen is the default ‘driver’ when you chose OpenVZ at the very beginning? I have no idea.
    1. Use the following commands to switch the system from Xen to OpenVZ [#. /scripts/directory] [#¬†lphp.exe ../bin/common/setdriver.php –server=localhost –class=vps –driver=openvz] (omit the square brackets of course). There are two commands, the first changes the current working directory, the second changes the virtualisation driver.
    2. After a few moments, you’ll see a confirmation message.
  6. You’re done! You can now login to the HyperVM control panel, add IP Addresses and create VMs!

Comments, Suggestions, Requests, all welcome ūüėČ

I recently had a requirement to remove vmware tools manually from a windows 2003 server. This is what I had to do.

  • Remove any keys with a DisplayName of VMware Tools anywhere in the following keys:
    • HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionuninstall
    • HKEY_LOCAL_MACHINESoftwareClassesInstallerProducts

 

  • Remove the keys with a ProductName of VMware Tools in the following keys HKEY_CLASSES_ROOTInstallerProducts
  • Delete the branch named VMware Tools in HKEY_LOCAL_MACHINESoftwareVMware
  • Delete the "VMware Tools" directory within in the Vmware directory under Program Files
  • Restart the server.

Props to WarOnErrors.

After installing ConfigServer Security and Firewall, many of us try to achieve as many ‘green’ results as possible. The often tricky one (or two) options to achieve, is mounting /tmp and /var/tmp as ‘separate’ file systems. On a bare metal linux installation (no virtualisation) this is easy to achieve by creating a file system (partition or¬†pseudo¬†file system) and mounting it accordingly. Under virtualisation (openvz, virtuozzo etc) this is not so easy, in fact, it’s not actually supported at all. However, there are two things you can try.

  1. Nothing. Just leave it. After all, the message at the bottom of the check security page says ‘This scoring does not necessarily reflect the security of your server or the relative merits of each check’ In other words, getting all green doesn’t¬†necessarily¬†mean your server is secure.
  2. You can set up pretend mount points (this works on bare metal installations as well). Delete the /var/tmp directory and symlink it to /tmp (ln -s /tmp /var/tmp). Next, edit your /etc/fstab file and all the following line: /tmp /tmp   ext3    defaults,usrquota,bind,noauto,noexec,nosuid        0 0 Finally, be sure to change the permissions to 1777 (chmod -R 1777).

The second option above doesn’t really achieve anything except the green ‘OK’ from CSF. Traditionally, the /tmp and /var/tmp directory have been located on a separate file system, due to the volatile nature of the files and content that are temporarily stored there. If the server was compromised via this directory, it could be easy to stop the compromise by un-mounting the file system. Better still, if the file system itself was hacked or damaged, it would only be the /tmp and /var/tmp that was damaged, both of which are easily replaced and can be deleted, removed and recreated all while the system is still running, not to mention that no important data is ever stored in these directories either.

News Flash! -:- Newer Version of This Guide based on CentOS 5.3 (32/64bit) and VMware Server 1.0.9 Available Here

So you just installed CentOS 5, as your host operating system for the latest version of VMware Server, 1.0.3. However, vmware-config.pl tells you it is missing something.

libXtst.so.6

What is libXtst.so.6? Well, to keep a long story short, libXtst.so.6 is a set of shared libraries that are used by the X Windows system. Although the term X Windows has now been deprecated in place of Xorg, the libraries are still required and still retain the same name.

To install the libraries that you require, just enter the following as root (or you could use sudo if you have it set up nicely):

yum -y install libX11-devel libXtst

Once you have those two and their dependencies installed, vmware will no longer complain about missing components, but you may come across another problem.

VMware requires GCC to be installed, so that it can compile a kernel module and run happily each day forever until the sun goes down. As root, type the following:

yum -y install gcc

OK, so now you have GCC installed. If VMware complains about how it can’t find your “C Header Files”, you may need to do the following, as root:

yum -y install kernel-headers kernel-devel

Now, some people will argue that you just need one, and not the other. In my opinion, just get both. That way when you install something else that needs the other later on, you will already have it! Besides, it’s not like you are giving up gigabytes of space, it’s just a few megabytes.

Lastly, VMware will probably look for your C Header files in the following location:

/usr/src/linux/include

Unfortunately, it won’t be there. As root, type the following:

mkdir /usr/src/linux

cd /usr/src/linux

ln -s /lib/modules/<your current running kernel>/build/include include

Run the setup one last time, and hopefully everything will be fine! Don’t forget to add your selected remote access port to your firewall!

If anyone requires any further assistance, feel free to post a comment here and let me know!

If you found this helpful or interesting, why not Digg It?