Home > Blogs > VMware Fusion Blog


VMware Fusion Tech Preview 20H1: Introducing Project Nautilus

It’s Tech Preview time, and this year we’re doing things a bit differently. Let’s dive in!

New Decade, New Approach to “Beta”

Here on the Fusion team, we want to get features in the hands of customers faster than ever before, and we want to iterate and refine things with the guidance of our users, and to do so transparently, out in the open, as much as possible.

In that vein, for the Fusion Pro Tech Preview 2020 we’re doing things a bit differently than we have in previous years.

This year, in an ongoing way, we’ll be releasing multiple updates to our Tech Preview branches, similar to how we update things in the main generally available branch.  The first release is available now, and we’re calling it ’20H1′.

What this means is that if you have Tech Preview 20H1 (TP20H1 as we lovingly call it…)  installed, it will get updates throughout the year as we improve the quality of our release.

We’re also moving our documentation and other things over to GitHub. We’ll be continuing to add more to the org and repos there, maintain and curate it, as well as host code and code examples that we are able to open source.

Having our docs etc on GitHub let users provide feedback and file issues filed against both docs as well as the products themselves. We will continue to post updates and encourage discussion in the community forum, while GitHub becomes more of a place where we can refer to the ‘latest source of truth’, and where folks can file (and even track) more ‘official’ bugs.

We encourage folks to file issues on GitHub, as well as fork and make changes to the repos there if you believe there’s a better way or if we’re missing something.

Same as always, the Tech Preview builds are free for use and do not require a purchased license, but they come with no guarantees of support and things might behave unexpectedly. But hey, that’s where the fun is, right?

Okay, let’s talk about features…

Firstly, we did some cool USB work!  We’ve opted into using Apple’s native USB stack, enabling us to remove one of our root-level kernel extensions. Try out your devices and let us know if they have any trouble by filing an issue in this GitHub repo: Fusion GitHub usb-support

In Fusion Tech Preview 20H1, however, our main focus is the initial release of an internal project we’ve been calling ‘Project Nautilus‘. We’ve been working on this for almost 2 years, so I’m extremely pleased to say that it’s finally available to the public to use, for free, as part of TP20H1.

 

What is Project Nautilus?

Project Nautilus enables Fusion to run OCI compliant containers on the Mac in a different way than folks might be used to. Our initial release can run containers, but as we grow we’re working towards being able to declare full kubernetes clusters on the desktop.

By leveraging innovations we’re making in Project Pacific, and a bevy of incredible open source projects such as runC, containerD, Cri-O, Kubernetes and more, we’re aiming to make containers first-class citizens, in both Fusion and Workstation, right beside virtual machines.

Currently a command-line oriented user-experience, we’ve introduced a new tool for controlling containers and the necessary system services in VMware Fusion and Workstation: vctl.

Containers on the desktop today

Today when you have say, Docker for Mac installed, its services start, it creates a special Linux virtual machine (in one of many ways, including using Fusion), and essentially maps all of the ‘docker’ commands back the kernel running in the linux vm. (remember that docker is just a front-end to containerd, formerly dockerd, which front ends runC, which interfaces into the linux kernel ‘cgroups’ feature for isolating processes [i.e. the ‘container‘ part of the container].)

So that bulky VM sits there running, waiting for your docker commands, and runs all your containers within it.

Each running container becomes a part of the docker private network, and you forward some ports to localhost and expose your service.

In Fusion with Project Nautilus, we’ve taken a different approach.

Nautilus is different

The vision for Nautilus: A single development platform on the desktop that can bring together VMs, Containers and Kubernetes clusters, for building and testing modern applications.

With Nautilus, leveraging what we built for vSphere and Project Pacific, we’ve created a very special, ultra-lightweight virtual machine-like process for isolating the container host kernel from the Host system. We call that process a PodVM or a ‘Native Pod’.

Each Container get’s its own Pod, and each Pod gets its own IP address from a custom VMnet, which can be easily seen when inspecting the container’s details after it launches.

Meaning, we can easily consume running services without have to deal with port forwarding back to localhost.

It also means that while today we deploy the container image in a pod on a custom vmnet, we can conceivably change that to a bridged network… Meaning you could start a container, the pod would would get an IP from the LAN, and you can then immediately share that IP to anyone else on the LAN to consume that service, without port forwarding.

Of course with custom vmnets we can configure port forwarding, and we’ll also be exposing more functionality there as we grow the Nautilus toolkit.

One of our goals is to bring to bear a new model for design much more complex deployments. We see a future where we can define, within a single file, a multi container + VM + kubernetes cluster deployment, allowing users to accelerate their application modernization.

Nautilus Today

Today Nautilus is controlled by ‘vctl’, and that binary is added to your $PATH when Fusion TP 20H1 is installed.

Let’s look at the vctl default output:

mike@OctoBook >_ vctl

vctl - A CLI tool for Project Nautilus Container Engine powered by VMware Fusion

