Fusion – Page 10

How to evaluate the vSphere VCSA Beta running on VMware Fusion & Workstation?

10.13.2014 by William Lam // 17 Comments

If you are taking part in the vSphere Beta (available to public to sign up but still under NDA), you may have recently noticed a new milestone release (RC) that has been made available for download. Having been a long time Beta participant when I was customer and still continuing to do so in my current role, the best way to evaluate and test new VMware software is to of course run them on top of vSphere! I know this may not be an option for everyone and the next best thing would be to use VMware Fusion or Workstation.

For those of you who have tried to run the vSphere Beta of VCSA on VMware Fusion or Workstation, you may have found that it does not work as there are some input parameters that are required as part of the new VCSA deployment. These parameters leverages OVF properties which are currently not supported in VMware Fusion and Workstation and therefore the new injectOvfEnv option in ovftool can not be used.

Having said that, VMware Engineering is quite aware that this can be challenging for many customers as well as VMware Employees who make use of Fusion and Workstation on a daily basis. That is why they have built the VCSA to be quite flexible to support both vSphere as well as Fusion and Workstation, however the process may not be completely obvious for the latter. If you inspect the latest VCSA Beta OVA, which you will need to extract from the ISO, you will notice a series of "keys" that begin with guestinfo which is just leveraging custom key/value pairs for the OVF environment.

Ideally, these are passed in from the OVF Properties using either the vSphere Web Client or the new VCSA deployment tool. However, due to the lack of OVF Property support, it can also be passed in through the VMX file of the Virtual Machine.

Here are the steps to deploy the VCSA Beta using either VMware Fusion or Workstation:

Step 1 - Download the VCSA Beta which is available as an ISO

Step 2 - Extract the contents of the ISO and add the .ova extension to following file located in vcsa/vmware-vcsa (this is the VCSA OVA)

Step 3 - Upload the OVA using either VMare Fusion or Workstation (you can either double click or just go to File->Open) but make sure you do not power it on after deployment. (this is very important)

Step 4 - Locate the directory in which the VCSA was deployed to and open up the VMX file and append the following (make sure to change the IP information and passwords based on your environment):

guestinfo.cis.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.mode = "static"
guestinfo.cis.appliance.net.addr = "192.168.1.90"
guestinfo.cis.appliance.net.prefix = "24"
guestinfo.cis.appliance.net.gateway = "192.168.1.1"
guestinfo.cis.appliance.net.dns.servers = "192.168.1.1"
guestinfo.cis.vmdir.password = "VMware1!"
guestinfo.cis.appliance.root.passwd = "VMware1!"
guestinfo.cis.appliance.time.tools-sync = "True"
guestinfo.cis.appliance.ssh.enabled = "True"

Note: The example above is a very basic VCSA deployment which should suffice for the majority of you. If you wish to deploy a more complex scenario, you can inspect the VCSA OVA for additional parameters and see their expected values.

Step 5 - Once you have saved your changes, go ahead and power on the VCSA. At this point, the guestinfo properties that you just added will be read in by VMware Tools as the VCSA is booting up and the configuration will begin. Depending on the speed of your hardware, hopefully in a very short amount of time you will have a fully configured VCSA that is ready for your evaluation and testing.

Here is a screenshot of running the VCSA Beta on both VMware Fusion and Workstation:

If you wanted to take this one step further and automate the entire deployment, you can leverage the ovftool to deploy the OVA as shown with the Fusion example below:

'/Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool/ovftool' --name=vmware-vcsa --acceptAllEulas --allowExtraConfig /PATH/TO/VCSA/OVA '/Users/lamw/Documents/Virtual Machines.localized'

and then append the specific configuration using either an echo or here-statement. You can also do the same on Windows leveraging either plain Windows Bat script or PowerShell.

Hopefully for those of you who only have access to Fusion or Workstation, you can now also take part in the vSphere Beta if you do not have a vSphere lab that can be used. I would also recommend checking out the vSphere Beta Community as there is a new contest that launched today for finding bugs in the latest RC release. Not only can you help improve the product through your feedback, you can also win some some $$$ in doing so!

