docker machine driver xhyve
v0.4.0
| 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-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.
docker-machine
minikube
minishift
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-xhyveUse 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
$ export GO15VENDOREXPERIMENT=1
$ go get -u -d github.com/zchee/docker-machine-driver-xhyve
$ cd $GOPATH/src/github.com/zchee/docker-machine-driver-xhyve
# 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-xhyveWe use Glide for dependency management.
$ go get github.com/Masterminds/glideThis 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.
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.glide.yaml and glide.lock files.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.
| 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 AUTOMATED_SCRIPT.md |
--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 |
--xhyve-boot2docker-urlThe URL(Path) of the boot2docker image.
By default, use cached iso file path.
--xhyve-cpu-countNumber of CPUs to use the create the VM.
If set -1, use logical CPUs usable by the current process.
--xhyve-memory-sizeSize of memory for the guest.
--xhyve-disk-sizeSize of disk for the guest (MB).
--xhyve-uuidThe UUID for the machine.
By default, generate and use random UUID. See xhyve/uuid.go
--xhyve-boot-cmdBooting xhyve kexec commands.
By default, use
loglevel=3 user=docker console=ttyS0 console=tty0 noembed nomodeset norestore waitusb=10 base host=boot2docker
--xhyve-boot-kernelBooting kernel file path.
By default, will automatically parses the file path using (vmlinu[xz]|bzImage)[d]*.
--xhyve-boot-initrdBooting initrd file path.
By default, will automatically parses the initrd contains file path.
--xhyve-qcow2Use qcow2 disk format.
If you using minikube, CONFIG_VIRTIO_BLK=y support is included in minikube-iso as of version v0.0.6.
--xhyve-rawdiskUse 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.
--xhyve-virtio-9pEnable 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/folderShare 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 /pathBy 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
Currently, docker-machine-driver-xhyve does not clean up the dhcpd_leases.
like,
# Running xhyve vm. for example, assign 192.168.64.1
$ 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 192.168.64.2
docker-machine create --driver xhyve xhyve-testIt will assigned to 192.168.64.2. If create another vm, assigned to 192.168.64.3.
But 192.168.64.1 are not using anyone.
vmnet.framework seems to have decide the IP based on below files
/var/db/dhcpd_leases/Library/Preferences/SystemConfiguration/com.apple.vmnet.plistSo, If you want to reset IP database, please remove it manually. but very risky.
Note that vmnet.framework shared net address range is 192.168.64.1 ~ 192.168.64.255. You can make 255 vm.
I will implement the clean-up process after understanding the vmnet.framework.
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 directoryand, In original xhyve,
hv_vm_create failedSee
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?
#18
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:
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 https://github.com/mist64/xhyve && cd xhyve
$ make
$ ./xhyverun.sh
vmx_init: processor not supported by Hypervisor.framework
Unable to create VM (-85377018)
