VMware Fusion 7 Pro. A must have upgrade.

VMware just released Fusion 7 Pro with some major changes and updates. The most obvious are support for Yosemite OSX 10.10, improve performance, GPU upgrades.

However, if you are Mac based developer who is involved with ESXi or vSphere, this is an absolute must-have upgrade. This version definitely gives weight to the "Pro" denomination. The remote server integration makes it well worth the $80 upgrade and $150 full price.

So what is new?

I'm not going to rehashed some press release or product page. You can read that directly on VMware's own product page here:http://www.vmware.com/products/fusion-pro/ . Improved performance. Check! Improved Retina support. Check!

The "what's big" is the vSphere, ESXi support. This is only in the Pro version and it definitely makes it a big differentiator between the regular Fusion 7.

For those Mac developers who tirelessly worked for years with ESXi, your normal modus operandi was to install a Windows VM and run vSphere Client in a Windows' Guest. Now,  a majority of those functions are built right into Fusion Pro.

In the screenshot below, I can see my local VMs and in the preview pane and I can now see the inventory of my remote Virtual Machines. I even get general stats on usage of the remote server.

Yep. Now you can start, stop, modify remote Virtual Machines, and even deploy OVFs right inside Fusion Pro.

Impressive indeed!

You simply, connect and you have some basic control. This is simply a killer feature.

Another benefit to this is you can now run Virtual Machines remotely. I have 6 and 8-core AMD ESXi white box servers running in my basement. They have  16 and 32GB of RAM with 3 terabyte of data storage. I don't need to even run my development VMs on my Macbook. Rather, I can control and run them remotely. Sure, you can VNC or RDP in but that method is often laggy and unpleasant. Nor can you enable features of the guest via traditional remote desktop connectivity.

Here, you can run and enable device features remotely. For example, I run a proxy server and have a stand-by failover VM on another server. Both are running with the same IP. When one fails, I simply enable the networking on the standby unit to take over. The guest will utilize whatever CPU and GPU processing power your remote host hypervisor has.

So if you have VMs on a ESXi, vSphere or Windows Workstation, you can now run your VM on beefier, remote boxes. The whole start-up and control process feels and acts if you are running locally. I am very impressed. You won't get unity or shared folders on remote VMs. Thus, you'd still need to run those VMs locally for those guests that need those features. However, for most console OSes (Linux apps servers), you can simply run them remotely.

Furthermore, you can now provision on-the-fly fairly quickly.

Fusion 7 Pro has the ability to export OVFs built in the interface.  You now no longer have to run command line tools like ovftool to export your Virtual Machine  into a ESXi/vSphere format. You can even drag-n-drop local Virtual Machines you built on your Mac and it will upload and deploy on your ESXi server in a seamless Mac-like fashion. Again, killer upgrade.

Pictured below is an example. I dragged a local LAMP stack from my Macbook onto my remote ESXi server box and voila. Instant provisioning.

You can also export and download as well.

I must say, these Pro features are impressive. It doesn't have all the features of the Windows ESXi client but it covers most of the stuff I need on a day to day basis. The OVF export takes the hassle of tweaking VMDK and thin provisioning.

Now, let me comment on some of the other features of Fusion 7.

You can select what GPU you want to use if your Mac has a hybrid graphics card set-up. Before, I had to use some hacks to disable the NVDIA card but now, you can set it in the VM guest.

This will save battery power considerably for Macbooks with dual GPUs.  Console based OS and older operating systems will no longer start the GPU if you don't want them to. My macbook no longer whizzes the fan when I want to fire up an old copy of Windows XP or CentOS.

They've also improved Retina support. For non HiDPI operating systems, the rendering doesn't look so bad anymore. Pictured above is Windows XP and it now looks fairly good without the nasty dithering blockiness found in earlier versions.

User interface wise, it is an clean, streamlined new look that will fit right in with Yosemite.

Overall, I am very impressed. I am definitely giving this upgrade a big thumbs up.

VM snapshots and why you should use them.

I've been playing with snapshots inside VMware Fusion (the Mac version of VMware Workstation) and I gotta say, this is one of the greatest tool to have. You can read up on countless articles and blog post of how cool it is. There are many reasons why you should use it. As many of the best practices suggest, it is not a substitute for backups or restore point.

