Fusion 11.5.5 Available Now
tldr; Fusion Supports Containers! Download the bits below!
Today is a big day for us on the Desktop Hypervisor team. Our beloved products Fusion and Workstation are getting some pretty significant updates for no extra cost to existing users.
We have a lot to share about our commitments to Developers, to Community, and to Windows , so let’s dive right in!
Our Commitment to Developers
VMware has long served developers, as well as end users and IT professionals, with some of the best in class features with our award winning desktop hypervisor products, VMware Fusion and Workstation.
However, when it comes to developing and testing today’s modern applications, things look a little different than the traditional ones which Fusion was originally designed to support.
Today, we’re proud to express our commitment to today’s modern developers by delivering new support for OCI containers using our award-winning hypervisor technology stack. Fusion 11.5 users can now pull, build, run and push containers as part of a modern development and testing workflow, without needing other tools such as docker desktop installed.
Enter vctl
To support these new workflows, we created a new CLI tool: vctl, and we’re shipping it today as a part of our Fusion 11.5.5 update.
vctl: “vee-kettle” or “vee-control”? The debate continues…
vctl is designed to locally manage containers and our containerd based runtime. We use vctl to pull and run images from remote container repositories like Harbor or Docker Hub, or to build custom container images using standard Dockerfiles.
Some folks may recall that we first introduced vctl as part of Project Nautilus during our Tech Preview a few months back. Since then, we’ve listened to the community, made some changes, added some new capabilities, and are ready to bring it to the world as part of a free update to your existing copy of Fusion 11.5 or Fusion 11.5 Pro. (yes, both!)
For starters, there’s a new syntax. If you’re familiar with docker, you’ll feel right at home. So things like ‘vctl run nginx’ works the same as ‘docker run nginx’.
We think users will also be happy to hear that we’ve also added build support, so you can build images from standard Dockerfiles.
Let’s take a quick look at how we can get started with vctl!
A familiar workflow
With the vctl cli experience we wanted to focus on some of the most common tasks users perform with containers, and bring that to our unique container engine to bring folks something radically new.
> vctl pull nginx INFO Pulling from index.docker.io/library/nginx:latest ─── ────── ──────── REF STATUS PROGRESS ─── ────── ──────── index-sha256:30dfa439718a17baafefadf16c5e7c9d0a1cde97b4fd84f63b69e13513be7097 Done 100% (1412/1412) manifest-sha256:8269a7352a7dad1f8b3dc83284f195bac72027dd50279422d363d49311ab7d9b Done 100% (948/948) layer-sha256:11fa52a0fdc084d7fc3bbcb774389fd37b148ee98e7829cea4af189735acf848 Done 100% (203/203) layer-sha256:afb6ec6fdc1c3ba04f7a56db32c5ff5ff38962dc4cd0ffdef5beaa0ce2eb77e2 Done 100% (27098756/27098756) config-sha256:9beeba249f3ee158d3e495a6ac25c5667ae2de8a43ac2a8bfd2bf687a58c06c9 Done 100% (6670/6670) layer-sha256:b90c53a0b69244e37b3f8672579fc3dec13293eeb574fa0fdddf02da1e192fd6 Done 100% (23922586/23922586) INFO Unpacking nginx:latest... INFO done
Pulling images is familiar, and defaults to docker hub for simplicity, but you can specify a full path to another repo or registry.
To run an image, it should once again feel familiar:
> vctl run --name=myNginx -t -d nginx INFO container myNginx started and detached from current session
Same goes for showing the container inventory:
> vctl ps -a ──── ───── ─────── ── ───── ────── ───────────── NAME IMAGE COMMAND IP PORTS STATUS CREATION TIME ──── ───── ─────── ── ───── ────── ───────────── myNginx nginx:latest nginx -g daemon off; 172.16.6.151 n/a running 2020-05-28T12:21:46-07:00 > vctl images ──── ───────────── ──── NAME CREATION TIME SIZE ──── ───────────── ──── nginx:latest 2020-05-28T12:21:13-07:00 48.7 MiB photon:latest 2020-05-27T19:40:03-07:00 14.5 MiB
It’s fairly light on resources, and you also have the control to assign more or less resources to the appliance when firing up the container using -c and -m (CPU and Memory) flags. Run vctl run with no arguments to see some examples.
Fusion is fairly light on resources consumption for the container appliance
When a container is fired up, we also mount the rootfs up to Host, meaning you can use Finder to browse the container contents! You could open up the running code of your app, make changes in real-time, in a way that feels just like editing any other file on your Mac.
When you start vctl, you’ll see the ‘Fusion Container Storage’ mount… each container also gets mounted as they’re started, and unmounted when they stop
Folders and Files from the Linux filesystem in the vanilla nginx container image. You could edit this file directly in Visual Studio Code on the Mac for example.
Let’s check out some of the details:
> vctl describe myNginx Name: myNginx Status: running Command: nginx -g daemon off; Container rootfs in host: /Users/mike/.vctl/storage/containerd/state/io.containerd.runtime.v2.task/vctl/myNginx/rootfs IP address: 172.16.6.151 Creation time: 2020-05-28T12:21:46-07:00 Image name: nginx:latest Image size: 48.7 MiB Host virtual machine: /Users/mike/.vctl/.r/vms/myNginx/myNginx.vmx Container rootfs in VM: /.containers/myNginx Access in host VM: vctl execvm --sh -c myNginx Exec in host VM: vctl execvm -c myNginx /bin/ls
Using the describe command on a running container, we can see more detail, as well as the execvm commands that we can copy and paste to ‘shell’ into our appliance OS or run some process (/bin/ls in the example above…). (This of course is in addition to being able to vctl exec into the container process itself…)
Getting Started
Getting started is as easy as updating to Fusion 11.5.5, opening up your favorite Terminal app, and running vctl system start.
Once the daemon is running, you can try pulling or building and running container images!
We have a good deal of documentation and examples located on our GitHub page, as well as our normal documentation centers.
If you hit a bug with your container or dockerfile, let us know so we can support it by filing an issue!
Which leads us to our next commitment: Community.
Our Commitment to Community
Releasing great software is fun, but what’s also exciting is the community around it.
VMware has a long standing and well-established community, but it tends to be centered around the “VI Admin” through VMware Technology Network, our community forum, and we welcome users to share their experiences with us there.
However, when it comes to the more development related discussions, the VMTN community forum might not always have the right experts readily available.
So we’ve expanded in a few new ways:
- New Slack channel
- GitHub repo for Docs, Examples and Issues
- Livestreams coming!
In collaboration with the VMware {code} team, we’ve created a new Slack channel: #fusion-workstation, within the VMware {code} Slack community!
Joining VMware {code} is free, and once you’ve joined you’ll get an email with a link to the main Slack channel.
The VMware Code community is full of folks that go beyond the typical duties of the VI Admin, and our Fusion and Workstation product and engineering teams will be directly participating to help answer tough questions. Editor: We’ll probably share some memes too.
We will also be doing live and recorded events with both the VMware {code} team, community, and on our own in an effort to help folks get the most out of Fusion and Workstation. Follow our Fusion and Workstation Twitter accounts to get the latest details!
As mentioned earlier in this post, we also have our Github repository where we have example docs, how-to content as well as detailed descriptions of the vctl subcommands. We encourage users to let us know if they hit any snags with vctl by filing an issue so we can work to make sure every OCI container runs without a hitch!
And finally,
Our Commitment to Windows Users
The days of “you must disable Hyper-V to use Workstation” are over!
After years of collaborative development and engineering between VMware and Microsoft, we’re proud to be delivering a compatibility story where Workstation 15.5.5 and newer can run on Windows 10 Hosts with Hyper-V mode enabled.
Hyper-V mode is required for security features like Device Guard and Credential Guard, as well as developer features like WSL, and previously rendered Workstation completely inoperable.
For more detail, check out our Workstation Blog
Wrapping it all up
So that was a lot… Our commitment to Developers with a new container runtime for Mac and supporting WSL on Windows, to Community with many new ways to engage and a content calendar put together to help folks get the most from Fusion and Workstation, and to Windows with our multi-year collaborative effort to support Windows 10 Hyper-V mode with Workstation.
