Introducing Anka

Today, Veertu Labs is thrilled to pull back the curtain on three Anka toolsets, our latest endeavors geared towards making macOS and iOS development infrastructure management simple and streamlined. Anka technology is a suite of three products that are built to bring the experience of working with containers to the complex macOS/iOS development process. We are inviting all macOS/iOS developers and as well as DevOps engineers to give Anka a try by joining our trial program ( We’ll provide launch dates and general availability of these solutions soon as well.  

It’s no secret that container-based app development and deployment has significantly changed the landscape of developer operations. Why a container approach? Because containers are built to be extremely lightweight, easy to interact with and extremely portable. While macOS cannot yet be run inside a container,  (different than running Linux and windows containers on macOS), we have taken the concepts of container-based devops to iOS/macOS development with Anka.  

Anka’s core hypervisor technology enables creation and execution of extremely lightweight and responsive macOS VMs on Apple hardware. The performance of build and test operations is extremely critical in using virtual environments successfully. As such we developed proprietary paravirtual network and block drivers in our hypervisor for macOS VMs. Then, we built a container ecosystem around Anka, so developers and systems engineers can effectively work with it for iOS and macOS development.  

A Container Ecosystem

We built the container ecosystem with three components: Anka Build, Anka DevOps, and Anka Device. Anka Build enables systems engineers and developers to build an on-premise macOS private cloud on Apple hardware. Anka Build consists of Anka’s native virtualization technology, as well as the Anka Registry and Controller services for storing and managing the on-premise macOS private cloud.  Anka Build enables familiar workflows used with many large cloud providers by allowing you to create version-tagged macOS VMs and store them in the Anka Registry. With Anka Controller’s REST API, you can use stored VMs in Anka Registry to spin up fresh, isolated copies for development, build, or test.  

Anka DevOps is a combination of Anka Registry and the Anka client. Anka Registry stores your macOS virtual machines with proper versioning and optional tagging. Anka client is a lightweight program that runs on your developer machines, that can pull relevant build VMs and make them available for local, but managed development.  

Anka Device extends Anka Build and Anka DevOps to allow iOS on-device testing within the macOS private cloud. Plug in any iOS device to Apple hardware running the Anka Build or Anka DevOps toolset to make real iOS devices available for your iOS CI system or to individual developers on-demand; Anka Device allows for the setup and management of the devices centrally in a private device cloud.  

Anka Build, Anka Devops and Anka Device are the building blocks we think will completely transform infrastructure management for macOS or iOS development.

The pace of growth of iOS app development is astounding and at the same time, the complexity and capabilities of these apps, both B2C and B2B are also increasing significantly. The iOS development methodologies have to stay ahead of the curve to make life easy for developers and publishers.

Listening, Growing and Adapting

It’s been nine months since we launched Veertu Native, the first version of our native MacOS virtualization platform based on Apple’s Hypervisor.framework. In these nine months, Veertu Native has seen significant adoption, and we are learning a lot from our users. We are also growing as a company. We expanded our development team with excellent developers, who are equally passionate about development on MacOS.

We have been busy in the past couple of months prioritizing user feedback, developing features and now we are ready to announce them.

This product release addresses some of the key items from the user feedback. It includes support for bridged networking and USB Pass Through and is now available as Veertu Desktop download outside the AppStore on our website. While we are very excited about being able to continue development on Veertu Desktop, we are also sad about taking this application out of the App Store. We explored various methods to make these new features work with sandboxing restrictions of the App Store, but it seems that this is not possible. So, we had to remove Veertu Native and Veertu Business from the AppStore.

Veertu Desktop leverages privilege separation model. It uses privileged resources only on demand basis for when you enable bridged networking support.

Our existing users can choose to continue to use the version they have installed, or they can switch to Veertu Desktop version. We have implemented capability in Veertu Desktop to migrate existing VMs from Veertu Native to Veertu Desktop, during the install process.

Being part of Mac App Store has great benefits, and we hope to be back in there as soon as possible.

We are also excited about one more thing. We are making Veertu Desktop Open source. It will be available on and will continue to be developed and maintained. We have also been working on innovative technology in the area of increasing velocity of application development on MacOS, iOS, and other Apple mobile platforms. Stay tuned for more updates on our Twitter channel and keep sending us your feedback.

Virtualization of macOS Sierra public beta

New versions of operating systems often cause a lot of heartache for Infrastructure technologies that run on top of them. As an example, virtualization products are often tied tightly with the underlying OS and supporting newer versions of that OS is never straight forward. Not at Veertu, though.

We started seeing feedback on our twitter channel from users, who were trying to run Veertu on the macOS Sierra public beta and run into issues. This got escalated to our developers and within a very short amount of time, they had identified the root cause and implemented the fix in the codebase. The new version with the fix was then pushed to Apple Store for review and publish.

As I thought about it more, I was really intrigued that how we were able to so quickly support the new macOS Sierra, while other similar solutions were/are still proposing all sorts of workarounds on this.

In fact, I later discovered that the code change that we had to implement, was not even done specific to supporting Sierra. The code change was to fix something that was implemented incorrectly from the very beginning. So, we basically, had to make zero code changes to support macOS Sierra.

This is because system driver APIs often change as Operating System vendors come out with new releases and this often breaks the kernel extensions based tool ecosystem that’s built on top of that. It’s different with Veertu. Veertu is built on top of the hypervisor.framework in user space, which abstracts the underlying macOS dependencies and presents simplified and standard interface. So, while macOS Sierra is a new OS release, the hypervisor.framework interface is still kept the same(maybe even extended to include/expose additional features) and as a result, Veertu works for macOS Sierra with no changes.
Veertu on macOS Sierra

Veertu on macOS Sierra

Cross browser testing on Mac

In one of my earlier blogs, I discussed how Macs were becoming the workstation of choice for the developers. In this blog, I want to look at how developers, who are working on browser based applications can leverage native virtualization solution like Veertu running on OS X/Mac to execute cross browser testing across different operating system versions. Take the example of unit testing your app on different versions of IE supported on different windows versions. While it’s kind of difficult to get multiple versions of windows to build test environments(unless you have MSDN account ), I came across this very interesting resource by Microsoft – Microsoft has packaged IE versions + Windows version as VMs and made them available for testing purposes. If you are running Veertu on your Mac, you will start by downloading VMs in either Virtual box, Fusion or Parallels format. I downloaded Virtualbox VMs of IE8 on Win7, IE10 on Win7 and the new IE MDEdge on Win 10. After unzipping the files, I imported these VM images into Veertu. I was able to start the VMs in Veertu right away without any manual intervention.IE 8 on Win 7 VM on Veertu cross browser testing on Mac  

Cross Browser testing of Web Apps

I am using YouTube web app to demonstrate the cross browser testing on these VMs running in Veertu. One of the advantages of using the Hypervisor.Framework, is that even with all of these 3 VMs running on top of Veertu(I am using Macbook Pro with 8GB RAM), it doesn’t seem like the Mac is resource constrained. The footprint of Veertu itself is extremely small, just 13MB. Linux Windows OS X VMs on Veertu cross browser testing on Mac   Here YouTube app in IE8 on Win 7 VM is reporting an error that it’s no longer supported on this IE version. VM in Veertu on Mac cross browser testing on Mac The App on IE 10 on Win 7 is reporting that the support for this IE version will be deprecating soon. IE 10 on Win 7 Veertu VM old browser version warning cross browser testing on Mac And, here is the new IE version MSEdge(stable version) on windows 10 VM on Mac in Veertu. MSEdge windows 10 VM in Veertu cross browser testing on Mac This is one use case example of the need to run virtualization solution on Mac. Other include running Linux dev environments, malware testing VMs etc. In the upcoming Veertu updates, there will be support to run OS X VMs. This will open up a broad area of iOS build and test on your Mac, with multiple OS X VM capsules running specific Xcode and iOS Simulator versions. Stay tuned.

Uncovering OS X Hypervisor.Framework – Part 1

We mentioned in our previous blog that we had been working with hypervisors and most recently with Apple Hypervisor.Framework since it’s release last year. We have used Hypervisor.Framework to develop light weight, high performance and highly reliable virtualization for OS X. With the recent attention and focus on this framework, we thought it would be good to share more detailed information on this with our users. First, a little bit of history on virtualization for Mac. While the hardware of a Mac is produced solely by Apple, it does use certain standard components like Intel x86-64 processors. x86 processor architecture uses the concept of privilege levels (or privilege rings) for machine instructions. The most privileged operations, which are reserved for the host operating system, have a privilege level of 0. A virtual system running on top of the host can’t access the 0 privilege level directly. So, Virtualization technology(VT) extension to CPU, memory and I/O hardware were developed as a technique to overcome this challenge. There are also software based approaches to address this – binary translation and paravirtualization. But, they have some challenges around ring aliasing, address-space compression, and non-faulting access to privileged processor state. Intel’s VT-x virtualization extensions, VT-i extensions and AMD’s AMD-V technology were released to enable hardware assist virtualization. Now, in order to use the VT extensions, hardware-assisted virtualization engines (hypervisor) were developed as kernel extensions(KEXTs) on the Mac. In this model, the hypervisor has complete control over hardware, memory and operates in VMX root mode. It prepares a special Virtual Machine Control Structure (VMCS), which sets the state of the guest. The VMCS stores copies of guest system registers and also includes control bits that specify conditions under which the host will trap (exit) into the hypervisor. Once the VMCS is ready, the hypervisor executes VMLAUNCH and lets the OS take control. The OS runs in VMX non-root mode (guest mode). When any of the exit conditions (privileged instructions) that were specified in the VMCS are met, the processor VM Exits into the hypervisor mode. After execution of the privileged instruction, the hypervisor executes VM Entry instructions, returning to the VMX non-root mode. Because, these hardware assist hypervisors are implemented as kernel extensions for Mac, there are some known issues identified with this approach. Any bug in KEXTs (kernel extensions) can have severe consequence than bugs in user-level code and could cause a kernel-panic, crashing the operating system. In some implementations, KEXTs close interrupts, so, which can have a negative impact on the responsiveness of the system. Kernel resources are wired(permanently resident in memory) and thus are more costly to use than resources in user space task of equivalent functionality. There are also no safeguards in place inside the kernel. For example, a memory leak inside a kernel will result in loss of this memory until the next reboot of the system. With OS X v10.10, Apple introduced the Hypervisor.Framework, which allows virtualization to be implemented on top of OS X, without needing to deploy third-party kernel extensions (KEXTs). It exposes Intel-VT extensions through APIs, to be run in the user space and eliminates the need to run third party developed virtualization code directly in the OS X kernel. At the command execution level it looks something like this. Hypervisor.Framework guest execution: Userspace:
  1. Getting VMCS ready – Veertu code
  2. Execute hv_vcpu_run() – Veertu code
Kernel space:
  1. Hypervisor framework validates VMCS – Apple code
  2. Hypervisor framework execute VMLAUNCH – Apple code
  3. Hypervisor framework wait for VMEXIT – Apple code
  1. Analyze VMEXIT and get back to step 1 – Veertu code
Now, this approach addresses most of the KEXT based implementations issues. A large portion of OS X virtualization code (dealing with VMEXIT etc.) executes in the user space. If there is a bug, it only impacts this application and the application can be closed without impacting other apps or the OS. Any memory leak type situations are handled by the OS X kernel in a safe manner. The decision to close system interrupts is done natively by Apple as per the OS X scheduling policy. What we have shared with you in this blog are additional details based on our experience working with this Hypervisor.Framework. Veertu implementation has lot more details and is much more extensive with guest add-ons etc. In the upcoming months, we plan to share additional details with you on our implementation. Do share your feedback with us.

The March towards adoption of OS X Hypervisor.Framework for Native Virtualization capabilities

Today, Docker announced beta availability of Docker for Mac, built on top of xhyve, one of the derivatives of OS X Hypervisor.Framework. This demonstrates two things – OS X recently released Hypervisor.Framework is a better architecture for developing virtualization on top of OS X, as opposed to installing layers of virtualization products. As a quick reminder, the docker machine was based on VirtualBox and required users to set VirtualBox on their Macs to be able to use the Docker ToolBox. A quick google search will reveal that this approach had a lot of stability and reliability issues. The second point, this announcement reveals is the growing importance of mac as the development desktop for developers. We, at Veertu, have been at work using the OS X Hypervisor.Framework for more than nine months. From the very beginning, we saw the advantages of using this to provide a native virtualization experience on mac. It’s great to see others follow the same path, and all put together will lead to more rapid awareness and adoption of native virtualization for OS X as well as Apple adding more useful features like bridge networking and USB support to the Hypervisor.Framework.

Developers, their desktop and dev environments in 2016

I recently came across this very interesting survey ( done by stack overflow( a site, I absolutely love for researching) on their developer/programmer community. While the survey has insights on trends on dev languages, technology stack etc., one of the highlighted trend was the increasing adoption of Mac OS X as the desktop OS of choice for developers. The survey indicated that Mac OS was overtaking linux as the number 2 operating system among developers. And, that the windows share of desktop OS was decreasing.
This got me thinking, because all around me, Linux seems to the platform of choice for development amongst developers. So, what’s really happening behind this trend? There are some factors which are driving the developers to adopt Mac OS X as their desktop OS, however it seems like, they are most likely still developing on Linux on their Macs. A long time windows desktop user, I recently made the switch to a Mac and I am extremely happy about it. What got me was the simplicity and the ease of use – it just feels natural and light. Of course, these are all user experience descriptions, but, If I think more on it, it’s really about the way the apps that I use on Mac behave. They feel like they are part of the OS, well integrated into it. They feel Native to the Mac.
And, that’s what got me thinking more about the user feedback we have been getting about Veertu. Up until now, we have been looking through a different set of lenses at Veertu – the kind that compels you to think in terms of features. So, I recently sat down with one of founders and had him draw me the most simple, architecture representation for Veertu virtualization on OS X. 
Veertu operates just like any other Mac OS X app. It’s not a heavy virtualization platform which runs on top of Mac OS X and changes the desktop experience for the developers. Instead, it’s an app, which developers can use to run linux, windows dev environments on their Mac. So, like other Mac apps, it lets the OS X do what it does best – Scheduling of resources and power management, without interfering or over riding it. It’s completely sandboxed. Why? Because, like other native Mac Apps, Veertu executes at a higher user privilege with no access to kernel level functions. This has some very unique advantages – The dev VM environments running on top of Veertu are completely sandboxed, operating in a capsule. They don’t inadvertently expose security holes in your Mac. And, recently, I heard from one of the users, how he is able to take advantage of this to run multiple VMs for malware testing. 
Like other apps running on top of your Mac, Veertu is executing in user space in it’s won capsule,  so if it crashes (Why not…it’s software and every software has bugs!), it doesn’t impact other running apps or processes.
So, It was starting to become clear to me that with these new set of lenses, I was looking at native virtualization for Mac OS X. That, Veertu is an app for developers who use Mac OS X as their desktop, using which, they can run dev environments of all flavors. Aas we continue to make Veertu more rich in features for our users, ‘ Native Virtualization’ will always be the overriding theme for us and we will continue to stay true to it. Do share your views and thoughts on this.

Veertu is now available through App Store VPP (Volume Purchase Program)

We have published a full priced(USD $39.99) version of Veertu called – ‘Veertu 2016 Business – Native virtualization‘, in the App Store VPP portal. Several of our users communicated to us that they wanted to purchase Veertu, however, they could only do it through their corporate VPP program on the App Store. Since, Mac App store VPP doesn’t yet support in-App purchase, we have published a full priced version of Veertu on the VPP portal. If you have a VPP account with Apple App store, you should be able to login and purchase Veertu through your existing procurement process. The free version with the In-App purchase called – ‘Veertu – Native virtualization’, will continue to be available through the App Store for everyone.

New version released

Today we have released a new Veertu version 1.0.4. There’s quite a few new features and improvements. We added a HyperV interface support. That will make Windows even faster because it reduces a number of VM exits and timer interrupts. HyperV also synchronizes wall clock automatically, so no more time drifts after suspending and resuming a VM. Linux guests would also benefit from the changes since recent kernels has a built-in support for the HyperV interface. We added a support for Retina HDPI resolutions when a host display is in a scaled mode. This was a popular request of many users. You can enable Retina by going to VM settings/Advanced and checking the box. We also fixed a sandbox file permission bug that caused VMs with an attached ISO residing on a removable media not to start after reconnecting the media. In addition we fixed a few other small bugs and issues. Next version will introduce VM import/export, ability to change VM Library location and more. Stay tuned…  

Welcome to Veertu!