Having said that, I use them for testing and quickly provisioning. This morning, I was playing with building a quick and dirty LEMP (PHP NGINX MySQL) stack from a bare clean Cent OS 6.5 build.

My default VM is about 900 MB and I can easily back that up pretty quick. Screw up? Easy, pull out the clean virgin image and start over. However, with snapshots, you can do side-by-side comparisons that is pretty invaluable. I've used snapshots before but not on a regular basis because export and migrating VMs with snapshots tend to be a hassle. Now, I run multiple snapshots and once my automation scripts all work fine and dandy, I dump the snapshot VM and finalize my build off a clean slate back-up.

After starting with a clean, virgin build, I built my list of what I needed to install into a BASH script. The script sets repositories, launches services, set IPtables, copy configuration files, and modifies /etc/ files. For example, with NGNIX, you have to make sure you change user/groups from apache to nginx, define the worker process, etc. So I did this all manually to see if I had any typos as I normally did.  My script also does things like set CRON jobs, copies SSH keys, and modifies SSH daemon logins for keys only. The point was to make it completely automated with only a few clicks and password entries. This would something analogous to installing a pre-built VM appliance but defined for my use case.

Then I reverted back to my clean slate snapshot. Launched the VM and ran my installation script. It ran flawlessly. I had a whole LEMP build running in 2 minutes with all my settings I needed.

So in short, snapshots are pretty awesome. Again, this is good for quick provisioning testing and comparing if a service update breaks anything. I can see it for those uses.

VMware ESXi, Xserve, and virtualizing your old Mac server infrastructure

I've been asked quite a bit on this blog, offline and via email about Mac Virtualization. Specifically, virtualizing old Mac OSX servers that previously ran on Apple's discontinued XServes. With VMware's ESXi, you can easily consolidate clusters of old Mac servers into fewer machines and easily provide failover and redundancy. For example if you had 4 Xserves, you can dedicate two as Hypervisors and virtualize all four older Mac Servers on a single machine. With two hypervisors, you would have duplicate and redundant standby failover new Mac servers.

Hopefully, this post will be a guide to help many of those who want to consolidate and virtualize their old Mac OSX 10.6 (and up servers). Think of this as a road-map, blueprint from this fortysome geek. This is my article on running ESXi on the Xserve and virtualizing old Mac servers.

First of all, you will need a few things.

• VMware's Free Hypervisor server, ESXi version 5.1.0
• VMware's Desktop Fusion. 
• an INTEL XEON Power Mac or XServe. My host is a XServe 3,1 which was the last one from 2009.

How-To: Multiseat set-up with VMware Fusion 5. Independent mouse keyboard monitors.

With VMware Fusion, you can easily set up a multiseat configuration where the Virtualized guests act and operate as an independent computer with its own mouse and keyboard. This is called multiseat.

Multiseat computing is where a single computer provides multiple, independent, multi-station computing where multiple users have their own console access.
Sounds confusing?  Well, it is basically one computer providing resources to multiple workstations where each users have their own monitor, keyboard and mouse.

The picture from HP below illustrates how a multiseat set-up works.

In essence, each user will have their own computing experience. They have their own desktop and full control as if the multiseat clients are real independent computers.

This is not a new idea. Companies have been doing this for decades. There are even thin client distributed multiseat devices on the market. Plugable has one but requires a dedicated Windows Multipoint Server 2012 for Windows or a custom Fedora Linux build.

Today, I am going to show you how to do it with VMware Fusion 5. In fact, you can and provide multiple operating systems to each and every user. Mom can be doing her spreadsheet in Windows XP while little junior is surfing the web in Chrome OS (Chromium) and everything can be hosted off a single Macbook. You are not tied to a hosted server solution.

The requirements are: Extra monitor, extra set of keyboard and mouse. You'll probably need a USB hub. This is the minimum for a single multiseat setup.

Extra network card and extra USB sound stick are optional. If you need more seats,you will need to look at extra graphics output. In this case, you can use a displaylink adapter.