Feature Highlights:
 • Native container runtime on macOS.
 • Pull and push container images between remote registries & local macOS storage.
 • Run containers within purpose-built linux-based virtual machines (CRX VM).
 • 1-step shell access into virtual machine debug environment. See 'vctl sh'.
 • Guide for quick access to & execution in container-hosting virtual machine available in 'vctl describe'.

USAGE:
 vctl COMMAND [options]

COMMANDS:
 delete Delete images or containers.
 describe Show details of containers.
 exec Execute a command within containers or virtual machines.
 get List images or containers.
 help Help about any command
 pull Pull images from remote location.
 push Push images to remote location.
 run Run containers from images.
 sh Shell into container-hosting virtual machines.
 start Start containers.
 stop Stop containers.
 system Manage Nautilus Container Engine.
 tag Create tag images that refer to the source ones.
 version Prints the version of vctl

Run 'vctl COMMAND --help' for more information on a command.

OPTIONS:
 -h, --help help for vctl

You can see we are off to a good start, there’s a lot we can do already. We also have many aliases in place. Most commonly you’ll have ‘ls’ for ‘get’, ‘i’ fo

As a quick example, to run our first container first we need to start the services.

mike@OctoBook >_ vctl system start
Preparing storage...
Container storage has been prepared successfully under /Users/mike/.nautilus/storage
Preparing container network, you may be prompted to input password for administrative operations...
Password:
Container network has been prepared successfully using vmnet: vmnet12
Launching container runtime...
Container runtime has been started.

Once the system is prepared and started, we can pull an image:

Note that we’re providing a full URL to the image hosted on docker hub, but we could easily point that to a private Harbor instance or some other OCI-compliant registry. In these examples I’m referring to the full path as the image name, but you could ‘tag’ it and just refer to the tag for simplicity’s sake.

mike@OctoBook >_ vctl pull image docker.io/mikeroysoft/mrs-hugo:dev
─── ────── ────────
REF STATUS PROGRESS
─── ────── ────────
manifest-sha256:83cd5b529a63b746018d33384b1289f724b10bb624279f444c23a00fd36e3565 Done 100% (951/951)
layer-sha256:c94289816e8009241879a23ec168af2d9189260423f846695538c320c8b99ea7 Done 100% (17575762/17575762)
layer-sha256:9d48c3bd43c520dc2784e868a780e976b207cbf493eaff8c6596eb871cbd9609 Done 100% (2789669/2789669)
layer-sha256:b6dac14ba0a98b1118a92bc36f67413ba09adb2f1bb79a9030ed25329f428c1f Done 100% (5876538/5876538)
config-sha256:cb657649e42335e58df4c02d7753f5c53b6e92837b0486e9ec14f6e8feb69b61 Done 100% (7396/7396)
INFO Unpacking docker.io/mikeroysoft/mrs-hugo:dev...
INFO done

Now that we have the container in our local inventory:

mike@OctoBook >_ vctl ls i
──── ───────────── ────
NAME CREATION TIME SIZE
──── ───────────── ────
docker.io/mikeroysoft/mrs-hugo:dev 2020-01-19T17:46:09-08:00 25.0 MiB