Community stories of VMware & Apple OS X in Production: Part 3

08.11.2014 by William Lam // 2 Comments

In this third post of the community stories, I had the pleasure to interview with Blake Garner who shares with us how he leverages VMware and Apple Technologies in his production environment.

Company: Adobe
Product: VMware Fusion
Hardware: Apple Mac Mini & Mac Pro

[William] - Hi Blake, thanks for your comment on Twitter today, it sounds like this blog series might be useful for your organization. I understand that you have some experiences working with VMware and Apple OS X that you can share with the community? Before we get started, can you quickly introduce yourself?

[Blake] - Sure, I have been working at Adobe for 11 years in the Seattle location. Started off as a Dev/Test lab administrator focused on Macs, Printers & color management. Been working with VMware seriously starting with VMware Fusion 1.0 and Lab Manager 2.x.

[William] - Wow, a VMware old timer 🙂 So, I take it from your Tweet that you must be doing some really cool stuff with VMware and Apple OS X? Can you describe the environment and how you leverage these technologies together?

[Blake] - We provide "bare metal" Mac Mini's and Mac Pro's to our users. They are mostly developers and testers of Adobe desktop software. The process involves approvals and users requesting a Mac from our web portal.

Once users have the Mac they load VMware Fusion which is the majority of the time. We do not have a centralized command and control of VMware Fusion. A lot of the teams then hook up VMware Fusion to our testing harnesses. Things like Jenkins and a lot of custom code to manage the VM's. We looked into using ESXi/vSphere/vCloud on the Mac but due to the Apple EULA restrictions it just wasn't a good fit.

[William] - Very cool! This sounds like you’re offering Mac as a Service for your internal customers? How do you go about managing the requests of which Mac Mini or Mac Pro are leased out? Is all this custom software Adobe has built?

[Blake] - Yes we do both Mac and x86 systems (Windows & Linux) as part of our bare metal offering on our internal IT Cloud. The bare metal part is custom code. We have rolled our own deployment systems to go along with it as well. Users access one portal that currently spans vCloud, AWS & bare metal along with a few other services.

[William] - You mention that the majority of users install VMware Fusion on the “bare metal” once they get their assigned Mac Mini or Mac Pro. What is VMware Fusion being used for?

[Blake] - Lot's of automation. vmrun gets a good workout here. One team has a "Test as a Service" that can control VMware Fusion and rollback snapshots to provide a clean testing state. The consumers of the Mac's enlist them into their own existing automation systems. Often if you look at the VM's you will see Creative Cloud applications running through test cases super fast. Builds of products for Mac OS and iOS also happen.

[William] - Ah, so they are leveraging VMware Fusion as a platform to be able to run sort of a “Continuous Integration” build environment for your internal Mac OS X and iOS builds? This sounds like it could be quite challenging to manage, have the end users had any issues or have they automated everything all already?

[Blake] - In a larger software company you end up with a number of approaches. I did not get involved at the build level enough to speak on that. Adobe IT tends to focus on the common services that all the teams can use. In general there is a lot of automation herding going on..

[William] - Gotcha. So, going back to physical Mac Mini and Mac Pro, roughly how many are you managing and what type of configurations did you spec out? Any particular reasoning for choosing these configurations?

[Blake] - Our initial launch of the bare metal mac service has 50 Mac Pro's and 50 Mac Minis split equally between two sites. This service is just a couple months old and we expect it to grow fast as the engineers figure out they can get Mac's if their manager approves a monthly fee to their cost center.

We have one config for Mac Pro and Mac Mini. The Mac Mini 6,2 has 250GB SSD and i7 2.6GHz with 16GB RAM. The Mac Pro 6,1 6-Core E5 3.5 GHz with 500GB SSD, 16GB RAM and lower end GPU's as those are not used that much. We really just looked for a sweet spot that matches what Creative Cloud needs

Here is a picture of one of the Mac Pro racks courtesy of Blake:

[William] - How do you monitor for hardware issues and what is the most common issues have you seen for both the Mac Mini and Mac Pro?