VMware Fusion setup.
The goal is to setup independent monitor, mouse, and keyboard for your guest.

The first part is easy. Set your guest to fullscreen on your second monitor and make sure you disable the "Use All Displays in Full Screen" option. Your guest(s) should start up on their screens.

Getting the extra, external mouse and keyboard isn't so straightforward and obvious. By default, this is disabled in VMware. It requires a little editing of the .vmx file in your VM Guest.
Go to your VM guests, show contents and open the .vmx file. You will need to add a line in the .vmx file that allows the guest to capture and use USB HID (input devices).

usb.generic.allowHID = "TRUE"

Once this is done, go to your USB&Bluetooth settings and assign the external USB keyboard and mouses to your guest. Once this is done, any mouse/keyboard movements will be independent from your host computer. This is how you set-up an independent mouse and keyboard for your VMware guest machine. Here, I paired an external Apple keyboard and mouse to my VM.

Next Steps.

Thats it. The only major hurdle is to get USB HID devices to recognize.
Note. Not all mouses and keyboards will work. You will need to use one with a standard HID interface.

The next steps are optional.

Picture below is my ad-hoc multi-seat set-up I setup for my Macbook Pro. It is a USB 3.0 four port hub with a USB 3.0 Displaylink HDMI adapter, a USB 3.0 Gigabit Ethernet adapter, and an extra set of keyboard and mouse. There are now USB 3.0 Displaylink port replicators on the market that you can use but those will cost you some money.

The extra network adapter is totally optional as you can NAT with VMware.

If you want a separate network interfaces for your users, you will need to setup bridging and assign a network card to your guests.

Once this is setup, the guest will now be a completely separate entity from your Host. It will act and behave as if it is an independent computer on your network.

Now, this is where things will get interesting in the future. With Thunderbolt docks coming in from Sonnet and Caldigit, I'll be able to set-up secondary multiseat guests with their own fast network and high-resolution (2560x1440) displays.

You can also do multiseat on-the-go.

Below is a hypothetical portable setup - portable MHL HDMI battery powered monitor and a separate portable keyboard/mouse. The main macbook is running OSX 10.8 while Pear OS, Ubuntu Linux is running off the portable monitor. This is pretty awesome when you want to demo client-server applications in meetings.

A simple youtube example:
http://www.youtube.com/watch?v=h8q-4VS1VXE

Once I get my cables and adapters for my Motorola Lapdock, I will update this post with this as my thin client. Also, I got this partially working in a Linux Host running VMware's free VMware player for Linux. I could get the keyboard but not the mouse to act independently.

Hmmm. Motorola Lapdock as second multiseat thin-client console.

First attempt at VMware ESXi 5 on Apple Xserve

A few post back, I wrote about converting real physical Macintoshes into VM (Virtual Machine) guests. Today, I am going to blog about my first attempt of installing VMware ESXi 5 hypervisor Virtualization server on a 2009 Apple Xserve 3,1. This was the last Xserve before Apple discontinued the line.

The purpose of this exercise is to see if I can recycle some old Xserve to hosts and consolidate older Mac OSX servers running Quicktime and Indesign services.

Installation was a breeze. I had an ISO and hit the "c" key at boot and selected the CDROM. Installing ESXi 5 was no different than installing it on a Dell. I picked a 8GB USB stick and installed everything onto a bootable USB stick. Once prompted to reboot, I had to hit the option key to choose the USB stick which happened to be properly EFI made.

I then configured my IP and logged into the Xserve through the VMware view client. I couldn't format one of the disks from the Xserve's SAS bay. VMware recognizes and it probably has some baked Apple firmware on it. I'll try with a different disk later. However, I was able to mount iSCSI and NFS shares to test.

I was able to load up my Linux and Windows VMs with no hassle. Getting a OSX guest will take me some time to figure out. I converted a Fusion guest with the ovftool but was not able to install my guests. I will play with it more and report back.

Right now my Xserve only has 6GB of RAM so I'll need to max that out and try adding eSATA or SAS storage to the ESXi build. My Xserve has an internal 128GB  boot SSD so I may try re-installing on that or create a datastore on it.

Convert a Physical Mac into a VM Guest under VMware Fusion 5

