Автомобиль с веб интерфейсом

Всего понемногу: автомобиль, облако, Raspberry Pi и CAN

Развлекательный центр (in-vehicle infotainment, IVI) стал неотъемлемой частью современного автомобиля. Если раньше это был просто радиоприемник, затем кассетный магнитофон, потом музыку можно было слушать просто с флэшки, а теперь едва хватает двух дисплеев по 10.25-дюймов для приборной панели и развлекательного центра в новом Mercedes A-класса. Кстати, IVI – это уже не только музыка, но и навигация, доступ к Интернет и многие другие возможности внутри транспортного средства, которые потихоньку дают старт воплощению концепции «подключенного автомобиля» (Connected Car). Пожалуй, автотранспорт так же очень близок к реализации концепции Интернета вещей (IoT). И все это достигается благодаря «ассимиляции» компьютера и автомобиля.

В продолжении предыдущей заметки «Автомобиль, Интернет вещей и прочие технологии» хотелось бы рассмотреть идеи для воплощения автомобильного компьютера на уровне открытых проектов и немного затронуть современные тенденции в этом ключе.


Image: Bringing its A game: new 2018 Mercedes A-class hatch revealed – CAR Magazine

Интернет вещей – это не призрак далекого будущего, а вполне реализуемая концепция настоящего. Начиная от лампочек и завершая домашними голосовыми ассистентами – все эти устройства уже имеют доступ в Интернет и могут взаимодействовать между собой. Да, сейчас для этого нужно немного настроить, например, сервис IFTTT и т.п., но прогресс уже не остановить. Как следствие – компьютер начинает проникать в автомобиль, как базовый компонент развлекательного центра. Для автопрома есть вполне обоснованные ограничения, которые прямо влияют на скорость развития IVI – это соблюдение всех мер безопасности. В любом случае, нельзя пренебрегать безопасностью как своей, так и других участников дорожного движения. Автомобиль и дорога – не место для экспериментов. Поэтому проекты энтузиастов, которые хочется рассмотреть в этой заметке – лишь идеи, которые возможно перерастут в будущие прототипы, но уже для коммерческих предложений. Конечно, если речь заходит о безопасности, то доверять следует сертифицированным изделиям, за которыми стоят часы разработок и тестирования.

Поскольку речь пошла о Connected Car и IVI, то стает очевидным использование ресурсов облака с функциями IoT, для реализации на «верхнем уровне» соответствующей программно-аппаратной архитектуры. Например, большинство универсальных облачных платформ, таких как Amazon AWS, Microsoft Azure, IBM Watson или др., содержат практически универсальные сервисы для построения Интернета вещей. По сравнению с сними, будут интересны и открытые решения в этой сфере. Проект Kaa является одним из таких примеров.


Picture: Веб-интерфейс платформы Kaa

Разработчики позиционируют Kaa, как многоцелевую платформу промежуточного уровня для решений IoT, нацеленную на создание приложений для подключенных устройств и интеллектуальных систем. Платформа Kaa представляет собой открытый, многофункциональный инструментарий для разработки встраиваемых систем и решений для облака. Платформа выпущена под лицензией Apache Software License 2.0. Для быстрого ознакомления с платформой можно скачать образ для VirtualBox или развернуть систему в облаке AWS.

Идея Kaa заключается в том, что разработчикам предоставляется SDK для создания приложений с использованием API рассматриваемой платформы, и соответствующие сервисы в облаке, включая компиляцию низкоуровневых программ. В текущей версии поддерживаются языки: C, C++, Java, Objective-C и операционные системы Linux, Windows, Android и iOS, а также заявлена поддержка множества встраиваемых аппаратных платформ, например, Raspberry Pi, Intel Edison.

Тут хочется отвлечься и заметить, что, примерно, как когда-то давно в начале 2000-х годов Intel ушла с рынка микроконтроллеров со своим интереснейшим решением – MCS-51, а сейчас, фактически, мы являемся свидетелями подобного – завершение разработки систем Galileo, Joule и Edison, это не осталось не замеченным у сообщества разработчиков и энтузиастов. Многие идеи из предыдущих систем станут началом для новых устройств и решений. Конечно, если для кристалла i8051 (MCS-51), компания Intel продолжила лицензировать его архитектуру, даже после своего ухода с рынка микроконтроллеров, то сейчас, пожалуй, значительно укрепятся позиции Raspberry Pi и Arduino (на классической платформе микроконтроллеров Atmel), как основных инструментов прототипирования встраиваемых устройств. Но не стоит забывать, что для IoT также интересны разработки на основе устройств ESP8266/ ESP32 Espressif и подобные системы с интегрированным интерфейсом Wi-Fi на кристалле.

