docker machine driver xhyve
v0.4.0
| Travis CI | Sorties |
|---|---|
Plugin de pilote Libmachine pour Hyperviseur OS X natif de Xhyve
Master Branch a hérité de Nathanleclaire / Docker-Machine-Xhyve. Merci @nathanleclaire :)
Si vous avez des problèmes ou des requêtes de traction, vous souhaitez être affiché dans ce référentiel.
Docker-Machine-Driver-Xhyve en utilisant le modèle de plugin Libmachine.
Veuillez ne pas publier le problème de ce référentiel à Docker / Machine, Kubernetes / Minikube et Minishift / Minishift
Il interférera avec le développement de Docker-Machine, Minikube ou Minishift.
Si vous aviez un problème de doute non plus, veuillez publier sur ces problèmes de référentiel.
docker-machine
minikube
mini-point
Utilisez 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 Utilisez go avec make :
Si vous souhaitez prendre en charge le format d'image du disque QCOW2, avez besoin d'installer Mirage / OCAML-QCOW. Voir Docker / Hyperkit # Bâtiment.
# 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-xhyveNous utilisons Glide pour la gestion des dépendances.
$ go get github.com/Masterminds/glide Cela installera le binaire Glide dans $GOPATH/bin .
Mise à jour des dépendances
Si votre travail nécessite une modification des dépendances, vous devez mettre à jour la configuration de Glide.
glide.lock et recréer le répertoire du fournisseur en exécutant make vendor . Glide reconnaîtra qu'il n'y a pas de fichier de verrouillage et recalcule les dépendances requises.glide.yaml et glide.lock mis à jour. Remarque: Dans certains cas, le cache Glide situé sous ~ / .glide / cache peut être corrompu. Si vous voyez des erreurs de glissement pendant make vendor , vous pouvez effacer le cache Glide via glide cc .
| Nom de drapeau | Variable d'environnement | Taper | Défaut |
|---|---|---|---|
--xhyve-boot2docker-url | XHYVE_BOOT2DOCKER_URL | chaîne | $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 | chaîne | Voir automated_script.md |
--xhyve-boot-kernel | XHYVE_BOOT_KERNEL | chaîne | '' |
--xhyve-boot-initrd | XHYVE_BOOT_INITRD | chaîne | '' |
--xhyve-qcow2 | XHYVE_QCOW2 | bool | false |
--xhyve-virtio-9p | XHYVE_VIRTIO_9P | bool | false |
--xhyve-experimental-nfs-share | XHYVE_EXPERIMENTAL_NFS_SHARE | chaîne | Chemin vers un dossier d'hôte à partager à l'intérieur de l'invité |
--xhyve-experimental-nfs-share-root | XHYVE_EXPERIMENTAL_NFS_SHARE_ROOT | chaîne | chemin racinaire auquel les actions NFS seront montées |
--xhyve-boot2docker-url L'URL (chemin) de l'image boot2docker.
Par défaut, utilisez le chemin du fichier ISO mis en cache.
--xhyve-cpu-count Nombre de processeurs pour utiliser la création de la machine virtuelle.
Si définissez -1 , utilisez des processeurs logiques utilisables par le processus actuel.
--xhyve-memory-sizeTaille de la mémoire pour l'invité.
--xhyve-disk-sizeTaille du disque pour l'invité (MB).
--xhyve-uuid L'UUID pour la machine.
Par défaut, générez et utilisez un UUID aléatoire. Voir xhyve / uuid.go
--xhyve-boot-cmd Démarrage des commandes XHYVE KEXEC.
Par défaut, utilisez
loglevel=3 user=docker console=ttyS0 console=tty0 noembed nomodeset norestore waitusb=10 base host=boot2docker
--xhyve-boot-kernel Démarrage du chemin du fichier du noyau.
Par défaut, analysera automatiquement le chemin du fichier en utilisant (vmlinu[xz]|bzImage)[d]* .
--xhyve-boot-initrd Démarrage du chemin du fichier initrd.
Par défaut, analysera automatiquement le chemin initrd contient le chemin de fichier.
--xhyve-qcow2 Utilisez le format de disque qcow2 .
Si vous utilisez MINIKUBE, CONFIG_VIRTIO_BLK=y La prise en charge est incluse dans Minikube-Iso à partir de la version V0.0.6.
--xhyve-rawdiskUtilisez un simple format «Disque brut» et un pilote Virtio-Blk pour le stockage. Cela peut être considérablement plus rapide pour les applications intensives d'E / S, au coût potentiel de la durabilité des données.
--xhyve-virtio-9p Activez le partage du dossier virtio-9p .
Si vous utilisez Docker-Machine, CONFIG_NET_9P=y La prise en charge est incluse dans boot2docker à partir de la version v1.10.2.
--xhyve-experimental-nfs-share /path/to/host/folder Partagez path/to/host/folder à l'intérieur de l'invité sur le chemin spécifié par --xhyve-experimental-nfs-share-root (qui lui-même est par défaut /xhyve-nfsshares ).
Peut être spécifié plusieurs fois
--xhyve-experimental-nfs-share-root /path Par défaut, les actions NFS seront montées dans l'invité à /xhyve-nfsshares .
Vous pouvez modifier cette valeur par défaut en spécifiant --xhyve-experimental-nfs-share-root /path , /path étant un chemin vers la racine
Actuellement, docker-machine-driver-xhyve ne nettoie pas le dhcpd_leases .
comme,
# 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-test Il sera affecté à 192.168.64. 2 Si vous créez une autre machine virtuelle, affectée à 192.168.64. 3 et 3
Mais 192.168.64. 1 n'utilise personne.
vmnet.framework semble avoir décidé de l'IP en fonction des fichiers ci-dessous
/var/db/dhcpd_leases/Library/Preferences/SystemConfiguration/com.apple.vmnet.plist Donc, si vous souhaitez réinitialiser la base de données IP, veuillez la supprimer manuellement. mais très risqué .
Notez que la plage d'adresses net partagée vmnet.framework est 192.168.64.1 ~ 192.168.64.255 . Vous pouvez faire 255 VM.
Je vais implémenter le processus de nettoyage après avoir compris le vmnet.framework .
Mac OS X 10.11.4 Build 15E27e a un bogue Hyperviseur.Framework .
C'est le bogue d'Apple.
Mais, Apple a été fixé à la construction 15E33e .
Si vous lancez le docker-machine-driver-xhyve sur Build 15E27E, affichera
open : no such file or directory et, dans xhyve d'origine,
hv_vm_create failedVoir
Je suis très anxieux si les autres utilisateurs (sauf moi) peuvent lancer le Xhyve.
Donc, si vous pouviez lancer le Xhyve Utiliser Docker-Machine-Driver-Xhyve, pourriez-vous publier un rapport sur ce fil de problème?
# 18
Si MacOS lancé par le Vagrant peut être construit, mais ne pourra pas lancer l'hyperviseur.
La cause probablement parce que Backend VM (VirtualBox, VMware, Parallels ...) pour masquer les informations du CPU.
Dans le cas de 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)
