Hi everyone,

To go along with the FreeBSD 8.0-CURRENT amd64 virtual appliance I released a few days ago, I’ve also prepared one for the i386 architecture.

Get the virtual appliance here: FreeBSD 8.0-CURRENT i386 virtual appliance

As always, comments and feedback to virtualization@sourcehosting.net is welcome. Enjoy!

Hi everyone,

Do you want to experience FreeBSD on the cutting edge without devoting a brand-new piece of hardware to it? You can test out the latest and greatest FreeBSD bits by downloading the FreeBSD 8.0 amd64 virtual appliance.

You’ll need a BitTorrent client, and once the download has completed, you’ll have a .ova file. This is a self-contained virtual appliance running FreeBSD 8.0-CURRENT amd64, and you can either import it directly into certain VMware products (e.g. VMware Workstation, VMware Player 2.x) or use VMware Converter to convert it into virtual machine format for use within VMware Server 1.x and other products that don’t read .ova files directly.

FreeBSD amd64 doesn’t actually require an AMD CPU to run as long as the specific Intel CPU is the correct architecture. Check for supported CPUs on the FreeBSD amd64 project page.

The virtual appliance’s root password is “password” and a minimal number of services and packages are installed. The virtual appliance is perfect for experimentation and testing, and please send any feedback or questions about it to virtualization@sourcehosting.net.

Enjoy!

Hi everyone,

I was excited to see VMware release the free ESX 3i software over the summer and had grand plans to install it on a spare SFF PC with a mini-ITX motherboard that I have laying around. I downloaded the installation bits and burned an ISO, salivating over the thought of a free ESX development box about the size of a large dictionary.

Whoa, nelly – not so fast! The ESX installer started up, chugged for a bit, and then told me that my CPU is not compatible. I guess I shouldn’t have been surprised, since it’s an EPIA Nehemiah M10000. I had to find another solution that didn’t include plunking down $$$ for a dedicated ESX host.

VMware Workstation to the rescue! If your PC has enough horsepower, you can install Workstation on it, create a VM for ESX3i inside of it, and then create your target VMs inside of ESX3i. It sounds crazy, but it works.

I started with Workstation 6.0.5 at the end of the summer and got everything working. After the evaluation ran out on the software, I decided to purchase it and eventually installed Workstation 6.5. As soon as I tried to start up my previously-working ESX3i VM, it kept hanging during boot-up, as seen here:

Originally, the following directives had to be added to the ESX3i .vmx file to get it to boot inside of Workstation 6.0.5:

monitor_control.restrict_backdoor = "true"
monitor_control.vt32 = "TRUE"

After some sleuthing around on the Internets, one more directive added to the .vmx file gets ESX3i booting under Workstation 6.5:

monitor.virtual_exec = "hardware"

Now you can even provision some interesting configurations using FreeNAS or OpenFiler to manage the disk space available to the VMs inside ESX3i. This makes it so much easier to develop a whole architecture on your desktop and deploy it right to a production ESX host.

Hi everyone,

Every now and again, a strange problem crops up with VMware Server. In this case, the VMs on one host began running with a very fast clock, even though the .vmx files contained the following line:

tools.syncTime = "TRUE"

Apparently, this setting helps keep the VM clock from slowing down too much, but it doesn’t do much when it’s going 1.5x faster than it should – whoa, Nelly! Running ntpdate every few seconds showed the clock resetting backwards 5-10 seconds each time. That’s going to play havoc with everything – log file messages, email timestamps, Makefiles and many other things.

I searched around Google for solutions, and 99% of the posts say “set kern.hz=100 in your /boot/loader.conf for a FreeBSD guest OS“. That’s great if your clock is slow, but it doesn’t fix this problem. A quick check showed that I had already added that setting a long time ago.

After more and more in-depth searching, a solution emerged. The host OS is RHEL4, and it enables CPU frequency scaling by default with the cpuspeed service. The idea behind this service is great, as it saves power, but it just wrecks the VMware timekeeping accuracy. Disabling the service fixes the problem for good:

# /etc/rc.d/init.d/cpuspeed stop
# cd /etc/rc.d/init.d/
# /sbin/chkconfig --del cpuspeed

Easy!

One final problem – the VM clock still runs fast until you reboot the host and the VMs on it. To get around the problem temporarily if you are running a high-availability service, add the following lines to your VM /etc/crontab file:

*/5 * * * * root /usr/sbin/ntpdate -s us.pool.ntp.org

I hope this posting makes the solution easier for someone else to find in the future!

Hi everyone,