Возвращаясь к проекту Kaa, следует отметить, что существует ряд архитектурных особенностей, которые делают разработку IoT на этой платформе исключительно быстрой и легкой. Решения на Kaa не должны зависеть от конкретной аппаратной платформы и, таким образом, проект является совместим практически с любыми подключенными устройствами, датчиками и шлюзами. Конечно, это достигается за счет использования универсальных протоколов связи и стандартизированных интерфейсов между компонентами системы. Также Kaa обеспечивает четкую структуру функций и расширений IoT для различных типов приложений. Они могут использоваться, почти по аналогии технологии plug-and-play, с минимальным кодом, который все-таки должен доработать разработчик для своих систем и устройств. Эти возможности, в сочетании с аналитикой в облаке, делают Kaa достаточно привлекательной платформой для Connected Car и др. решений.

Проект Kaa успешно развивается и совершенствуется, но есть и другая, можно сказать, обратная задача для построения решений Connected Car. Суть ее лежит в выполнении задач тестирования программной части облачной системы и непосредственной эмуляции поведения множества подключенных к облаку автомобилей. Для этой задачи интересны проекты с открытым кодом, например, AutoSIM компании Automatski, который разрабатывается с поддержкой двух лицензий: GPLv3 и коммерческой. В данной системе используются основные протоколы передачи данных, включая MQTT, AMQP, CoAP и др. Пользователь при помощи Rest/Json API управляет работой сервера для симуляции требуемых процессов. AutoSIM теоретически позволяет имитировать поток данных от более чем 100 миллионов устройств.

Kaa и AutoSIM – замечательные примеры открытых систем и, возможно, решений, которые станут очень востребованными для автопрома. Но уже сейчас, на нижнем уровне встраиваемых систем для автомобиля, есть множество интересных открытых решений, которые успешно взаимодействуют с облачными сервисами. Например, платформа Android Auto компании Google. Это решение базируется на Android Automotive и нацелено на объединение смартфона и автомобильного медиа-центра в единую платформу, расширяющую функционал IVI-систем.

Читайте также:  Александр радулов и его автомобиль

Поскольку в современном автомобиле присутствуют множество блоков, которые непосредственно взаимодействуют с медиа-центром, например, с использованием сетей Controller Area Network (CAN), Local Interconnect Network (LIN), Media Oriented Systems Transport (MOST), а также более привычные Ethernet и протоколы TCP/IP, то Android Automotive предлагает некоторую абстракцию – hardware abstraction layer (HAL) между физическими сетями автомобиля и функционалом операционной системы Android, доступного разработчикам.


Figure: Vehicle HAL and Android automotive architecture

Но, если Android вполне прогнозируемое решение от Google, то использование Linux, в качестве платформы для автомобильного развлекательного центра, пожалуй, уже стала классикой жанра. И, как говорится, кто-нибудь определенно должен был предложить проект, например, Automotive Grade Linux. Это открытая разработка, объединяющая автопроизводителей, поставщиков и технологические компании под эгидой The Linux Foundation. Конечно, AGL доступен в виде исходного кода, а для первоначального знакомства можно скачать образ виртуальной машины, например, для запуска в VirtualBox или вполне можно запустить дистрибутив систему на Raspberry Pi. Для работы с AGL SDK потребуется Docker.


Picture: Automotive Grade Linux – Getting Started

Разработка приложений для AGL предусмотрена на HTML5, Qt OpenGL. Сама платформа автомобильного Linux сосредоточена на безопасности. Например, архитектура решения предполагает гипервизор и, конечно, изоляцию критически-важных приложений, систем мультимедиа и развлечений. Приложения и компоненты AGL строятся по модульному принципу с интерфейсами в виде сигналов/событий, что позволяет скрыть сложную программную реализацию низкоуровневых решений, например, реализацию интерфейса CAN-шины, и предоставить простой API для приложений.


Figure: Upgraded Security Blueprint 2017. AGL security overview — Automotive Grade Linux Documentation

