Ускоряем vagrant shared-folder на Windows хосте (UPD. не всё так гладко)
Я полтора года мучился с одной неприятной особенностью ubuntu под vagrant — чертовски медленная расшаренная папка. Простые бенчмарки показывали просадку производительности I/O операций почти на 2 порядка, проекты на php работали до 10 раз медленнее чем на нативном хосте. Так вот, сегодня я задолбался окончательно, хорошо поискал… и оказалось что есть решение, и теперь я просто не могу не поделиться им с кем-то. Решение простое, кому-то покажется очевидным, кто-то знал о нём с рождения (ну или будет так утверждать), но я уверен что знают о нём не все.
А чём проблема то?
По умолчанию vagrant использует файловую систему vboxsf, которая иногда работает крайне медленно (когда это «иногда» случается — я не знаю, у меня оно всегда тормозило). Свой тип файловой системы можно узнать по команде mount.
Можно заменить файловую систему, но пролема в том что официальная документация… врёт! Она говорит мол да, иногда бывают проблемы с перфомансом расшаренных папок, в таких случаях используйте nfs и будет вам счастье. А ниже приписка — на windows не сработает, и не пробуйте.
А знаете в чём соль? Да работает оно и на windows, нельзя верить документации!
Идём сюда https://github.com/winnfsd/vagrant-winnfsd, читаем, ставим, радуемся. Для тех кому лень читать:
- выполнить в windows консоли «vagrant plugin install vagrant-winnfsd»
- добавить две строки в Vagrantfile
config.vm.network «private_network», type: «dhcp»
config.vm.synced_folder «.», «/vagrant», type: «nfs»
Перезагружаем vagrant, готово! Не знаю, возможно существуют какие-то подводные камни, может кому-то не поможет, но у меня, вроде, работает отлично. Моя конфигурация: Windows 10 (host) + ubuntu 14.04 (guest). Мой проект на laravel ускорил отдачу страницы с 6.5 секунд до 0.5, что не может не радовать.
P.S. пост получился коротким, сумбурным, но попадись он мне год назад — я был бы безумно рад.
UPD. В комментариях говорят что работает нестабильно. Спустя сутки работы убедился сам — бывают проблемы с синхронизацией файлов. Так что не всё так идеально, как казалось на первый взгляд…
Штампуем окна: автоматизированное развёртывание виртуальных машин Windows на Hyper-V при помощи Vagrant (часть 3)
В принципе, ничего особенного, за исключением того, что некоторые команды, включая Install-WindowsUpdate, являются модулями Boxstarter (за что мы его и любим).
В идеале после этого можно засунуть наш скрипт в папку выполнять заветную команду vagrant up. Однако, после этого могут возникнуть некоторые сложности. Хотел бы сразу предупредить о них:
- Бывает, что при попытке поднятия виртуалки вы получите ошибку от Powershell с указанием, что диска IDE у неё быть не может. Это известный баг, который связан с тем, что если бокс подготовлен во второй версии виртуальных машин Hyper-V, то там действительно как класс отсутствуют виртуальные контроллеры IDE, о чём совершенно не догадывается наш Vagrant. Лечится недоразумение очень просто, редактированием скрипта импорта ВМ: C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.7.2\plugins\providers\hyperv\scripts\import_vm.ps1 — в соответствующих строчках нужно
Запомните этот путь, он ещё может пригодится: например, если вы наткнётесь на неизведанные доселе ошибки или захотите что-то туда прикрутить.
Ещё один нюанс связан с очерёдностью загрузки. Дело в том, что даже если на оригинальной машине стоял приоритет у загрузки с жёсткого диска, при запуске вышеупомянутого файла он почему-то понижается и в итоге при первом запуске система долго пытается загрузиться с сети по PXE и в результате Vagrant может не дождаться загрузки и не может определить IP адрес. Наблюдается в машинах второго поколения. Обычно это не то, что требуется, поэтому нужно либо отследить, когда виртуалка включилась и быстренько её перезагрузить, предварительно выставив правильный приоритет в настройках, либо соорудить костыль над вышеупомянутым файлом импорта: перед строкой “$vm_id = (Get-VM $vm_name).id.guid” необходимо добавить пару строк:
Условие нужно, т.к. в машинах первого поколения не поддерживается VMFirmware. В результате у ВМ останется всего один вариант для загрузки — VHD файл.
Скрипт import_vm.ps1 в версии 1.7.2 не умеет правильно добавлять несколько дисков к поднимаемой машине. Связано это с тем, что он не копирует имя VHD файла (да и сам файл не копируется), а ставит передаваемое ему от import.rb дефолтное “disk.vhd”, и при подключении второго диска возникает ошибка:
Cannot add ‘disk.vhdx’. The disk is already connected to the virtual machine ‘Windows2012R2x64’’. (Virtual machine ID 35449990-E3D2-4BE1-99E5-2CAACC537097).
Это известная проблема. Пока я не смог её победить наскоком, так что буду рад, если кто-то подскажет, как её можно одолеть. Иначе остаётся ждать, пока то поправят разработчики.
Вот и всё! Теперь можно штамповать виртуальные машины в любом количестве (ну, насколько хватит ресурсов гипервизора, конечно). Если не переименовать название инстанса (а оно берётся из бокса), то в имени просто дописывается “_1”, соответственно ещё одна будет иметь в конце “_1_1” (а не “_2”): так уж написан файл import_vm.ps1.
Если что-то не получилось и не всё пошло гладко — всегда можно попробовать поработать с чужим боксом. Свой я, к сожалению, дать не могу (туда уже забиты лицензионные ключи и сертификаты), однако можно воспользоваться боксом Мэта Рока, о котором уже упоминалось в статье; благо этот бокс доступен публично из интернета, его можно добавить одной командой (по умолчанию Vagrant ищет боксы у себя в облаке):
vagrant up mwrock/Windows2012R2 —provider hyperv
Поднятие о нескольких машин
Что ж, в итоге мы получили поднятие ВМ по нажатию нескольких кнопок. Что же делать, когда хочется установить сразу целое окружение? Конечно, для этого понадобиться немного поскриптовать, но не обязательно сразу браться за Powershell. К счастью, конфигурационные файлы написаны на Ruby, что позволяет поднимать несколько машин за раз из одного Vagrantfile, одной командой, причём можно даже указывать несколько различных боксов в одном файле. Процедура подробно описана в документации. При должном владении языком можно творить настоящие чудеса: например, автоматически, беря из JSON файла, назначать настройки сети и имена хостов всем машинам, а также накатывать на них рецепты Chef в зависимости от роли в том же файле (например, так). Однако, это далеко выходит за рамки этой, и так уже расползшейся статьи.
Итоги
Что ж, что мы получили в результате? Систему быстрого развёртывания Windows машин в родном для них окружении, поднимающую готовую виртуалку и настраивающую её согласно нашим требованиям.
Чем это помогло конкретно нашей компании? Это значительно экономит время на поднятие новой инфраструктуры: раньше установка системы из ISO файла, настройка и обновление всего софта могла занять полдня, теперь это считанные минуты. Даже клонирование машин из шаблонов System Center обычно происходит дольше, не говоря уже о перечисленных недостатках типа наследования файлов виртуальных жёстких дисков. Также это отличный инструмент для наших разработчиков и тестировщиков, которые получили возможность быстро поднять на локальной системе (даже на рабочих станциях с Windows 8.1) какое-то тестовое окружение. Для этого я написал простую короткую инструкцию, так что им не надо вникать в детали и отвлекаться от рабочего процесса.
Что дальше? Сейчас мы ведём активную работу по анализу и документированию имеющихся окружений, чтобы потом описать их в виде рецептов Chef. Наши службы планируется устанавливать и выкатывать в виде пакетов. Это позволит автоматизировать множество процессов, избавиться от множества рутины и ошибок, связанных с человеческим фактором. В общем, то, что доктор DevOps прописал. Также в планах осваивание Packer, если понадобиться быстро готовить много разных образов. Поддержка Hyper-V и Azure в нём появилась совсем недавно, но выглядит очень многообещающей. Также в планах работа по быстрой синхронизации папок между ВМ и хостом — к сожалению, обычный шаринг работает довольно медленно для большого количества файлов и активных операциях (например, билде).
Если эта статья была полезной и тема в целом интересна — я с радостью сделаю отдельную публикацию о наших последующих победах и неудачах на этом поприще.
Vagrant doesn’t honor `config.vm.synced_folder` set to `disabled` and sets up an rsync folder with a CentOS 7 guest using VirtualBox #6154
Comments
Copy link Quote reply
tjanez commented Aug 17, 2015
Versions of installed components (the system is Fedora 20):
Steps to reproduce the problem:
Add the official CentOS 7 box to Vagrant:
Use the following Vagrantfile :
Expected Results:
Vagrant disables syncing the current folder.
Actual Results:
Even though syncing the current folder is disabled, Vagrant installs rsync on the guest machine and rsyncs the contents of the current folder. Here is the output:
wshallum commented Aug 29, 2015
Is this not caused by the target path being different? The CentOS 7 box’s Vagrantfile specifies:
In my Vagrantfile, using
works for me. It no longer tries to install rsync or sync the directory. Of course, there is still the question of why they create an image that uses rsync by default and then not include rsync in the image.
mwiora commented Sep 23, 2015
with the specification of the right destination folder this works for me too.
darkn3rd commented Nov 6, 2015
Is this the new default in 1.7.4 where /vagrant is disabled now? It is no longer mounting the current working directory as /vagrant . Instead I get this rsync folder.
exstral commented Nov 18, 2015
This rsync shared folder is set in the Vagrantfile contained in the «centos/7» box.
I guess that for some reason the creators of the official box thought it prudent that everyone use rsync without giving us a hint or description on how to properly disable it. Thankfully I found this issue 🙂
mitchellh commented Nov 19, 2015
I also can’t reproduce this. I’m going to mark as not a bug.
vikas027 commented Feb 10, 2016 •
I also faced this today on a CentOS 7 box.
In CentOS 7, this works
gdanielson commented Apr 20, 2016
I’m experiencing this too.(just starting to use vagrant so I might’ve done something wrong)
Running on OS X Vagrant 1.8.1 and VirtualBox 5.0.18
A new centos/7 attempts to rsync by default from . to guest
This is the Vagrantfile it created
If I destroy and update the Vagrantfile to
the rsync doesn’t fire up.
Where is that rsync being triggered from? I guess there is some other config somewhere controlling this?
vikas027 commented Apr 22, 2016
@gdanielson I did not quite understand your issue. Do you want rsync to be enabled or disabled ?
If you want to disable it, just see my previous comment. If you want to enable it (which it is by default), then you can do something like this
gdanielson commented Apr 25, 2016
I wanted to disable rsync. I didn’t think that something like rsync replication would be enabled by default so I assumed it was an error.
automaticgiant commented Oct 30, 2017 •
i have this problem with debian/jessie64 , and i can’t install rsync before configuring the proxy settings in apt. (well, to be clear, my problem is that i don’t have a synced folder but it wants to install rsync anyway.) ah. and when i changed config.vm.synced_folder «.», «/home/vagrant/sync», disabled: true to listing /vagrant , i suspect it lined up with the default setting for debian/jessie64 and disabled it and doesn’t need to install rsync now.
so it’s a box «problem».
vhosakot commented Dec 17, 2017 •
When I did vagrant up with the box centos/7 (virtualbox, 1703.01) , ==> default: Rsyncing folder: /root/ => /vagrant was stuck for me too, and adding
config.vm.synced_folder ‘.’, ‘/vagrant’, disabled: true
in Vagrantfile resolved the issue for me and rsync did not happen.
hashibot bot commented Mar 29, 2020
I’m going to lock this issue because it has been closed for 30 days ⏳ . This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.