• процессор Atlon X2 245
• оперативная память 4 гигабайта
• жесткий диск 500 гигабайт
• материнская плата ASUS M4N68T-M LE.

Хотим мы того или нет, но программы, для которых необходима Windows, никуда из офисов не исчезли. В ситуации, когда их использование безальтернативно, лучше иметь виртуальную ОС, например для того, чтобы подключиться к аудио-конференции через Skype for Business.

В этой статье я расскажу, как можно с минимальными издержками установить гостевую ОС Windows на гипервизоре QEMU с помощью графического интерфейса virt-manager. Мы нанесем на карту все подводные камни и рифы, а жучков аккуратно посадим в банку.

Эта статья посвящена автоматизации системного (end-to-end) тестирования с использованием виртуальных машин. В статье рассматриваются такие вопросы, как автоматизация развертывания и настройки виртуальных стендов, а также автоматизация запуска процессов внутри виртуальных машин с последующим контролем полученных результатов. В конце статьи мы получим пусть неидеальный (к этому мы ещё вернемся), но простой и понятный скрипт, с помощью которого вы сможете запускать системные тесты одной кнопкой, даже не имея у себя на компьютере ни одной виртуальной машины.

Статья предполагает наличие следующих навыков у читателя:

• Уверенное пользование ОС семейства Linux;
• Базовое понимание принципов виртуализации;
• Знакомство с гипервизором QEMU и графическим клиентом virt-manager

Статья разбита на две части: в первой части мы познакомимся с основными инструментами, которые позволят нам создавать, развертывать и управлять виртуальными машинами используя исключительно командную строку. Эти знания нам пригодятся для второй части статьи (которую можно найти здесь: https://habr.com/ru/post/520648/), где мы соединим эти инструменты вместе и попробуем автоматизировать тесты конкретного сетевого приложения.

Это вторая часть статьи, посвященной автоматизации системного тестирования на основе виртуальных машин. Первую часть можно найти здесь.

В этой части статьи мы будем использовать навыки, полученные в первой части, для реальной автоматизации системных тестов. В конце статьи мы получим скрипт, который каждый желающий может запустить у себя на компьютере и совершенно с нуля получить развёрнутый стенд из трёх машин, установленным тестируемым приложением, а также пройденными настоящими системными тестами (мы напишем три теста).

Приветствую читателей.

Меня зовут Андреас, давно веду видеоблог (SunAndreas) на темы гражданской информационной безопасности и сегодня о том, какими гипервизорами и менеджерами виртуальных машин лучше пользоваться особым любителям приватности и свободы. Если вы не знакомы с иными материалами моего YouTube-канала, рекомендую ознакомиться с его содержимым.

В сети крайне мало информации по более этичным аналогам инструментов виртуализации, а также имеющаяся информация не достаточная и не вполне доступная для широкого круга лиц. Сегодняшний теоретический выпуск больше для рядовых пользователей и входит в цикл видео на моём канале о виртуализации, ожидайте и последующие практические части об установке, настройке и использовании более правоверной виртуализации, чем VirtualBox. В практических частях также поговорим и о работе виртуальных машин с VPN и TOR. А сегодня пока что немного теории.

В сети только и пестрит VirtualBox, да, VirtualBox. Конечно, это очень простой и удобный вариант для совсем новичков, а также и для пользователей виндоус, которые больше ценят удобство и популярность, но сознательным людям, использующим GNU/Linux системы, настоятельно рекомендую перейти, если вы всё ещё этого не сделали, на более этичные аналоги, после того как, вроде пару лет назад, Oracle, пересмотрела немного свои позиции в отношении VirtualBox.

Ранее, более 4 лет назад, когда ещё на канале публиковалось почти легендарное видео с названием SunbooK, тогда VirtualBox был большей мере открытым и свободным проектом, не было с моей стороны к нему никакой пренебрежительности, но ныне уже лучше всё же использовать иные гипервизоры, тем более, что они позволяют легко импортировать виртуальные диски, то есть по сути виртуальные машины, которые ранее были созданы с помощью VirtualBox. Таким образом переезд с VirtualBox на иные решения может обойтись вам даже без потери данных.

Две разные системы (win + linux) на одной аппаратной базе - реальность. В этом нет ничего нового или инновационного (на данный момент времени), но если требуется максимальная производительность гостевой системы, то не обойтись без проброса реальных устройств в виртуальную машину. Проброс сетевых карт, usb-контроллеров (etc) экстраординарных особенностей не несёт, а вот попытка "шаринга" ресурсов видеокарты и процессора вполне может принести некоторое количество проблем.

Итак, а для чего, собственного говоря, городить системы с полнофункциональным использованием ресурсов GPU и CPU? Самый простой и очевидный ответ - игры (широко известный факт - если не большинство, то очень многие, написаны под ОС Windows). Другой вариант - полноценное рабочее место с возможностью запуска требовательных приложений (например, CAD-софта), быстрым бэкапом (скопировать файл ВМ куда проще, чем создавать полную копию HDD/SSD) и опцией полного контроля сетевого трафика гостевой системы.

Начнем с простого вопроса:

Что означает QEMU/KVM или QEMU-KVM?

Можно ответить - это QEMU + KVM или qemu-system, запущенный с kvm в качестве ускорителя. Но в какой-то степени это еще и анахронизм, так как с появлением KVM его разработчики для интеграции с QEMU поддерживали отдельный форк qemu-kvm, но начиная с QEMU версии 1.3 (декабрь 2012) все основные изменения из qemu-kvm были перенесены в главную ветку QEMU, а qemu-kvm объявлен устаревшим.

В разных дистрибутивах до сих пор еще можно встретить исполняемый файл qemu-kvm или просто kvm, но это лишь обертки над qemu-system:

exec qemu-system-x86_64 -enable-kvm "$@"

или симлинки:

/usr/bin/kvm -> qemu-system-x86_64

А в самом qemu существует проверка: