By Gregory Murray, Product Line Manager for Cloud-Native Apps at VMware

I’m excited to announce that VMware has published the binaries and updated our repos for our Photon OS 1.0 release! In a little more than a year, the team has evolved Photon OS from a technology preview into a mature operating system available as open source software that’s been vetted by VMware engineering, support and guest OS validation teams as well as thousands in the community.

With the 1.0 release, we’ve greatly expanded the number of packages that we’re including in the repository, opening the door to many more use cases than were possible with the technology preview releases. At the same time, we’ve managed to keep both the disk and memory footprints extremely small. Read more about Photon OS 1.0 support for packages in our previous blog post.

There have been several enhancements to our release processes to improve its security profile, as well. Prior to availability, the 1.0 release was subjected to more than eight different vulnerability scanning tools, static code analysis and third-party penetration testing.

We’ve maintained the focus on being frugal with system overall resources and their effect on performance in vSphere environments. As a result of the optimizations for vSphere, kernel boot times are ~200ms and runtime performance shows consistent improvement. Even with these enhancements, the Photon OS developers have managed to keep disk and memory footprints very small. Today, the 1.0 release sits at a 384MB memory footprint and, with a minimal installation, 396MB on disk.

Today, we’re also happy to introduce the Photon Administration Guide. We have received plenty of feedback from the community over the last year. We have packaged up common questions about Photon OS as well as operations details in a thorough, easy-to-use guide to help users get the most out of Photon OS.

We invite you to download Photon OS and join our community on GitHub—the source for Photon OS support. We’ve got some exciting things planned for future releases of Photon OS and need your feedback to make sure that we’re heading in the right direction for running your workloads on vSphere.


cfsummit2016We are a proud gold sponsor at this year’s Cloud Foundry Summit and we look forward to interacting with the Cloud Foundry community next week.