Интересно, что разработчики Automotive Grade Linux присматриваются к реализациям уровня архитектуры из других проектов, впрочем, что характерно для всего движения открытых систем. Например, интересным решением в проекте OpenXC является принцип описания в формате JSON всех сигналов CAN, которые нужно обрабатывать. Программный генератор преобразовывает такое описание в файл на языке C ++, которая может быть скомпилирована и т.п.


Figure: OpenXC is an open source, data-focused API for your car

Если говорить о проекте OpenXC, то в нем используется комбинация аппаратного и программного обеспечения с открытым исходным кодом, которое позволяет расширить функционал автомобиля с помощью специальных приложений и подключаемых модулей. Проект сконцентрирован на получении данных об автомобиле и использует стандартный интерфейс диагностического разъема OBD-II. Фактически проект позволяет разработать свое мобильное приложение под Android, iOS или использовать для разработки Python, а в качестве основной автомобильной платформы выбрана марка Ford.

Возвращаясь к проекту Automotive Grade Linux стоит заметить, что в нем Raspberry Pi используется скорее для целей демонстрации и прототипирования, а вот для промышленной платформы выбраны специализированные решения, например, системы на базе ARM SoCs (система на чипе) компании Renesas Electronics серии R-Car Generation 3 и некоторые др.


Figure: R-Car H3. System Block Diagram – Renesas Electronics

Поскольку можно и дальше рассматривать различные платформы для построения IVI-систем, то хочется сделать небольшой вывод об уже приведенных примерах. Все говорит о том, что текущий, 2018 год, будет годом доставляемых пользователю и разработчику приложений. Ведь, как в проекте облака Kaa, так и решениях для операционной системы AGL, используется принцип предоставления практически готового приложения в виде SDK для разработчика. Также широко используется подход на основе описания критериев разрабатываемой системы, например, в формате JSON, и генерации на их основе каркаса приложения. Это чем-то напоминает идеи раскрытые ранее в публикации: «Быстрое прототипирование устройств Интернета вещей», где были рассмотрены решения, в которых разработчики микросхем предоставляют стартовые наборы и т.п. для быстрого ознакомления с их компонентами. Действительно, для программиста, разрабатывающего проект для IoT, всегда будет удобно начать разработку не с детального ознакомления с «неким» API, а с уже готового каркаса приложения.

Давайте обратим внимание на немного другой уровень IVI, где не используются такие многофункциональные системы, как Renesas или др. Интересно рассмотреть подходы на основе уже традиционного решения Raspberry Pi. Понятно, что все это скорее прототипы, т.к. Raspberry Pi вряд ли можно сравнить с промышленной платой, специально разработанной для автомобильных применений, но всегда интересны идеи и подходы энтузиастов. Так, одним из любопытных решений для медиа-центра стоит отметить проект CarPC, который фактически является разработкой и совершенствованием графического интерфейса и дополнительного функционала для известного кроссплатформенного медиапроигрывателя Kodi (ранее проект XBMC).


Picture: CarPC-touch for Kodi

Но Kodi или другой медиа-центр не позволят получить и отобразить данные из бортовой сети автомобиля. Для этого проще всего подключиться к диагностическому разъему автомобиля, как было рассмотрено в нашей предыдущей публикации: «Разъем диагностики OBD-II, как интерфейс для IoT». И тут интересен проект Carberry, представляющий из себя плату расширения для Raspberry Pi.


Picture: Carberry for RPi 3 – Paser

Плата Carberry итальянской компании Paser стоит 123.83 € (евро). Она подключается к стандартному порту расширения Raspberry Pi 3 и поддерживает: CANBUS, GMLAN, инфракрасный приемник и другой функционал. Плата расширения служит отличным дополнением к программным решениям, например, уже упомянутому CarPC. Следует отметить, что программно-аппаратный проект постоянно развивается в сторону расширения функционала и т.д.


Picture: What is AutoPi and What Does It Do? – AutoPi.io

Так же активно развивается немецкий стартап AutoPi, представляющий собой проект автомобильной IoT-платформы. Интересной в AutoPi является аппаратная часть на базе Raspberry Pi Zero и наличием интерфейса OBD-II, а также: 3G/4G, Bluetooth, WiFi, GPS-приемника и других компонентов, умещающихся в достаточно небольшом устройстве.