In the PC World, there many cool migration tools to convert a live, physical and running Windows machine into a VM (Virtual Machine) guests. I have migrated quite a few using VMware's own migration tool and they work great. Converting Linux and OSX isn't so easy.

OSX makes it much more difficult but it is not impossible. I plan to convert some Apple Xserves into VMs and consolidate them into a few running ESXi 5. That will be a later post as I am getting my feet wet; figuring this out and sharing it to those interested.

This tutorial will use VMware Fusion 5. You will need Fusion 5. It doesn't cost much and apparently the licensing allows you to install on 3 macs which is way cool.

I have switched completely over to VMware Fusion 5 from Parallells and VirtualBox on the Mac platform. It makes it  easier to convert a VMware machine build into something I can import into ESXi. The difference between Parallels, I won't go into here but so far, I am digging Fusion. I really like the fast suspend.

To Clone a Physical Mac there are a few things you need to consider. 

1)Is it legal?

Well, Servers from 10.5 can be virtualized. Workstation/Desktop (non-server) OSX 10.7 and 10.8 can be virtualized. For my use case, yes, I am completely legal.   I am converting a 10.6.2 Snow Leopard server. I'll even try as far back as 10.5 if any of those still exists in my inventory. There are back-door step (changing a plist file) to virtualize 10.5 and 10.6 non-server but I won't go there.

2) You need to build a base OS build from scratch to act as your Cloning "middleman." This should be a minimal Mac OS X VM guest build just big enough to run something like Carbon Cloner

3) You should have a spare USB drive or network share to store your "cloned disk images."


How To Convert  a Physical Macintosh into a VMware VM Virtual Machine.

It is a multi-step process so I will outline how I successfully converted a few Macs.

Step 1. Clone your Physical machine using your cloning tool of choice. CarbonCloner is the most popular. Clone it to a Sparse Disk Image. It makes it easier to transport and store multiple clones. Do not try to clone to a drive and use it as your source. It will probably be a waste of disk storage and you wont be able to boot from it in your VM. Stick to creating DMG images you can clone to.  I won't go into details how you do this but there are probably hundreds of tutorials on cloning your mac on the internet. If you are a mac IT pro reading this post, it is most likely you've already done this.

Step 2. Build your "middleman" OSX build. Here, you have to actually install a full running OSX that runs inside Fusion 5. Trust me, it is pretty easy unlike various hack attempts in the past. No pseudo hackintosh in a VM or special CD-ROM iso boot disk. It is a straight install as if you are installing on to a real Mac.

I chose something simple. I did a quick install of 10.7. You can even install from a DMG. I believe I used the ESDInstall extracted from the app store download. The whole process took 20 minutes on my setup and the size was around 12 GB for a virgin system. I simply stored my build on an external drive that I can shuttle around.

OK. We've gotten this far. At this point. I would strongly suggest backing up your middleman OSX so you can re-use again if you want to clone more physical Macs. You will end up discarding the middleman's drive when you are finished.

Step 3. Add additional Virtual Hard Disk(s) to your "middleman" OSX build. In my example, I added two more just for the sake of experimentation.

Step 4. Boot into your middleman OSX, format your additional virtual drives and prep them for destination clone. Remember to format them GUID.

Step 5. You should have your sparse disk image from Step 1 from somewhere accessible by the middleman OSX. You can copy from the network or from a share if your guest's OS drive is big enough.

I much prefer using a USB drive with all my builds. Simple. Just plug in an external USB drive and allow Fusion to take ownership. USB 3 is supported on Macs that have USB 3. The VM will see the USB mounted mac drive as a mounted external drive just as your normal hosts sees it.

Step 6. The Clone process. If you've gotten this far, you are 90% done. Run Carbon Cloner or whatever cloning tool you have to clone your sparse image to your second or third newly added virtual drive. Let the clone process run the usual course as you would clone a real mac.
As you can see in the screenshot,I am cloning from my sparse disk image.

Step 7. When finished, shut down.
If you think you can reboot into the next step, you will be in for a big surprise. This is the error message I got from trying to boot a 10.6.2 server from a 10.7 middleman install. Unfortunately, there are probably boot flags and indentifiers that restrict what can run/boot on what OS.