Please stop by our booth (#201), we’d love to hear how you are using Cloud Foundry to create applications that are transforming your business and for us to give you a first hand look at the enterprise cloud-native stack Pivotal and VMware announced last month.

On Wednesday @ 9:45am, don’t miss our 5 minute lightening talk by our very own Mark Peek, Principal Engineer for CNA and member of The Cloud Foundry Foundation’s Technical Advisory Board.

See you there and stay connected!



Last week I announced the first offering from our joint work with Pivotal.  Today I am excited to announce that we’ve been working closely with Pivotal and EMC to help realize EMC’s vision for Native Hybrid Cloud, a new offering that brings Pivotal Cloud Foundry, VMware Photon Platform and VxRack System 1000 together into an engineered offering that enables any organization to rapidly build, deploy and run cloud-native applications on premises.

With the pressure on business to deliver software and software services, the top-to-bottom hardware and software integration of Native Hybrid Cloud enables business to dramatically accelerate the formation of a cloud-native environment without the time, complexity, or uncertainty associated with building a do-it-yourself solution.

Native Hybrid Cloud

Essentially the EMC team is taking the Pivotal-VMware cloud-native stack we announced last week and building it into their VxRack appliance to deliver a robust converged platform.  This makes it even easier for customers to quickly and easily realize all the benefits of an on-prem cloud-native solution.

The cloud-native team is looking forward to this year’s EMC World! We’ll be front-and-center in the VMware Booth’s CNA zone and the EMC Native Hybrid Cloud area. If you are attending EMC, please come by and see first hand how developers and IT operators can spend more time enhancing applications and less time readying an application for production.

You also don’t want to miss:

See you there!


By Gregory Murray, Product Line Manager for Cloud-Native Apps at VMware

It’s been an eventful week for the Cloud-Native Apps team. On the 26th, Pivotal and VMware announced an enterprise cloud-native stack featuring Pivotal Cloud Foundry and VMware Photon Platform.

Today is a milestone day for the Photon OS team – we’re sharing our 1.0 Release Candidate. Go check it out now!

Photon OS is VMware’s enterprise-grade, small-footprint Linux distribution, optimized for running cloud-native applications on vSphere. Photon OS is also an embedded component within Photon Platform, our purpose-built cloud-native infrastructure, and vSphere Integrated Containers.  Since we announced and open-sourced Photon OS last year, the product has racked up tens of thousands of downloads, and we’re confident that this Release Candidate will be the most popular download to date.

As we march towards a 1.0 release, we’ve been hard at work on testing and maturing Photon OS to the near production-grade state it’s in today. It turns out that after more than a decade of supporting guest operating systems, we’ve got quite a bit of expertise on validating and optimizing an operating system for VMware platforms. We took the opportunity to leverage those resources – and, as a result, went a bit quiet – to really hammer on Photon OS performance, security and package library. We think you’ll find this RC much more representative of what’s needed to run Linux, cloud-native applications on vSphere.

So what’s new with Photon OS today?

Today’s Photon OS release allows users to more easily secure and manage systems while improving overall compute performance. We do this through:

  • Easy system updates and in-place upgrades. Today’s release candidate includes tdnf enhancements, making it straightforward to perform system-wide scans and refreshes of your installed core packages, including Docker.
  • Greatly expanded package library in the repos. As we worked with support, the guest operating system validation team and others, we found critical requirements for many new packages. These packages should make Photon OS much more broadly applicable to customer use-cases and open up many new options on what can be done with Photon OS.
  • More file systems options: With the newer 4.2 kernel, Photon OS now supports btrfs, in addition to overlayfs, giving users the ability to leverage some of the efficiencies and capabilities of btrfs.
  • New performance enhancements: We continue to tune the Photon OS kernel when running on vSphere and now deliver a 10-26 percent improvement in file operation microbenchmarks. We’ll be working with our performance team to translate this to some real-world applications and post more details on the VROOM! blog.

Photon OS is a crucial underpinning to our vSphere Integrated Containers and Photon Platform products, and today’s release brings all of VMware’s cloud-native infrastructure solutions one step closer being fully-supported and production-ready. We’re excited to hear about your experiences with Photon OS, and welcome your feedback on our release over on GitHub and @cloudnativeapps.



At VMworld 2015, VMware and Pivotal announced they would work together on a combined solution for cloud-native applications.  Today I am thrilled that Pivotal and VMware have announced the first offering resulting from this work, an enterprise cloud-native stack featuring Pivotal Cloud Foundry and VMware Photon Platform.

Why is this a big deal?  It goes back to the basics of the digital transformation businesses are driving.  They realize that software and software services are becoming bigger and bigger differentiators for their businesses and so must accelerate how they deliver innovation to their customers.  Businesses are leveraging new application architectures, delivery models, and operational models.  To accomplish this, they must embrace next generation application and infrastructure platforms.  Businesses are most successful when they have a tightly integrated, simple to use application and infrastructure platform.  This is why this announcement is a big deal: the combination of Pivotal’s cloud-native application platform, Pivotal Cloud Foundry, with VMware’s cloud-native infrastructure, VMware Photon Platform, will allow your organization to spend more time and resources on innovating and driving customer value and less time getting an application ready to run in production.

Before talking about the integrated solution, let’s look at each component.  We’ll start with the cloud-native application platform, Pivotal Cloud Foundry (PCF).  As anyone who has experience with cloud-native app development will know, cloud-native apps are about much more than just containers.  There are many problems to solve when operating cloud-native apps in production, such as enabling registration and discovery of application services, network request routing / load balancing, health and availability, monitoring and logging, identity and authentication, and much more.  PCF provides a single, powerful environment providing all these capabilities and more.  This allows application teams to rapidly build, deploy, and operate cloud-native applications within PCF.

On to the infrastructure.  All application platforms require an infrastructure to run on.  The infrastructure must provide compute, storage, and network capabilities at a minimum.  But enterprises require much more: security, multi-tenancy, resource management, scheduling, and more.  In addition, for cloud-native environments, businesses are looking for a high-scale, API-driven, OSS solution.  This is exactly what we’re delivering with Photon Platform.  It’s a robust infrastructure solution optimized for cloud-native applications.

Now let’s return to the integrated solution.  Successfully building, deploying, and operating a cloud-native application in production requires many enterprise-grade capabilities.  Many of the customers I’ve spoken with over the last eight months face installation and maintenance complexity.  There’s simply too many pieces and various third parties with whom the customer must contract as they assemble their cloud-native stack. In addition, many of these pieces are at different levels of maturity, reliability, and interoperability.  By offering a single solution that is built to work together, tested and backed with unified support, we will accelerate initial deployment and post-installation efforts.  You can expect speedy application deployments and streamlined operations with built-in application and infrastructure management.  This joint solution is built for speed, scale and programmability, that is usable by developers, operations teams, and everyone in-between.

Pivotal Cloud Foundry on VMware Photon Platform Demo

The Pivotal-VMware cloud-native stack offers unparalleled simplicity and power that enables your organization to deliver cloud-native apps quicker, easier, and with greater efficiency.  What are you most excited about?


Authored by Mark Peek, Principal Engineer for Cloud-Native Apps

At VMworld 2015 we showcased vSphere Integrated Containers (based on the Project Bonneville code), providing a docker daemon endpoint into a vSphere cluster. Since then, the team has been actively working on redesigning the architecture and implementation to best deliver this product to our customers. We also thought about better ways to engage and add value to our customers with this work. I am happy to announce we have now open sourced the initial 0.1 release of vSphere Integrated Container (VIC) available on the GitHub repository. This early access version supports basic operations such as a VCH deploy, docker pull, create and start. These operations are implemented via the VIC Container Abstraction which treats containers as VMs rather than in VMs. More information about the VIC Container Abstraction can be found here.

Open Source

Why are we open sourcing this code? At Cloud-Native, we believe in collaborating with the community and sharing ideas with developers as we work together to build useful tools and products. Following on the open source nature of the container community, we wanted to make the VIC code open source as well. This will give our customer and partner communities access to the code, visibility into our work, more direct access to file issues, contribute code back, and help us make our code better for their use. We are also structuring the product in such a way to expose a “port layer” which customers or other teams may use to support other container endpoints or to implement new functionality.

Port layer

At this time we are focused on delivering a docker endpoint for our customers to use with future integrations coming along the way. As such we have developed an abstraction called the Port Layer. This allows us to write a docker front end that then uses the port layer as a more generalized, low-level, container backend. This will allow 3rd party integration with consistent API’s for compute, network, and storage. You can learn more about the port layer here.

Check it out on GitHub and let us know what you think!


By James Zabala, Senior Product Manager for Cloud-Native Apps at VMware

We recently released v0.8 of Photon Controller — a distributed, high-scale platform purposefully-built for cloud-native applications. I encourage you to read more about the v0.8 release and the tremendous engineering effort behind it.

Today we’re continuing our fervent push towards making Photon Platform the best Cloud-Native infrastructure available by announcing our BOSH CPI implementation.

BOSH is a popular open source toolchain designed to help you build and run distributed services. Many identify BOSH as a method of deploying Cloud Foundry (which it was originally designed to do), but it’s actually a far more robust system. BOSH addresses many of the common challenges in running distributed systems: release engineering, deployment and even life-cycle management of small or large-scale distributed services.

With BOSH, a developer can create software releases — a tight coupling of source code, binary assets, configurations, etc. — and then easily capture dependencies as an image that BOSH will manage and distribute as necessary. The system manages operating system images, persistent data, and system configurations, providing developers a single pane of glass to operate complex distributed systems. With the ever-expanding management challenges across objects and systems supporting today’s cloud-native applications, the BOSH toolchain is a natural fit for current software engineering best practices.

A BOSH CPI, or Cloud Provider Interface, is an API that is used to interact with an underlying IaaS to create and manage objects on an infrastructure, including images, VMs and disks. Put simply, the Photon Platform BOSH CPI release enables developers to use our elastic, large-scale and highly-available infrastructure without changing their workflow.

We’ve worked closely with the Cloud Foundry Foundation (CFF) to build and incubate our BOSH CPI with the goal of making Photon Platform a first-class citizen for the many devops organizations relying on BOSH to run their applications. The process of incubating the CPI aligns with the strong community-based nature of BOSH and the Cloud Foundry Foundation, of which VMware has been a member since day one.

Getting started with the CPI is easy: visit the project’s GitHub page and follow a few simple steps to get started using BOSH on Photon Platform. No open-source project is ever complete without feedback, and we look forward to hearing from you soon!


VMware’s cloud-native apps team, along with the VMware Management Suites team, will attend the Google Cloud Platform user conference this week (March 23-24) at Pier 48 in San Francisco. Be sure to stop by the VMware booth in the Partner Zone where we will be demo-ing Photon Platform with Kubernetes, among other solutions and technologies.

Get all the details about VMware’s presence at the event here. We hope to see you at the show!




By James Zabala, Senior Product Manager for Cloud-Native Apps at VMware

tl;dr We’re releasing Photon Controller v0.8 today — a major release with significant improvements. Want to get started right away? Check out the wiki on GitHub.

Photon Controller is an infrastructure stack purposefully-built for cloud-native applications. It is a distributed, high-scale control plane for multi-tenant deployments designed from the ground-up to address the need for elasticity, high churn and self-healing.

Photon Controller was announced at VMworld in 2015 and, in the spirit of VMware’s cloud-native initiatives, subsequently open sourced on November 16th, 2015.

With significant progress on the project in the three months since we open sourced Photon Controller, we’re thrilled to announce the release of v0.8 — a major milestone in the development of Photon Controller. While November’s release was targeted at demonstrating the features available on the platform on a small scale, we’ve poured our development efforts into building a robust and scalable foundation for your critical cloud-native workloads.

The v0.8 release, found on our GitHub repository, really shines in manageability and maturity:

  • Support for Real-World Deployments – The Photon Controller installer supports real-world deployments on ESXi hosts. You can carve up your fleet of hypervisors, setting aside hosts dedicated to your distributed control-plane with the remainder running your cloud-native workloads.
  • User Interface – We now have both an Installer and Management UI, making the process of deploying and managing Photon Controller on ESXi hosts in large-scale, production-like environment easy.
  • Upgrade – We’ve built a robust and seamless upgrade process ensuring that you can upgrade to v0.8 (and subsequent releases) with ease. If you’ve ever upgraded a distributed cloud platform you’re likely familiar with the significant pain points. The Photon Controller upgrade process incurs minimal downtime (as short as several minutes) and can be performed in a handful of CLI commands or API calls.
  • Scalability – We’re constantly challenging ourselves to improve scalability. As of today Photon Controller scales to thousands of hosts and hundreds of thousands of objects. We’ve successfully scale tested a 200-node Kubernetes cluster (on-par with Google Container Engine’s limits) and a 700-node Mesos cluster. At the moment our scalability testing is hardware limited.
  • Multi-image Datastore – We no longer require a shared datastore amongst your CLOUD nodes (such as NFS or FC). Instead, Photon Controller will automatically replicate images to the appropriate local datastores for you.
  • Statistics with Graphite / Grafana – Operationalizing clouds can be difficult if you’re flying blind. Photon Controller uses Graphite to gather statistics from your management plane and cloud hosts to give you the visibility you need to feel confident running a large cloud.

Perhaps most exciting, however, is the work going into our future v1.0 release. We’re working hard to address fleet management and authentication. We are improving things “under the hood,” too. We’re vastly simplifying our scheduler with the goal of increasing scalability and performance. Beyond v1.0 we’re looking at deep integrations with both NSX and VSAN to address the need for network microsegmentation and persistent storage in a containerized environment.

The engineering effort in the last three months has been nothing short of monumental: 36 developers committed over 750 patches. We’re serious about open source, too. In addition to developing completely in the open (all commits land in the develop branch) we’re opening up our Pivotal Tracker. The world can now see how we’re prioritizing our engineering efforts.

Our releases use semantic versioning, with v0.8 representing an almost feature-complete release. The v0.8 release also signifies that we’re getting closer to being comfortable calling our release “production ready.” Thus while we encourage users to deploy Photon Controller and discover its robust capabilities, it’s best to hold off on running production workloads until the v1.0 release.

Getting started with Photon Controller is simple: check out our GitHub wiki — there’s a plethora of information on how to deploy and manage the platform with more on the way.

We would love to get your feedback — negative or positive — as we progress towards a v1.0 release. There are numerous ways to reach us, all listed on our GitHub wiki. It’s only by understanding how you — devops engineers, cloud architects, developers building applications on our platform, and hackers who love to tinker with the latest open source bits — are using the project that we can aim improve it.

If you are inclined to help improve Photon Controller, whether by writing documentation or code, feel free to ping us on GitHub — we love collaborating!



As many of you know docker-machine is the client side tool that allows an individual on his/her own workstation to fire up docker hosts either locally or remote.

Docker-machine supports a variety of “drivers” to accomplish this. Some of these drivers deploy locally (e.g. Virtualbox, VMware Fusion), some of them deploy inside the data center (e.g.  OpenStack, VMware vSphere) and others can deploy in public clouds (e.g. AWS, VMware vCloud Air).

As I was experimenting with the vSphere driver for some tests I was doing with Docker Swarm, I found that the number of options available on the vSphere driver and the flexibility it provides, could make its usage challenging without proper examples to kick off the scripting.

For this reason, I am sharing some of the scripts I have used for my experiments with the ultimate goal of providing solid practical examples of how to use those vSphere parameters.

For your convenience, I am also attaching the variable configuration examples in this post.

This is how you’d configure the variables or corresponding options if you were to deploy to a vCenter server:

VSPHERE_VCENTER=                                                                # vCenter IP/FQDN

VSPHERE_USERNAME=’administrator@vsphere.local’                             # vCenter user

VSPHERE_PASSWORD=’***********’                                                             # vCenter user password

VSPHERE_NETWORK=’VM Network’                                                          # PortGroup

VSPHERE_DATASTORE=’datastore1′                                                          # Datastore

VSPHERE_DATACENTER=’Home’                                                               # Datacenter name

VSPHERE_HOSTSYSTEM=’Cluster1/*’                                                        # cluster name

#VSPHERE_POOL=’/Home/host/Cluster1/Resources/SwarmTeam13′        # *optional* Resource Pool name

This is how you’d configure the variables or corresponding options if you were to deploy to a standalone ESXi host:

VSPHERE_VCENTER=                                                          # ESXi IP/FQDN

VSPHERE_USERNAME=’root’                                                                      # ESXi user

VSPHERE_PASSWORD=’***********‘                                                              # ESXi user password

VSPHERE_NETWORK=’VM Network’                                                           # PortGroup

VSPHERE_DATASTORE=’datastore1′                                                           # Datastore

#VSPHERE_POOL=’/*/host/*/Resources/SwarmTeam9′                               # *optional* Resource Pool name

In particular, the syntax to use for the VSPHERE_POOL variable (or corresponding options) requires a bit of attention.

Let’s say, for example, that you want to deploy a 5-node Swarm cluster in a vCenter Resource Pool called “SwarmTeam13”, inside a cluster called “Cluster1”, in a data center called “Home”.

To do so, you will use the first syntax above inside the script and then you will run it on your workstation using the following parameters:

> ./ 5 vmwarevsphere vcenter

Note: the VSPHERE_POOL variable has to be set if you want to deploy inside a Resource Pool (and not in the root of the cluster) so you need to remove the comment preceding the variable.

This is what you will see in the vCenter UI once the script has completed:


You can set the proper environmental variables to access the Swarm cluster by running the following command at the prompt:

> eval $(docker-machine env –swarm swarm-node1-master)

If you want to play with the scripts and deploy / destroy an entire multi-node Swarm cluster on vSphere, just grab them here.