Стоит заметить, что низкая цена модуля MCP2515/TJA1050 обусловлена его скромным размером и количеством элементов на плате. Она отлично подходит для работы с платами Arduino, но в таком случае при программировании следует не забывать, что в основном на модуль MCP2515/TJA1050 разработчики устанавливают кристалл кварца 8 MHz, а не 16 MHz, который обычно присутствует на большинстве плат Arduino CAN-BUS Shield. Таким образом, само-собой напрашивается использование модуля MCP2515/TJA1050 для подключения к Raspberry Pi и работа с шиной CAN, например, с эмулятором OBD-II, рассмотренным все в той-же статье «Разъем диагностики OBD-II, как интерфейс для IoT» или напрямую с модулем ELM327 и т.п.

Читайте также:  Автомобиль с эмблемой головы коня


Picture: Модуль CAN Bus на базе MCP2515/TJA1050

Но работая с электронными модулями всегда нужно внимательно относиться к напряжению питания и ограничениям по линиям передачи данных. При использовании стандартного интерфейса расширения GPIO платы Raspberry Pi это достаточно актуально. Дело в том, что на разъеме Raspberry Pi присутствуют напряжения 5В и 3.3В, которыми можно запитать внешние схемы, однако, линии ввода-вывода платы работают только с уровнями до 3.3В. Соответственно, плату модуля MCP2515/TJA1050, рассчитанную только на 5В не следует сразу подключать к Raspberry Pi.


Schematic: CAN bus on raspberry pi with MCP2515 – Raspberry Pi Foundation Forum

Решением может стать простой двухсторонний преобразователь уровней 3.3В/5.5В. Таких готовых модулей для шины SPI предостаточно, но MCP2515 имеет дополнительный вывод прерывания, свидетельствующий о готовности данных. Такой вывод позволит процессору Raspberry Pi выполнять свою работу и реагировать на данные от MCP2515 только в требуемые моменты времени, не отвлекаясь постоянно на мониторинг SPI-интерфейса. Следовательно, готовый модуль сопряжения не будет иметь дополнительного контакта и нужно будет просто сделать свою схему.


Picture: Небольшая доработка модуля CAN Bus на базе MCP2515/TJA1050 для работы с Raspberry Pi

Есть и совершенно простое решение, но конечно, не лучшее. Оно основано на том, что микросхема MCP2515 вполне работоспособна с уровнем напряжений от 2.7В до 5.5В, значит ее можно запитать 3.3В с Raspberry Pi, а линии интерфейса SPI и прерывания INT – подключить к GPIO. Для TJA1050 потребуется питание 5В, которое можно подключить все с того же разъема GPIO, но на модуле MCP2515/TJA1050 потребуется аккуратно перерезать дорожку общего питания и подпаяться к ней.

В качестве правильного усовершенствования такой схемы очень разумно использовать делитель напряжения для согласования уровней 5В микросхемы трансивера TJA1050, кстати, можно использовать аналог MCP2551 от компании Microchip или др., и CAN-контроллера MCP2515 с питанием 3.3В (см. рис.). Также интересен проект CAN Simulator на основе Raspberry Pi и, конечно, MCP2515. В качестве трансивера в симуляторе используется микросхема TJA1049, которая хотя и требует питание 5В, но работает без дополнительных компонентов согласования уровней с 3-х вольтовыми системами. Если выбирать самое интересное решение, то, пожалуй, проект CAN-Bus Interface with galvanic isolation самый интересный, так как предлагает использовать трансивер MCP2562, позволяющий без дополнительных элементов подключить контроллер с напряжениями в диапазоне от 1.8В до 5В.


Schematic: CAN + Raspberry Pi

Определившись с аппаратной частью можно переходить к работе с Raspberry Pi на программном уровне. В качестве операционной системы выберем достаточно традиционное решение Raspbian Stretch. А для работы с CAN поддержку драйвера MCP2515 уровня ядра Linux.


Picture: Передача данных между Raspberry Pi и Arduino по шине CAN

В нашем случае – это Linux raspberrypi 4.9.59+. Более детальную информацию о дистрибутиве и самой плате можно узнать, используя команды:
$ cat /etc/debian_version – версия базового дистрибутива Debian;
$ cat /etc/os-release – особенности релиза;
$ cat /proc/cpuinfo – версия аппаратной платформы (подробности можно узнать из статьи: «How to Check the Software and Hardware Version of a Raspberry Pi»).

