Skip to content


Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Travis CI Releases
Travis CI Releases


libmachine driver plugin for xhyve native OS X Hypervisor

Master branch inherited from nathanleclaire/docker-machine-xhyve. Thanks @nathanleclaire :)
If you have issues or pull-requests, Desired to be posted to this repository.




docker-machine, minikube or minishift

docker-machine-driver-xhyve using libmachine plugin model.

Please do not post the issue of this repository to docker/machine, kubernetes/minikube and minishift/minishift
It will interfere with the development of docker-machine, minikube or minishift.
If you were doubt problem either, please post to this repository issues.


Use Homebrew/brew:

$ brew install docker-machine-driver-xhyve

# docker-machine-driver-xhyve need root owner and uid
$ sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
$ sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve

Use go with make:
If you want to support qcow2 disk image format, need install mirage/ocaml-qcow. See docker/hyperkit#building.

# Need Go 1.5 vendoring support

$ go get -u -d
$ cd $GOPATH/src/

# Install qcow-format for qcow2 disk image format
$ brew install opam libev
$ opam init
$ eval `opam config env`
$ opam install uri qcow-format io-page.1.6.1 conf-libev

# Install docker-machine-driver-xhyve binary into /usr/local/bin
$ make install

# docker-machine-driver-xhyve need root owner and uid
$ sudo chown root:wheel /usr/local/bin/docker-machine-driver-xhyve
$ sudo chmod u+s /usr/local/bin/docker-machine-driver-xhyve

We use Glide for dependency management.

$ go get

This will install the glide binary into $GOPATH/bin.

Updating Dependencies

If your work requires a change to the dependencies, you need to update the Glide configuration.

  • Edit glide.yaml to change the dependencies as needed.
  • Delete glide.lock and re-create the vendor directory by running make vendor. Glide will recognize that there is no lock file and recalculate the required dependencies.
  • Check-in the updated glide.yaml and glide.lock files.
  • Test that everything still compiles with the new lock file in place by running make clean && make.

Note: In some cases the Glide cache located under ~/.glide/cache can get corrupted. If you seeing Glide errors during make vendor, you can clear the Glide cache via glide cc.


Available flags

Flag name Environment variable Type Default
--xhyve-boot2docker-url XHYVE_BOOT2DOCKER_URL string $HOME/.docker/machine/cache/boot2docker.iso
--xhyve-cpu-count XHYVE_CPU_COUNT int 1
--xhyve-memory-size XHYVE_MEMORY_SIZE int 1024
--xhyve-disk-size XHYVE_DISK_SIZE int 20000
--xhyve-uuid XHYVE_UUID int ''
--xhyve-boot-cmd XHYVE_BOOT_CMD string See
--xhyve-boot-kernel XHYVE_BOOT_KERNEL string ''
--xhyve-boot-initrd XHYVE_BOOT_INITRD string ''
--xhyve-qcow2 XHYVE_QCOW2 bool false
--xhyve-virtio-9p XHYVE_VIRTIO_9P bool false
--xhyve-experimental-nfs-share XHYVE_EXPERIMENTAL_NFS_SHARE string Path to a host folder to be shared inside the guest
--xhyve-experimental-nfs-share-root XHYVE_EXPERIMENTAL_NFS_SHARE_ROOT string root path at which the NFS shares will be mounted


The URL(Path) of the boot2docker image.
By default, use cached iso file path.


Number of CPUs to use the create the VM.
If set -1, use logical CPUs usable by the current process.


Size of memory for the guest.


Size of disk for the guest (MB).


The UUID for the machine.
By default, generate and use random UUID. See xhyve/uuid.go


Booting xhyve kexec commands.
By default, use
loglevel=3 user=docker console=ttyS0 console=tty0 noembed nomodeset norestore waitusb=10 base host=boot2docker


Booting kernel file path.
By default, will automatically parses the file path using (vmlinu[xz]|bzImage)[\d]*.


Booting initrd file path.
By default, will automatically parses the initrd contains file path.


Use qcow2 disk format.
If you using minikube, CONFIG_VIRTIO_BLK=y support is included in minikube-iso as of version v0.0.6.


Use a simple 'raw disk' format and virtio-blk driver for storage. This may be significantly faster for I/O intensive applications, at the potential cost of data durability.


Enable virtio-9p folder share.
If you using docker-machine, CONFIG_NET_9P=y support is included in boot2docker as of version v1.10.2.

--xhyve-experimental-nfs-share /path/to/host/folder

Share path/to/host/folder inside the guest at the path specified by --xhyve-experimental-nfs-share-root (which itself defaults to /xhyve-nfsshares).

Can be specified multiple times

--xhyve-experimental-nfs-share-root /path

By default, NFS Shares will be mounted in the Guest at /xhyve-nfsshares.

You can change this default by specifying --xhyve-experimental-nfs-share-root /path, /path being a path to the root

Known issue

Does not clean up the vmnet when remove a VM

Currently, docker-machine-driver-xhyve does not clean up the dhcpd_leases.

# Running xhyve vm. for example, assign
$ docker-machine create --driver xhyve xhyve-test
# Send ACPI signal(poweroff) signal over the ssh
$ docker-machine rm xhyve-test
# Re-create xhyve vm, will assign
docker-machine create --driver xhyve xhyve-test

It will assigned to If create another vm, assigned to
But are not using anyone.

vmnet.framework seems to have decide the IP based on below files

  • /var/db/dhcpd_leases
  • /Library/Preferences/SystemConfiguration/

So, If you want to reset IP database, please remove it manually. but very risky.
Note that vmnet.framework shared net address range is ~ You can make 255 vm.

I will implement the clean-up process after understanding the vmnet.framework.

Can't launch on macOS 10.11.4 build 15E27e

Mac OS X 10.11.4 build 15E27e has a Hypervisor.framework bug.
This is Apple's bug.
But, Apple has been fixed build 15E33e.

If you launch the docker-machine-driver-xhyve on build 15E27e, will displayed

open : no such file or directory

and, In original xhyve,

hv_vm_create failed


Could you report?

I'm very anxious whether other users(except me) are able to launch the xhyve.
So, if you were able to launch the xhyve use docker-machine-driver-xhyve, Could you post a report to this issue thread?

If macOS launched by the Vagrant, can be build, but will not be able to launch the Hypervisor.
The cause probably because backend vm (Virtualbox, VMWare, parallels...) to hide the CPU information.

In the case of VMWare,

$ system_profiler SPHardwareDataType
system_profiler[458:1817] platformPluginDictionary: Can't get X86PlatformPlugin, return value 0
system_profiler[458:1817] platformPluginDictionary: Can't get X86PlatformPlugin, return value 0

    Hardware Overview:

      Model Name: Mac
      Model Identifier: VMware7,1
      // Where is "Processor Name:" field?
      Processor Speed: 2.19 GHz
      Number of Processors: 1
      Total Number of Cores: 1
      L2 Cache: 256 KB
      L3 Cache: 6 MB
      Memory: 2 GB
      Boot ROM Version: VMW71.00V.0.B64.1505060256
      SMC Version (system): 1.16f8
      Serial Number (system): ************
      Hardware UUID: ********-****-****-****-************

$ git clone && cd xhyve
$ make
$ ./
vmx_init: processor not supported by Hypervisor.framework
Unable to create VM (-85377018)