You might be safe and and skip to Step 9 of you are cloning from the same build as your middelman OSX. For example, cloning from a real physical 10.7 Mac if you were using my example.


Step 8. Now, this is the most important step I had to figure out. Change your Virtual Machine's device setting. It is not easy to find and not so obvious. Click on the "General" under the System settings.

And this the part that is not so obvious. The Name and OS look like normal labels.

But they are actually clickable input fields. This is my pet peeve. It shows a lack of UI (User Interface) understanding in the most fundamental way in regards to how applications should be designed.  The gist of this section is, you have to change the OS device label to the updates guest should be running. My original build was 10.7 and now, I had to now change it to 10.6 so I can boot into a 10.6 build.
To boot back to my middleman OSX, I would have to go back and change the OS device label back to 10.7

And that is pretty much it.

Step 9.  Select your new Virtual Hard disk as the new boot drive under "Startup Disk" from the main Settings. Reboot and test your new guest VM.

And Voila! An older 10.6 Xserve build running inside Fusion on my Macbook.


At this point, you should just delete the original drive containing the bootable "middleman" OSX. You can remove it from your inventory from the settings. Now, you should have a full running clone of your existing physical mac. You may want to install VMware guest tools but for me, I will wait till I have my builds migrated over to ESXi.

So far I have a few Macs virtualized and I will undergo some testing before I embark on building out an ESXi 5 build on a physical 12 core XServe which will host these new Mac guests.

There you have. Hopefully this will help some people looking to virtualize their macs.

Extra Credit for Mac IT guys:

And a little extra tidbit of info. If you are looking to doing this as a failover precaution due to the fact Xserves are no longer being sold, you can do scheduled nightly clones from a live running real mac. In essence,have a VM guest that is continually synchronizing with a live mac in the event the live mac fails and the VM guest can take over.

This is my style of ghetto IT that works:

You would need to set up two Carbon Copy schedulers. One on your live Mac and one on your middleman VM mac.

Either your live mac or VM Mac would need to share out a volume or have both access a shared network storage. The Live Mac would backup nightly to a sparse image on the shared network volume. Then schedule the middleman mac to clone from that nightly backup to your new VM second drive. You would need to schedule them apart to let the live mac to finish it's clone. Usually it should be quick because Carbon Cloner doesn't do a full clone on subsequent clones. It only copies the incremental. You can also use SuperDuper, Chronosync or old fashion rsync. With rsync, you just need to add the -E flag to copy extended attributes. I would personally run a cron job with rsync every hour to get at least an hour of synchronized data.

So in the event your Xserve (or other Mac server) physically dies, you should have a fairly up-to-date VM guest ready to be fired up and run while you go ebaying for a replacement Xserve or buy a new Mac Pro.

VirtualBox Headless Server vs Vmware ESXi

 I've started to notice a few twitter and blog posts about running VirtualBox headless as a VM server. In short, have a dedicated machine to host and run VM guests that can be managed via a web console.

Well, there is no such thing as a VirtualBox server. VirtualBox is a Type 2 Hypervisor that runs as an application in a hosted operating system.A true virtualization server would be a Type 1 variety like VMware ESXi or Citrix XenServer. However, that hasn't stop many people from running VirtualBox headless with a web based front end management tool.

In fact, in certain instances, it is a great way to recycle old machines.  Some Type 1 hypervisors have certain hardware requirements that exclude a large number of older machines. For example,VT-x and certain virtualization features of the CPU and chipset are absolute requirements. VirtualBox tends to be more forgiving. I have quite a few old Dell rack servers (1950,2850,2950s) that don't quite meet many of the VMware HCL (Hardware Compatibility List). In fact, depending on the generation, a few of them wont even install ESXi 3 or 4. Hence, despite what people say, you can run VirtualBox as a headless VM server.

There are plenty ways of setting up a VirtualBox server. The most likely way is to install a minimal footprint Linux distro like CentOS, Debian or Ubuntu and install PHPVirtualBox. PHPVirtualBox is a PHP-based web base front end that employs AJAX and PHP to manage VirtualBox.