Cool, there’s my image (you can see it live at https://mikeroysoft.com!).

Let’s start it up!

mike@OctoBook >_ vctl run container my-www --image=docker.io/mikeroysoft/mrs-hugo:dev -d
INFO container my-www started and detached from current session
 
mike@OctoBook >_ vctl ls c
──── ───── ─────── ── ───── ────── ─────────────
NAME IMAGE COMMAND IP PORTS STATUS CREATION TIME
──── ───── ─────── ── ───── ────── ─────────────
my-www docker.io/mikeroysoft/mrs-hugo:dev nginx -g daemon off; 172.16.223.128 running 2020-01-19T17:58:33-08:00

You can see that the container ‘my-www’ is running, based on the mrs-hugo:dev image in it’s fully-pathed form.

You can see the command being run, and most interestingly you have an IP address.

Opening that up yields whatever was running in the container. In my case it’s nginx serving up some static content on port 80. No port mapping necessary.

I won’t go into much further detail in this post, but in the coming days and weeks we will be doing a series of posts and additions to the GitHub repository to explore using all of the capabilities we’ve been able to deliver as part of Nautilus.

Nautilus Tomorrow: Let’s get there together

This is only the first iteration, and we’re making great effort to ensure that we can iterate quickly. This means not only listening better and hearing more from our users, but also tracking issues more transparently, and hold ourselves accountable for delivering fixes and improvements in a timely manner.

We see a not-so-distant future where we can define complex multi-vm+container+kubernetes cluster setups locally on the desktop using a standard markup, and to be able to share that quickly and easily with others even if they’re using Windows.

So there you have it… time to go get started!

Direct Download

VMware Fusion on GitHub

This entry was posted in cloud native, containers, fusion, kubernetes, Nautilus on by .

About Michael Roy

Michael Roy is the Product Line Manager for Desktop Hypervisor products such as VMware Fusion and Workstation.

14 thoughts on “VMware Fusion Tech Preview 20H1: Introducing Project Nautilus

  1. Eric Sloof

    It would be great if NTS-T runs on this release, older versions of Pro even with a bigger MTU of 1600 broke the Geneve overlay network.

  2. Nicolas Solop

    Awesome news. Can’t wait to try it out.

  3. Jerry

    What is the name of the shell/application that displays CPU, network, etc? It’s part of the Nautilus GitHub page?

    1. Michael Roy Post author

      Hi there,

      I’m not sure what you’re specifically looking for, but hopefully this helps a little.
      Now it sounds like you’re asking ‘is there a vctl command that can tell me what my resource consumption looks like’, and the short answer is not yet.

      It would be great to do say, ‘vctl system resources’ and have it print out all the running containers, sandbox vms, how much they’re configured to use and how much they’re actually consuming. Something we can definitely work on there.

      For now, there are commands to see the status of a few things, as well as print the command for ‘sh’ing into the right vm/container host for a given container..

      vctl describe c myWWW
      Name: myWWW
      Status: running
      Command: nginx -g daemon off;
      Container rootfs in host: /Users/mike/.nautilus/storage/containerd/root/io.containerd.snapshotter.v1.native/snapshots/4
      IP address: 172.16.127.128
      Creation time: 2020-01-27T13:15:30-08:00
      Image name: mrs-hugo
      Image size: 25.0 MiB
      Host virtual machine: /Users/mike/.nautilus/.r/vms/myWWW/myWWW.vmx
      Container rootfs in VM: /.containers/myWWW
      Access in host VM: vctl sh vm -c myWWW
      Exec in host VM: vctl exec vm /Users/mike/.nautilus/.r/vms/myWWW/myWWW.vmx — /bin/ls

      So you can see we could do vctl sh vm -c myWWW

      Once that’s done, you could run ‘top’ to see the consumption of the processes in the docker host.
      or you can run ‘free’ to see the memory consumption.

      sh-4.4# free -h
      total used free shared buffers
      Mem: 993M 143M 849M 90M 0
      -/+ buffers/cache: 143M 849M
      Swap: 0 0 0

      By default, the sandbox VM we create has 1GB of RAM and 2 CPUs. If you do ‘vmrun list’ you can see the .vmx file of the sandbox/pod vm:

      >_ vmrun list
      Total running VMs: 1
      /Users/mike/.nautilus/.r/vms/myWWW/myWWW.vmx

      >_ cat /Users/mike/.nautilus/.r/vms/myWWW/myWWW.vmx
      .encoding = “UTF-8”

      config.version = “8”
      virtualHW.version = “16”
      guestOS = “crxpod1-64”
      displayName = “myWWW”
      memSize = “1024”
      numvcpus = “2”

      Does that help, or at least make sense?

      1. Jerry

        Thanks–on the page vmwarefusion.github.io it displays a shell like application with title mike@OctoBook followed by CPU%, Network%, > etc. with a turquoise shell prompt. You’ll see it again next to “Run, Build or Test any app, anywhere, any time” frame. Can you tell me the name of this application as it looks like a shell alternative to macOS Terminal.

        1. Michael Roy Post author

          Hey, sorry I missed your question… I’m using iTerm2 as my terminal. My shell is ‘zsh’ and I have ‘oh_my_zsh’ addon installed. The theme zsh is using is called ‘agnoster’. 🙂

  4. mcnahum

    I’m trying to connect an Hello Camera to the Win10 VM without success … where is the best place to discuss about it.. in the forum I didn’t found a section for 20H1 version…

    1. Michael Roy Post author

      Hm, weird… Did you see: https://communities.vmware.com/community/vmtn/beta/fusion-pro ?

  5. Kirby Zhou

    Uesless container.
    We need DirectX 12.

    1. Michael Roy Post author

      Thanks for your insightful comment.

  6. Oliver

    Hi,

    Wow, it’s always a good point to test the future!

    How is this tech preview in terms of stability and performance for Mac OS 10.15.3 (19D76) and a Windows 10 Pro guest? I know it’s like a beta version, but I would need to know if you recommend to test it for advanced users and enough stable working scenario.

    Thank you.

    1. Michael Roy Post author

      It’s definitely stable. That said however, this release does have ‘debugging flags’ enabled which incurs a performance hit. It’s not supported in production environments, but frankly there isn’t a ton of difference between GA and this TP when it comes to basic VM usage. This TP is all about our container support. If all you want to do is run VMs like Win10, we would recommend the GA release. If you want to see where we’re going with container support, this TP is the way to do it =)

  7. Jim Chavez

    Michael,
    From one of our customers:

    Apple has provided guidance that they will be disabling Kernel Extensions in one of their upcoming versions of OS X (macOS 10.16) . Can you please provide an overview of if/how Fusion will work with this?

    Context: https://developer.apple.com/support/kernel-extensions

    Can you provide some additional information on this.

    1. Michael Roy Post author

      It’s something that we’re aware of and we’ll address through updates.

Comments are closed.