Fortysomething Geek

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.

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.

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.

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.

Read more »

I really didn't think this was possible - running a VM hosting another VM.

Yep. That is a few layers deep.

I was able to run VMware ESXi 5.0 Hypervisor server inside my Mac via VMware Fusion. Virtualized ESXi was able to host and run an Ubuntu LAMP server. I managed the ESXi server from a VM Windows XP. Under XP, I could easily load up and deploy my OVA provisioned guests in a virtual network.

Impressive.
If this is all greek to you, I am running a Virtual data-center off my Macbook. ESXi is an popular Hypervisor server that hosts VM (Virtual machines). I can do all my development on a Mac platform and test my provisioning virtually. The VM runs fairly responsive due to the fast SSD and Thunderbolt.

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.

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.

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.

The Fujistsu MX130 small foot print server is getting a lot of love these days.
In fact, I love it so much I decided to get a second one when it went on sale again.


I just upgraded the memory to Mushkin Silverline 32GB for 122ドル when it went on sale at NewEgg.


Now, I have a great little ESXI 5 Hypervisor server for under 400ドル with 32GB of RAM.

140ドル Fuji Server
122ドル 32GB of RAM
120ドル 6-core AMD FX-6100 CPU
12ドル extra gigabit card
394ドル total




I can run 20-40 Virtual Machines (depending on size and payload). Average LAMP VM are 256-512MB so if I only wanted to host Linux VPS, I think I can probably go as high as 50 LAMP VM.

I'll build my second MX130 whenever deals and bargains arises for components.