Here are some relevant links:
https://code.google.com/p/phpvirtualbox/

A step by step how-to:
http://www.howtoforge.com/managing-a-headless-virtualbox-installation-with-phpvirtualbox-on-nginx-ubuntu-12.04

I have a few headless VirtualBox headless machines under Debian and they work quite good for their intended purposes. I run low-level, non mission critical things like Squid, Nagios, and other  network/intrusion monitoring systems.

Benefits of VirtualBox headless over something like ESXi.

The key gain with VBOX (VirtualBox) is familiarity and cross platform. VBOX is free and works across platforms - Linux, OSX, Windows. You don't even have to run a Linux host. You can choose an old MacMini with OSX if you like. You can download images, build appliances and they pretty much work on any machine by copying the files. Most of the people I know who do desktop virtualization use VirtualBox because it is free and cross platform.

You get to test and stage your VM guests on your workstation or laptop. You can build your great web LAMP app on your laptop and easily deploy by copying via something simple as a USB stick. You can simply SSH into your VirtualBox host, mount the drive and copy your files and be ready in a few minutes. When you have 10-20GB VM disks, it is faster to sneakernet the files via USB than over the internet. ESXi does not recognize inserted USB devices so you have to remotely copy files over to your VMFS data-stores. This requires setting up NFS/iSCSI shares , SFTPing your files, or use the Windows application to upload your files. For a non-window user, this is a hassle. In short, I find it easier to get VMs loaded onto the VirtualBox.

Next, the front end is standard web interface and works on phones and tablets using any modern browser. The web app is amazingly well done. You can build VMs from scratch, clone guests, start and stop VMs. If you are familar with the VBoxManage terminal commands, you can SSH into to your host server and manage from the console quite easily. I teach junior developers and have a VBOX machine loaded with a bunch of turnkey LAMP iso. They get to learn to install/build lightweight Linux servers using the web browser interface to VirtualBox.

I also like the different networking options of Virtual Box (bridge,nat,host-only).  Unlike ESXi, your guests can run under NAT mode; meaning they do not require a dedicated IP or actual access to a network interface.  This is handy if you are running something like NAGIOS that doesn't need to be access by the outside world. Nagios works fine behind a NAT. Lastly, the biggest advantage is RDP (Remote Desktop Protocol) console access. I don't need a dedicate app to access the desktop/console of my guest machine. I can use any RDP applications including those found on smartphone and tablets.

ESXi is not as easy to use as VirtualBox. Datastores reside on VMFS (VMWare File Systems). If the ESXi box dies, you can only access the contents of the disk from another ESXi machine that can read VMFS. You can do FUSE-VMFS but I won't go there. With VirtualBox, you simply pull the drives to another machine with similar OS or File-system access. Backups with VirtualBox can be easily automated by the host OS. I can use rsync to copy images to remote backups easily.I'm certain VMware has some nice enterprise features for cloning/migration/etc but my post is intended for those who want to consider using the free version of ESXi.

Another big negative is managing ESXi requires a Windows machine with a dedicated VMware View application. In fact,I manage my ESXi server via Windows 98 running inside VirtualBox. I rarely use Windows and prefer not to boot out of Linux/OSX into Windows 7 just to use one application.


Now for the advantages of ESXi over VirtualBox (headless).

ESXi is a Type 1 baremetal hypervisor. It runs its own small OS that can be booted off a small USB stick. The OS is minimal and its only job is to run Virtual Machines. You don't get the overhead layer of running a host operating system. It runs much much faster without that extra layer of complexity found in Type 2 hypervisors like VirtualBox. On average, my ESXi baremetal OS consumes like 40-80 MB of RAM. The rest of the RAM are dedicated to guests VM and some overhead to manage them. Did I mention it was a small footprint? The whole server can be installed on a flash card or USB stick. It takes a total of 10 minutes to install and get ESXi up and running. With VBOX headless, you have to install the host OS, harden it, install LAMP, set permissions and modify a bunch of config files.