Для работы SPI с микросхемой MCP2515 нужно добавить параметры в конфигурационный файл /boot/config.txt операционной системы:
# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=spi=on
dtoverlay=mcp2515-can0, oscillator=8000000, interrupt=25

Понятно, что если кварц на плате 16 МГц, то нужно указать число «16000000».
# dtoverlay=spi-bcm2835-overlay
Драйвер bcm2835 потребуется явно указывать в конфиге только для старых ядер Linux до kernel 4.4.x+

Следующий параметр следует раскомментировать для современных систем:
# dtoverlay=spi1-1cs

А, вот, после долгих поисков нашлась актуальная строчка, которая позволила заработать нужному модулю на ядре Linux raspberrypi 4.9.59+ в текущей системе:
dtoverlay=spi0-hw-cs

После перезагрузки можно просто «поднять» сетевой интерфейс:
$ sudo ip link set can0 up type can bitrate 500000

Чтобы каждый раз при старте системы не «поднимать» интерфейс, можно добавить пару стандартных строк в файл конфигурации /etc/network/interfaces и т.п.

Screenshot: Передача данных между Raspberry Pi и эмулятором OBD-II на базе платы Arduino
Дальше остается писать новый код или использовать готовые библиотеки. Поскольку драйвер MCP2515 фактически дает системе новый сетевой интерфейс, то разработку можно выполнять практически на любом языке. И тут сразу хочется сказать немного о Go, кроссплатформенном, компилируемом, многопоточном языке программирования, разработанным компанией Google. Этот язык однозначно очень интересен в плане разработки встраиваемых систем и, конечно, будет совсем не сложно найти под него уже готовую библиотеку, подходящую для проекта, например, CAN bus in Go. А если зайти дальше, то следует рассмотреть и проект Gobot – фреймворк, направленный на создание роботов, решений для IoT и т.д. Но, пожалуй, для этой публикации это будет уже слишком много.

К вопросам программирования на Go обязательно следует вернуться, но уже в следующих публикациях. Так же нужно будет не забыть об операционной системе Tizen, на которой ранее базировалась Automotive Grade Linux, а также рассмотреть тренд этого года – голосовые ассистенты в салоне автомобиля и многое др. А в завершении авто тематики текущей публикации просто вспомним о платформе цифровой кабины, представленной Samsung и HARMAN на CES 2018 и немного вдохновимся идеями дизайнеров и инженеров, разработавших этот концепт.

Источник

Настройка среды для веб разработки в Windows на основе виртуальной машины VMware Player

Пытаться разрабатывать большие и средние PHP проекты на Windows, по моему, не совсем правильно. Поэтому если PHP разработка это ваше основное занятие, то скорее всего вас давно на рабочей машине стоит Linux и горя вы не знаете. Но если по каким-то причинам вы также, как и я, прилипли к Windows, но при этом вам необходимо работать с веб проектами, эта статья поможет вам настроить и запустить 100% полноценную среду для веб разработки с любым набором линукс софта, докером, и при всем этом красиво интегрированную в Windows.

Читайте также:  Акции автомобили официальный дилер в москве

После долгих лет работы под всякими Denwer/OpenServer, мучениями с нативным докером для Windows, VirtualBox-ом, попыткой использовать подсистему Ubuntu в Windows и прочее, прочее… я наконец-то нашел связку ПО, которая позволяет поднять безупречную Linux систему поверх Windows и сделать работу внутри Linux такой же органичной, как и работу с любым приложением Windows.

Немного истории TL DR

Когда-то очень давно был Денвер, Far manager и FTP. Этого хватало. Потом подключались ssh, git, phing, composer — но все это так или иначе, с небольшими танцами с бубном, можно было настроить в Windows и продолжать жить в своем счастливом мире. Это было предельно просто, понятно и легко.

Такая счастливая пора длилась довольно долго. Но в какой-то момент стартовала неистовая гонка за новыми технологиями, которая с каждым годом лишь набирала обороты. Денвер не успевал и не хотел успевать за выходом новых версий PHP, проекты росли и становились сложнее, зоопарк технологий плодился на глазах.

