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.

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.

Here is a good deal not to pass up. Small net-top AMD APU E-350 barebone computer.
It is currently 120ドル (110ドル after rebate) with 64GB OCZ Agility SSD at NewEgg.



It is the size of a few DVD cases (19 x 14cm and 2.5cm tall). It supports one 204 laptop dimm and a 2.5" laptop drive. The power draw is 14-23W (idle to playing video).

It comes with a SSD and I have a few laptop memory lying around. At 110,ドルwhy not?

It is 110ドル after rebate today: http://goo.gl/DULcp

Slick deals thread on this.

Update: here it is.

I recently built a FreeNAS ZFS RAIDZ box for my personal backup archives. I wanted something elegant and low powered with the ability to run ZFS. FreeNAS is a NAS appliance built on FreeBSD. It supports the ability to run the ZFS filesystem and can be booted off a small flash storage like USB or Compact Flash.

I selected the following components:

• 6 X Hitachi 2TB 7200rpm Desktars 3.5 " drives
• ASUS E35M1-I Mini-ITX Motherboard with an AMD dual core E-350 and 8GB of RAM.
• LIAN LI Silver Aluminum PC-Q25A Mini case
• FreeNAS-8.2.0-RELEASE-p1-x64 (r11950)
• 8GB internal Patriot USB stick as OS boot

A few notes on my setup:
The ASUS E35M1 is a low voltage netbook AMD Fusion CPU (same one found in the Thinkpad X120E) and supports six SATA 3 6Gb/s ports. The LIAN LI PC-Q25 case can hold up to seven 3.5" hard drives. Five of those seven drives can be hot-swappable.

Here are some pictures of my build.The fit-n-finish on the LIAN LI is pretty impressive. The machined aluminium is well made. This case was clearly designed to be a HTPC or NAS box. It fits well in my Apple - Macintosh environment. Except for the logo up front, it is one slick looking piece of gear.



Picture below depicts drives loaded up. There are five hot-swappable bays. I had to put this to real world practice by taking out drives while the OS was running and without rebooting! The backplane is pretty interesting since it uses molex connectors for power.





With 8GB of ram, I have enough to run ZFS and RAIDZ; giving me roughly 9TB useable space.



After my build, I started to notice some degraded RAIDZ errors on my 3rd disk. Disk #3 seemed fine. I zeroed out the data and booted a different OS (Linux Mint) and copied files with no integrity issues. I tried the drive in different computers and everything checked out fine (S.M.A.R.T) and other scans. However ZFS zpool was giving me checksum errors. Well, it turned out to be a case of "silent data corruption." Linux Mint and Ubuntu did not see any problems but FreeNAS was able to give me a good heads up. It turned out to be a bad SATA cable. Once replaced, everything was fine.

In terms of performance:

Running a short DD benchmark,I was getting 263-268 Megabytes per second on the internal bus. This is pretty decent considering it is a RAIDZ disk array.

 [root@RAIDZ] /# dd if=/dev/zero of=/mnt/RAIDZ/test.dd bs=2048k count=10000 
 10000+0 records in 
 10000+0 records out 
 20971520000 bytes transferred in 74.518446 secs (281427232 bytes/sec) 
 [root@RAIDZ] /# 
 [root@RAIDZ] /mnt/RAIDZ# dd if=/dev/zero of=/mnt/RAIDZ/test.dd bs=2048k count=10000 
 10000+0 records in 
 10000+0 records out 
 20971520000 bytes transferred in 76.008326 secs (275910826 bytes/sec) 
 [root@RAIDZ] /mnt/RAIDZ# 
 

In short,

268.3899230957 megabytes

263.1290683746 megabytes


Through the network, I was getting 60-80 MB/s. This may be due to the Realtek 8111E gigabit controller on-board or the fact I was testing during the middle of the day with 60 other people on the network. I was hoping to get closer to Gigabit's theoretical limit of 125 MB/s so I may experiment with a dual NIC Intel card in the future..