A while back, I made some blank VMware VMDK images available in various sizes. I am now making some pre-formatted VMDK images available that are even easier to use. Of course, these images are specific to the operating system you’re using, and as long as that’s FreeBSD, you’ll be fine.

I can make pretty much any size or operating-system-specific filesystem type, so what else would you like to see?

• 10Gb FreeBSD UFS2 (10Mb zipped – LSILogic SCSI VMDK)
• 20Gb FreeBSD UFS2 (20Mb zipped – LSILogic SCSI VMDK)
• 50Gb FreeBSD UFS2 (50Mb zipped – LSILogic SCSI VMDK)

Hi everyone,

I updated the ports tree and repackaged the FreeBSD 7.0 VMware virtual machine that turned out to be corrupted in my earlier release. I apologize for anyone who was inconvenienced, and I still don’t know how part of one of the disks was corrupted, since the source image was fine.

Anyway, you can find the new download here: VMware 7.0 virtual machine with ZFS enabled

If you run into any problems, please contact me.

Hi everyone,

In a previous post, I asked for assistance about getting a FreeBSD 7.0 virtual machine running on VMware Workstation on MS Windows Vista. Well, it turns out I didn’t need any help after all – the torrent file was corrupted!

Somehow, one of the 2Gb slices of the VM’s boot disk was truncated to ~1.4Gb. I don’t know how it happened – perhaps during the ZIP compression. It’s very odd, because the rest of the slices were fine.

Anyway, I’m preparing a new torrent, and I’ll post the link when it’s ready.

Hi everyone,

A while back, I was setting up some virtual machines, each with a public and host-only network interface. I like using the host-only interface for high-performance VM-to-VM communications and then to expose the WAN IP to the Internet for public access.

I soon ran into a problem, though. What happens if a VM on one physical server needs to make an internal connection to one on another physical server? The first VM has to use the public IP address of the second VM, but I still want the connection to be essentially private and not route the packets outside of the firewall-protected LAN.

Here’s a diagram showing the VMware Server configuration with virtual machines and host-only networks (click to enlarge):

For the following examples, let’s use these IP addresses for the physical servers and virtual machines:

Hostname	WAN IP	LAN IP	Gateway IP
GW1	207.46.193.241	N/A	N/A
PH1	207.46.193.242	172.16.80.1	207.46.193.241
VM1	207.46.193.243	172.16.80.2	172.16.80.1
VM2	207.46.193.244	172.16.80.3	172.16.80.1
VM3	207.46.193.245	172.16.80.4	172.16.80.1
PH2	207.46.193.246	172.16.80.1	207.46.193.241
VM4	207.46.193.247	172.16.80.2	172.16.80.1
VM5	207.46.193.248	172.16.80.3	172.16.80.1
VM6	207.46.193.249	172.16.80.4	172.16.80.1

Notice that the LAN IPs are repeated for VMs on different physical hosts. That’s because the VMs are connecting to a host-only network on each physical machine and are independent of each other. Therefore, they can use the same IP numbers without conflicting.

Ok, so assume VM1 is a public-facing web server, and VM4 is a database server with no external services exposed except for ssh. Since there’s no way for VM1 to use VM4′s LAN IP address to connect to the database – the IPs are the same – VM1 has to use VM4′s WAN IP.

Let’s now trace where a packet as it originates from VM1 bound for VM4. This table shows the path that the packet takes, along with the source address as it passes through each hop.

Hop #	Hostname	Source Addr	Dest Addr
1	VM1	172.16.80.2	207.46.193.247
2	PH1	207.46.193.242	207.46.193.247
3	GW1	207.46.193.242	207.46.193.247

Woops – the packet has made it out to the gateway router (GW1)! That’s not what we want, because the packets exchanged between any VM should stay on the inside of the firewall. The same problem occurs if any VM on one physical machine connects to a VM on the other physical machine.

Luckily, this easily fixed by adding some static routes to each physical machine to help guide the packets where they need to go. Instead of allowing packets bound for a VM to use the default route and get sent to the gateway router, a static route redirects them to the next hop that we specify.

On RHEL4, the /etc/sysconfig/static-routes file controls any required extra routes. On PH1, the file will look like:

any host 207.46.193.247 gw 207.46.193.246
any host 207.46.193.248 gw 207.46.193.246
any host 207.46.193.249 gw 207.46.193.246

The file on PH2 looks like:

any host 207.46.193.243 gw 207.46.193.242
any host 207.46.193.244 gw 207.46.193.242
any host 207.46.193.245 gw 207.46.193.242