Спасением на некоторое время стал OpenServer. Очень адекватное решение для Windows с большим количеством инструментов и достаточно актуальными версиями ПО. На нем удалось продержаться несколько лет. Если вы начинающий разработчик, прилипший к Windows, если у вас относительно простые проекты, или веб разработка это ваше не основное занятие, то выбор в пользу OpenServer для вас может быть очень хорошим решением. Просто, удобно и понятно.

Но зоопарк технологий в нашей компании тем временем продолжал расти — nodeJS, elastic, разные версии PHP для разных проектов — от 5.6 до 7.1. Стартанули проект на PHP 7.1, а OpenServer оказывается не поспевает… На момент написания этой статьи поддержка 7.1 уже есть, но тогда не было. Да и обновлять OpenServer занятие не очень приятное, т.к. с переносимостью настроек между версиями у них тяжело.

Немного потыкался, погуглил более продвинутые аналоги OpenServer. Не нашел ничего вразумительного. Ну и бросил это дело, т.к. для средних и больших проектов с кучей зависимостей этот путь развития кажется тупиковым.

Подсистема Ubuntu в Windows 10?

Была предпринята попытка настроить подсистему Ubuntu на Windows. Потыкался, что-то попытался поставить и настроить. Это не работает, то глючит, документации внятной не найдешь.

Docker на Windows?

Пришлось проапргрейдить домашнюю версию до professional, чтобы все заработало нативно. Несколько дней возьни с настройками, перенастройками, установками. Ну и плюсом погружение в докер. Работает!

Серьезно, докер на Windows работает вполне вполне успешно, и наверняка пойдет для мелких и средних проектов. У меня же все уперлось в производительность файловой системы в shared volumes. Этот баг давно известен и хорошо описан, например здесь, проявляется он на Windows и Mac.

На практике на моей машине с SSD диском это выглядело так — открытие стартовой страницы сразу после дефолтной установки Symfony 3 занимало в среднем 1.5 секунды. Проект над, которым мне надо было работать, самую простую страницу открывал около 10-15 секунд, некоторые тяжелые страницы вообще не открывались. Работать в таких условиях я посчитал нереальным.

Существует проект docker-sync, который как раз призван решить проблему со скоростью работы файловой подсистемы. Вместо использования shared volumes, docker-sync организует двунаправленную синхронизацию файлов между вашей локальной системой и докер контейнерами. К сожалению, попробовать docker-sync в реальной работе мне так и не довелось. К тому моменту я устал от обилия костылей, которыми обрастала моя конфигурация среды разработки на Windows и решил снова дать шанс виртуальным машинам.

Виртуальная машина

«Это то, с чего надо было начать!» — скажет продвинутый читатель, и окажется почти прав.
Конечно, за всю историю своей веб разработки на Windows, я не раз пытался переключиться на использование виртуальных машин. Но ни одна из тех попыток не была успешной из-за значительного ухудшения User Experience, который я получал при использовании виртуалок. Не знаю, с чем это связано, может с недостатками VirtualBox, который я использовал, может с кривыми руками и ленью, но факт, остается фактом — я пробовал Linux в VirtualBox, натыкался на какие-то проблемы одна за одной, плевался, все бросал и возвращался в свой уютный Windows.

В очередной раз, обернувшись в сторону виртуализации, я нашел очень многообещающую инструкцию по установке Linux на бесплатную версию WMVare Player.

Минимальный набор требований к виртуальной машине для комфортной работы выглядел с моей стороны примерно так:

Я очень надеюсь, что с установкой xubuntu в виртуальную машину вы справились самостоятельно, также как и справитесь с настройкой необходимого ПО для запуска своих веб проектов на Linux. Для этого достаточно следовать любой инструкции по установке Nginx, Apache, MySQL, PHP и других приложений на Ubuntu. Либо использовать Docker, как это делаю теперь и я.

Кстати, приложение которое у меня выполнялось по 15 секунд и больше в докер контейнерах на Windows, в виртуальной машине отрабатывает секунды за 3, т.е. в 5 раз быстрее. Конечно, хотелось бы еще большей скорости, но пока это лучший вариант из найденных мной, и он очень удобный.

Данная статья во многом основана на материале из данного видео. Если вы хотите увидеть полную пошаговую инструкцию по установке и настройки виртуальной машины, то рекомендую к просмотру. Язык — английский, автор видео — Nick Janetakis.

Источник

Ответы на популярные вопросы