| ترافيس سي | الإصدارات |
|---|---|
البرنامج المساعد لبرنامج تشغيل Libmachine لـ Xhyve الأصلي OS X Hypervisor
فرع رئيسي ورثه من Nathanlecleaire/Docker-Machine-Xhyve. شكرا @nathanlecleaire :)
إذا كانت لديك مشاكل أو أسواق سحب ، فهي ترغب في نشرها في هذا المستودع.

Docker-Machine-Driver-Xhyve باستخدام نموذج المكون الإضافي Libmachine.
يرجى عدم نشر مسألة هذا المستودع إلى Docker/Machine و Kubernetes/Minikube و Minishift/Minishift
سوف تتداخل مع تطوير Docker-Machine أو Minikube أو Minishift.
إذا كنت تشك في مشكلة أيضًا ، فيرجى نشر مشكلات المستودع هذه.
Docker-Machine
Minikube
minishift
استخدم البيرة/المشروب:
$ 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 استخدم go with make :
إذا كنت ترغب في دعم تنسيق صورة قرص QCOW2 ، فاحتاج إلى تثبيت Mirage/OCAML-QCOW. انظر Building Docker/HyperKit#.
# 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-xhyveنستخدم الانزلاق لإدارة التبعية.
$ go get github.com/Masterminds/glide سيؤدي ذلك إلى تثبيت Glide Binary إلى $GOPATH/bin .
تحديث التبعيات
إذا كان عملك يتطلب تغييرًا في التبعيات ، فأنت بحاجة إلى تحديث تكوين الانزلاق.
glide.lock وإعادة إنشاء دليل البائع عن طريق تشغيل make vendor . سوف يدرك Glide أنه لا يوجد ملف قفل ويعيد حساب التبعيات المطلوبة.glide.yaml و glide.lock المحدثة. ملاحظة: في بعض الحالات ، يمكن أن تفسد ذاكرة التخزين المؤقت للجلد الموجود تحت ~/.glide/ذاكرة التخزين المؤقت. إذا رأيت أخطاء الانزلاق أثناء make vendor ، فيمكنك مسح ذاكرة التخزين المؤقت للجلد عبر glide cc .
| اسم العلم | متغير البيئة | يكتب | تقصير |
|---|---|---|---|
--xhyve-boot2docker-url | XHYVE_BOOT2DOCKER_URL | خيط | $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 | خيط | انظر Automated_script.md |
--xhyve-boot-kernel | XHYVE_BOOT_KERNEL | خيط | '' |
--xhyve-boot-initrd | XHYVE_BOOT_INITRD | خيط | '' |
--xhyve-qcow2 | XHYVE_QCOW2 | بول | false |
--xhyve-virtio-9p | XHYVE_VIRTIO_9P | بول | false |
--xhyve-experimental-nfs-share | XHYVE_EXPERIMENTAL_NFS_SHARE | خيط | طريق إلى مجلد مضيف ليتم مشاركته داخل الضيف |
--xhyve-experimental-nfs-share-root | XHYVE_EXPERIMENTAL_NFS_SHARE_ROOT | خيط | مسار الجذر الذي سيتم فيه تركيب أسهم NFS |
--xhyve-boot2docker-url عنوان URL (مسار) صورة boot2docker.
بشكل افتراضي ، استخدم مسار ملف ISO المخزنة مؤقتًا.
--xhyve-cpu-count عدد وحدات المعالجة المركزية لاستخدام إنشاء VM.
إذا تم تعيين -1 ، استخدم وحدات المعالجة المركزية المنطقية قابلة للاستخدام في العملية الحالية.
--xhyve-memory-sizeحجم الذاكرة للضيف.
--xhyve-disk-sizeحجم القرص للضيف (MB).
--xhyve-uuid uuid للآلة.
بشكل افتراضي ، قم بإنشاء واستخدام UUID عشوائي. انظر xhyve/uuid.go
--xhyve-boot-cmd تشغيل أوامر Xhyve Kexec.
بشكل افتراضي ، استخدم
loglevel=3 user=docker console=ttyS0 console=tty0 noembed nomodeset norestore waitusb=10 base host=boot2docker
--xhyve-boot-kernel تشغيل مسار ملف kernel.
بشكل افتراضي ، سوف يقوم تلقائيًا بتحليل مسار الملف باستخدام (vmlinu[xz]|bzImage)[d]* .
--xhyve-boot-initrd تشغيل مسار ملف initrd.
بشكل افتراضي ، سوف يقوم initrd بتخزين initrd تلقائيًا.
--xhyve-qcow2 استخدام تنسيق قرص qcow2 .
إذا كنت تستخدم minikube ، يتم تضمين CONFIG_VIRTIO_BLK=y في minikube-ISO اعتبارًا من الإصدار v0.0.6.
--xhyve-rawdiskاستخدم تنسيقًا بسيطًا "قرصًا خامًا" وبرنامج تشغيل فضيلة BLK للتخزين. قد يكون هذا أسرع بكثير للتطبيقات المكثفة I/O ، بالتكلفة المحتملة لمتانة البيانات.
--xhyve-virtio-9p تمكين مشاركة مجلد virtio-9p .
إذا كنت تستخدم Docker-Machine ، يتم تضمين CONFIG_NET_9P=y في Boot2Docker اعتبارًا من الإصدار v1.10.2.
--xhyve-experimental-nfs-share /path/to/host/folder شارك path/to/host/folder داخل الضيف على المسار المحدد بواسطة- --xhyve-experimental-nfs-share-root (والذي يتجه نفسه إلى /xhyve-nfsshares ).
يمكن تحديدها عدة مرات
--xhyve-experimental-nfs-share-root /path بشكل افتراضي ، سيتم تركيب أسهم NFS في الضيف في /xhyve-nfsshares .
يمكنك تغيير هذا الافتراضي من خلال تحديد- --xhyve-experimental-nfs-share-root /path ، /path كونه طريقًا إلى الجذر
حاليًا ، لا يقوم docker-machine-driver-xhyve بتنظيف dhcpd_leases .
يحب،
# 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 سيتم تعيينه إلى 192.168.64. 2 . إذا أنشئ VM آخر ، تم تعيينه إلى 192.168.64. 3 .
لكن 192.168.64. 1 لا تستخدم أي شخص.
يبدو أن vmnet.framework قد قرر IP استنادًا إلى الملفات أدناه
/var/db/dhcpd_leases/Library/Preferences/SystemConfiguration/com.apple.vmnet.plist لذلك ، إذا كنت ترغب في إعادة تعيين قاعدة بيانات IP ، فيرجى إزالتها يدويًا. لكن محفوفة بالمخاطر للغاية .
لاحظ أن نطاق العنوان الشبكي المشترك vmnet.framework هو 192.168.64.1 ~ 192.168.64.255 . يمكنك جعل 255 VM.
سأقوم بتنفيذ عملية التنظيف بعد فهم vmnet.framework .
Mac OS X 10.11.4 Build 15E27e لديه علة Hypervisor.Framework .
هذا هو خطأ Apple.
ولكن ، تم إصلاح Apple 15E33e .
إذا قمت بتشغيل docker-machine-driver-xhyve على Build 15e27e ، فسيتم عرضه
open : no such file or directory وفي xhyve الأصلي ،
hv_vm_create failedيرى
أنا حريص جدًا على ما إذا كان المستخدمون الآخرون (باستثناء أنا) قادرين على إطلاق Xhyve.
لذا ، إذا تمكنت من إطلاق Xhyve Use Docker-Machine-Driver-Xhyve ، فهل يمكنك نشر تقرير إلى موضوع المشكلة هذا؟
#18
إذا كان MacOS الذي تم إطلاقه بواسطة Vagrant ، يمكن إنشاءه ، ولكن لن يكون قادرًا على إطلاق Hypervisor.
السبب ربما لأن الخلفية VM (VirtualBox ، VMware ، أوجه المتوازي ...) لإخفاء معلومات وحدة المعالجة المركزية.
في حالة 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)