This simply means “when sending a packet to host X (e.g. 207.46.193.245), first send it to host Y (e.g. 207.46.193.242), because it has the information about how to get there”.

Once the static routes are installed, the packet trace now looks like:

Hop #	Hostname	Source Addr	Dest Addr
1	VM1	172.16.80.2	207.46.193.247
2	PH1	207.46.193.242	207.46.193.247
3	PH2	207.46.193.242	207.46.193.247
4	VM4	207.46.193.242	207.46.193.247

Of course, this can be extended across many virtual machines and physical machines, and it always helps to trace the packet and the network routes at each hop to determine where it’s going next. The traceroute command is your friend!

Hi everyone,

In a previous post, I postulated a solution for rotating the Apache log files produced by the VMware MUI application. Unfortunately, the MUI version of Apache doesn’t work well with logrotate, as I discovered over the weekend.

After receiving an alert on the cell phone in the middle of the night that the MUI was down, I discovered this in the /var/log/vmware-mui/error_log file:

[Sun Apr 13 04:02:03 2008] [error] Could not destroy the stale named pipe directory: /var/run/vmware//httpd/21157\n
[Sun Apr 13 04:02:03 2008] [error] VMWARE PANIC: \nNOT_IMPLEMENTED F(4023):707\n
[Sun Apr 13 04:02:03 2008] [error] Panic: Could not allocate temporary context.\n

Ok, perhaps there’s a better solution than logrotate and one that I’m already using with Apache in all of the SourceHosting.net virtual machines. A while back, I discovered the httplog tool, which builds on the premise of the standard rotatelogs tool that’s part of the Apache distribution. Since it doesn’t restart Apache when it rotates its log files, I suspected it might work well with the MUI.

Since the MUI is running on a RHEL4 system, I created an RPM of httplog instead of installing directly from the source distro. After many years working with Linux and FreeBSD, I much prefer everything to be installed from an RPM or a port, just for sanity’s sake and managing future upgrades.

The next step is to integrate the httplog command into the MUI’s httpd.conf file, found in /usr/lib/vmware-mui/apache/conf. If you’d like to update your file, download this patch file, and run the following commands (after installing httplog):

rm -f /etc/logrotate.d/httpd.vmware
/etc/rc.d/init.d/httpd.vmware stop
patch -b --verbose  /usr/lib/vmware-mui/apache/conf/httpd.conf < httpd.conf.httplog-patch
/etc/rc.d/init.d/httpd.vmware start

After starting up httpd.vmware, your /var/log/vmware-mui directory should look something like this:

total 16
lrwxrwxrwx  1 root root   36 Apr 14 17:12 error_log -> /var/log/vmware-mui/200815-error_log
-rw-r--r--  1 root root  186 Apr 14 17:12 200815-error_log
lrwxrwxrwx  1 root root   41 Apr 14 17:12 ssl_engine_log -> /var/log/vmware-mui/200815-ssl_engine_log
lrwxrwxrwx  1 root root   42 Apr 14 17:16 ssl_request_log -> /var/log/vmware-mui/200815-ssl_request_log
lrwxrwxrwx  1 root root   37 Apr 14 17:16 access_log -> /var/log/vmware-mui/200815-access_log
-rw-r--r--  1 root root  396 Apr 14 17:31 200815-ssl_request_log
-rw-r--r--  1 root root 3820 Apr 14 17:31 200815-ssl_engine_log
-rw-r--r--  1 root root  328 Apr 14 17:31 200815-access_log

I’ve got my httplog process configured to encode the week number into the Apache log filenames, rotate them each week and compress the rotated logs. If you want to automatically remove compressed logs after a certain number of weeks, a simple cron job accomplishes that.

httplog accepts many different filename configurations, so man httplog for more information or post questions here.

Hi everyone,

In a future post to follow very shortly, I’ll discuss a change to the VMware MUI application that relies on the httplog tool to perform Apache log rotation.

The first thing I had to do was get httplog installed on the RHEL4 system here. I quickly discovered that the source distribution wasn’t too good at detecting the proper version of zlib and configuring the Makefile accordingly. If you don’t have exactly zlib v1.1.3, the configure script assumes that you don’t have it at all. If you have a later version of zlib (like RHEL4 does), you have to do some hand-editing of the source code to build the tool.

I found an httplog SRPM online, but the .spec file wasn’t quite up to snuff. I added some dependencies and tweaked the configure script a bit. If you just want to install the tool, download the httplog RPM, or you can make additional tweaks with the httplog SRPM.