Most importantly, ESXi is much faster than VBOX. There are countless benchmarks on the internet if you care to look.VT-D hardware access if your hardware supports it. You can dedicate physical hardware to guest OS. For example, you can install a Windows guest to access a physical GPU video card. In short, you can run a graphical OS like Windows with hardware acceleration to a large monitor from your "headless" server. All of my experiment with VBOX headless were for low volume material. I would not entrust running a high volume web server off VirtualBox. With ESXi, I would not hesitate to use it for production.

I wont go into the hundreds of reasons why ESXi is better than VirtualBox (e.g. setting resource pools,etc) but the key thing for me is the reporting and statistics. The reporting allows me to examine my guests performance and tailor and allocate resources for their consumption needs. Before, I was allocating 512MB, 1 GB or 2GB of RAM to various "lightweight vms" in VirtualBox and had to constantly log into their consoles to monitor their performance needs. With ESXi, I can graph and visualize their needs after a few benchmarks/testing. For example, with one particular VM guest, I found out all I needed was 384MB ram and 2 CPU vs 1024MB and 1 CPU based on extended analysis.

The screenshot shows a typical scenario on how I may benchmark and prep my guest VM. This particular one is a small web app that serves 5 users and generates PDFs. My test consisted on running several concurrent hits and measuring how long it would take to generate 1500 PDFs. I was able to see the effects of different CPU and RAM settings effected my performance. In this particular example, 768MB and 2 cores was the sweet spot ( vs 2 cores/2GB RAM  or 4 core 512MB). You simply can't do this with VirtualBox.

There are also good 3rd party tool and apps with ESXi. The iPad is handy as well when used with the mobile access appliance. It is good for getting an overall picture of your host and guests. If I had the Vsphere license, I figure I could probably do a bit more.

There you have it. My thoughts on running VirtualBox headless as a VM server. I hope you enjoy the insight.

Windows 3.1 under VirtualBox

Words can't describe the nostalgic feeling. I was never really fond of Microsoft's original major Windows operating system, 3.1. It had its uses back in the day on those old dual-scan TFT Toshiba laptops I use to run in college. I can still remember the flickers and the side trackballs. I was always an Amiga guy back then. I was the only one in college to do all my homework and work on an Amiga 1200.

Here it is running in 2013 under VirtualBox.

Notice how DOS 6.22 even recognizes my AMD FX-8320 8 core processor.

The year 2013 doesn't seem to effect to operating system. Windows can go well past any Y2K fears.

Unlike Mac OS 9, I couldn't get Windows 3.11 to run 2560x1600 on a 30" screen. I don't know what to say about the 800x600 256 colors!

Finally a good MySQL client for Linux, using WINE Crossover

If you've been running Ubuntu 11.04 and up, you will notice Canonical no longer provides support for the classic MySQL Query Browser and Admin. Instead, you are relegated to using MySQL Workbench or use an application like Emma.

Well, some people are set in their old ways and do not like to use something monolithic as Workbench. For example, if all you need to do is query, why go through the steps of making profiles to connect to random MySQLservers?

During the Election, Crossweaver gave away copies of Crossover for Linux and OSX. Crossover is a proprietary commercial version of Wine and works quite nice. It is not an OS virtualization tool like Vmware or Virtualbox. It is more of a run-time, application compatibility layer to allow you to run (some) Windows apps inside Linux or OSX. Instead of launching a heavy weighted OS, you launch a Wine Bottle and run your Windows app inside Linux with full access to the native filesystem.

How does it work? Quite fantastic. I installed the classic MySQL windows tool, HeidiSQL (a popular Windows MySQL client), Komodo Edit and Notepad++ with no problems.

HeidiSQL is so far superior to Emma.

Installation couldn't be easier. Build a bottle and select your .exe or .msi installer.

Like I wrote earlier, the app works within the OS. You can access your services locally like you do on any other native application. File-system is visible as well as networking

Pay attention to the screenshot below. I am connected to localhost (127.0.0.1). My local server is Ubuntu and my local client is WindowsXP. Cool. Dual identity.

Crossover works great on Mac OSX as well. However, I don't have applications deficit on Mac OSX so I wont be using it much on a Mac.

If you don't want to use Crossover, WINE is freely available.




Links:
http://www.codeweavers.com/products/
http://www.heidisql.com/
http://www.winehq.org/