[Blake] - That is a real challenge with Apple hardware. With no out of band management we rely on our staff to troubleshoot via KVM or in person if needed. Pre-release software can really crash a system and that often needs a finger on the power button. I'm looking into using our remote controlled PDU to power cycle systems via the portal. If a system is truly FUBAR we just give people a new one.

In a lot of cases we can simply re-image the system via netboot and add it back to the available pool. VMware Fusion comes really in handy for developing our custom netboot environments as well. Netbooting an OS X VM's is one of my favorite features of VMware Fusion.

[William] - I can definitely see it being easier to re-image than to troubleshoot unless you are seeing a consistent issue. Curious, what version of Mac OS X and VMware Fusion are you using today? In addition to snapshot & Netbooting, any other useful features VMware Fusion provides?

[Blake] - VMware Fusion 6.0.3 is what we support today. On the hardware we encourage people to use the latest release version of OS X. In the VM's it depends on what kind of testing. Validation of pre-release OS's is a big chunk of the testing work. For OS X that happens in VMware Fusion and other x86 it's done in vCloud and some VMware Workstation. The automation capabilities of VMware Fusion are a key component. That's what gives us the upper hand in managing these virtual systems.

[William] - Hey Blake, I really appreciate you taking the time and sharing with us on how Adobe leverages VMware and Mac OS X. Before I let you go, do you have any words of advice for other customers looking to provide a similar type of environment? Any gotchas or things you would change if you could start fresh?

[Blake] - Go talk to those people who have offices crammed full of systems and find out what they are doing. You can often find the common requirements and start building against that. Don't try and dictate the whole solution to engineers. Once they are happy customers it's much easier to get them onboard with centralized services. Provide a set of functional services and engineers will pick it up quickly. Keep adding services and they will grow along with you.

Things that I would change all end up on our features roadmap. I have my eyes on providing an API to access to re-image or reserve bare metal systems and providing vagrant along with VMware Fusion for automation.

If you are interested in sharing your story with the community (can be completely anonymous) on how you use VMware and Mac OS X in Production, you can reach out to me here.

How to run Nested Mac OS X guest on ESXi VM on top VMware Fusion?

08.08.2014 by William Lam // 1 Comment

You might be asking, why would anyone want to do this? Well, luckily this is not a "because you can" type of answer but was it was an interesting solution that one of our VMware Engineers (Darius) had shared with me after helping out on this VMTN Community forum thread.

The user was running VMware Fusion on his physical Mac OS X system and wanted to be able to test OS X Mavericks under ESXi. Not having a physical ESXi host to test with, the next best thing was to run a ESXi VM under VMware Fusion and then run the Mavericks guest on top of that.

Here is a quick diagram of the user setup:

The issue with just simply doing this is that for a Mac OS X guest to properly run on ESXi, the underlying hardware must be Apple Hardware. The reason for this is not a technical challenges, but rather a legal one per Apple's EULA. The way in which ESXi detects that the underlying hardware is Apple is by checking whether Apple's SMC (System Management Controller) is available.

In the scenario above, the Nested ESXi VM is not automatically passing through the SMC from the physical Mac OS X system and hence the Mac OS X VM at the very top of the stack will not properly function. The solution that Darius found was to add the following two Advanced VM Settings (VMX) entries to the ESXi VM:

smc.present = "TRUE"
smbios.reflectHost = "TRUE"

This will allow the passing of the underlying SMC up into the Nested ESXi VM which will then allow Mac OS X guest VMs to properly function. We can also confirm this by check the Nested ESXi MOB by pointing a browser to the following URL: https://[ESXI-IP]/mob/?moid=ha-host&doPath=hardware

If you did not add the two entries above, then the smcPresent property would show up as false. In our case, we did add the following two entries and we now run our Mac OS X Guest. Here are a couple of screenshots of performing this on my iMac at home running the same exact configuration:

Thanks Darius for sharing this with me and the community! I am sure this will come in handy for anyone wanting to test Mac OS X guests under ESXi but do not have a physical ESXi host and can easily substitute using VMware Fusion.