Автоматизация для самых маленьких. часть 1.1. основы виртуализации / хабр

Область стека

Всякий раз, когда в JVM создается новый поток, одновременно создается отдельный стек среды выполнения. Все локальные переменные, вызовы методов и частичные результаты хранятся в области стека.

Если для обработки в потоке требуется больший размер стека, чем доступно, JVM выдает ошибку .

Для каждого вызова метода в памяти стека делается одна запись, которая называется фреймом стека. Когда вызов метода завершен, фрейм стека уничтожается.

Фрейм стека разделен на три части.

Локальные переменные. Каждый фрейм содержит массив переменных, известных как его локальные переменные. Здесь хранятся все локальные переменные и их значения. Длина этого массива определяется во время компиляции.
Стек операндов. Каждый фрейм содержит стек последним-вошел-первым-вышел (last-in-first-out, LIFO), известный как стек операндов. Он действует как рабочая область среды выполнения для любых промежуточных операций. Максимальная глубина этого стека определяется во время компиляции.
Данные фрейма. Здесь хранятся все символы, соответствующие методу. Здесь также хранится информация о блоке на случай исключений.

К примеру, есть следующий код:

double calculateNormalisedScore(List<Answer> answers) {  double score = getScore(answers);  return normalizeScore(score);}double normalizeScore(double score) {  return (score – minScore) / (maxScore – minScore);}

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

Примечание: поскольку область стека не является общей, она по своей сути потокобезопасна.

Инструмент выявления сетевых атак

Офисные сети обычно не испытывают необходимости в сенсорах и датчиках,
детектирующих вторжение, а если и испытывают, то дело обычно ограничивается
приобретением коммерческой IDS/IPS-системы, встраиваемой в брандмауэр и спокойно
работающей на шлюзе в интернете или на одном из узлов локальной сети.

С ростом сети появляется желание установить специализированную систему
обнаружения вторжений, например, Snort (бесплатный) или AMP (коммерческий). И
разместить ее на выделенном узле, поскольку для установки того же AMP
администратор должен предоставить его поставщикам удаленный shell на свою
машину. Причем, AMP будет не только автоматом скачивать свежие сигнатуры из
Сети, но и отправлять весь подозрительный трафик для анализа на серверы компании
Endeavor, которая и является его разработчиком.

Доверие — это прекрасно, но отдавать свой трафик в чужие руки… Нет, лучше
размесить эту штуку на отдельном узле, отключенном от основной локальной сети,
но запитанном от того же самого ISP – то есть ловящего тех же вирусов и червей,
что и основные узлы локальной сети. Можно ли использовать для этой цели
виртуальную машину? Конечно! Главное, надежно изолировать ее от корпоративной
сети.

Наибольшую проблему представляют виртуальные сетевые карты, через
которые гостевая операционная система легко доберется до основной. Все
виртуальные карты в обязательном порядке должны быть отключены! Но… если у нас
нет сети, как же тогда общаться с внешним миром и ловить трафик? Вариантов
много. Вот только один из них: ADSL-модем с USB-интерфейсом, подключенный к
виртуальной машине с выдернутой сетевой картой и заблокированными шарами.

Какую именно виртуальную машину следует использовать? VMware очень известна и
слишком дырява. Bochs невероятно медленно работает. Virtual PC – неплохой выбор,
но учитывая большое количество дыр в процессорах, его использование крайне
небезопасно. Реально остается только VirtualBox, XEN или QEMU, хотя первый из
них все еще достаточно сырой и до сих пор не отлаженный.

Сборщик мусора

Сборщик мусора (Garbage Collector, GC) собирает и удаляет объекты без ссылок из области кучи. Это процесс автоматического восстановления неиспользуемой памяти во время выполнения путем уничтожения мусорных объектов.

Сборка мусора делает память Java эффективной, потому что удаляет объекты без ссылок из памяти кучи и освобождает место для новых объектов. Она включает два этапа:

Пометка — на этом этапе GC идентифицирует неиспользуемые объекты в памяти.
Очистка — на этом этапе GC удаляет объекты, идентифицированные на предыдущем этапе.

Сборка мусора выполняется JVM автоматически через регулярные промежутки времени и не требует отдельной обработки. Ее также можно запустить вызовом , но выполнение не гарантируется.

JVM содержит три различных типа сборщиков мусора.

Последовательная сборка мусора. Это самая простая реализация GC. Она предназначена для небольших приложений, работающих в однопоточных средах. Для сборки мусора используется один поток. Запуск приводит к событию “остановки мира”, когда все приложение приостанавливает работу. Аргумент JVM для запуск последовательного сборщика мусора: .
Параллельная сборка мусора. Это реализация GC по умолчанию, также известная как сборщик пропускной способности. Для сборки мусора в нем используется несколько потоков, но работа приложения все равно приостанавливается при запуске. Аргумент JVM для параллельного сборщика мусора: .
Garbage First (G1). G1 был разработан для многопоточных приложений с большим доступным размером кучи (более 4 ГБ). Он разбивает кучу на набор областей одинакового размера и использует несколько потоков для их сканирования. G1-сборщик определяет регионы с наибольшим количеством мусора и сначала выполняет сбор мусора в них. Аргумент JVM для этого сборщика мусора: .

Примечание: существует другой тип сборщика мусора, называемый сборщиком параллельных меток (CMS). Однако он устарел начиная с Java 9 и полностью удален в Java 14, и его место занимает сборщик G1.

Нативный интерфейс Java (Java Native Interface, JNI)

Иногда необходимо задействовать в работе нативный (не Java) код (например, написанный на C/C++). К примеру, в тех случаях, когда нужно взаимодействовать с физическим оборудованием или преодолевать ограничения по управлению памятью и производительности в Java. Java поддерживает выполнение нативного кода через нативный интерфейс Java (JNI).

JNI действует как мост для предоставления вспомогательных пакетов другим языкам программирования, таким как C, C++ и так далее. Это особенно полезно в тех случаях, когда нужно написать код, который не полностью поддерживается Java, например, некоторые специфичные для платформы функции могут быть написаны только на C.

Вы можете воспользоваться ключевым словом , чтобы указать, что реализация метода будет предоставлена нативной библиотекой. Также потребуется вызвать , чтобы загрузить общую нативную библиотеку в память и сделать ее функции доступными для Java.

Нативные библиотеки методов

Нативные библиотеки методов — это библиотеки, написанные на других языках программирования, таких как C, C++ и ассемблер. Эти библиотеки обычно представлены в виде файлов или . Такие библиотеки можно загружать через JNI.

Распространенные ошибки JVM

. Происходит, когда загрузчик классов пытается загрузить классы с помощью , или , но определение класса с указанным именем не найдено.
. Происходит, когда компилятор успешно скомпилировал класс, но загрузчик классов не может найти файл класса во время выполнения.
. Происходит, когда JVM не может выделить объект из-за нехватки памяти, и сборщик мусора не может предоставить больше памяти.
. Происходит, если в JVM не хватает места при создании новых кадров стека во время обработки потока.

Заключение

В этой статье мы обсудили архитектуру виртуальной машины Java и ее компоненты. Часто мы не вникаем глубоко во внутреннюю механику JVM или не интересуемся, как она работает, пока работает код.

Только когда что-то идет не так, и нам нужно настроить JVM или устранить утечку памяти, мы пытаемся понять ее внутреннее устройство.

Это также очень популярный вопрос во время интервью на роль бэкенд-разработчика — как младшего, так и старшего уровня. Глубокое понимание JVM поможет вам лучше писать код и избегать подводных камней, связанных со стеком и ошибками памяти.

9 вещей, которыми следует заняться Java программисту в 2018 году
Превратите свой Java-код в полностью асинхронный
Циклы Java в сторону — даешь потоки!

Читайте нас в Telegram, VK и

1.2.2. Недостатки виртуальных машин

Тем не менее, несмотря на все преимущества, виртуальные машины также имеют и свои недостатки:

Потребность в наличии достаточных аппаратных ресурсов для функционирования нескольких операционных систем одновременно.
Операционная система работает несколько медленнее в виртуальной машине, нежели на «голом железе». Однако, в последнее время показатели производительности гостевых систем значительно приблизились к показателям физических ОС (в пределах одних и тех же ресурсов), и вскоре, за счет улучшения технологий реализации виртуальных машин, производительность гостевых систем практически будет равна реальным.
Существуют методы определения того, что программа запущена в виртуальной машине (в большинстве случаев, производители систем виртуализации сами предоставляют такую возможность). Вирусописатели и распространители вредоносного программного обеспечения, конечно же, в курсе этих методов и в последнее время включают в свои программы функции обнаружения факта запуска в виртуальной машине, при этом никакого ущерба вредоносное ПО гостевой системе не причиняет.
Различные платформы виртуализации пока не поддерживают полную виртуализацию всего аппаратного обеспечения и интерфейсов. В последнее время количество поддерживаемого аппаратного обеспечения стремительно растет у всех производителей платформ виртуализации. Помимо основных устройств компьютера, уже поддерживаются сетевые адаптеры, аудиоконтроллеры, интерфейс USB 2.0, котроллеры портов COM и LPT и приводы CD-ROM. Но хуже всего обстоят дела с виртуализацией видеоадаптеров и поддержкой функций аппаратного ускорения трехмерной графики.

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

Обзор технологии виртуальных машин

Обычно приложения работают в изолированном адресном пространстве и взаимодействуют с оборудованием при помощи API, предоставляемым операционной системой. Если две операционные системы совместимы по своим АРI (например, Windows 98 и Windows 2000), то приложения, разработанные для одной из них, будут работать и на другой. Если две операционные системы несовместимы по своим API (например, Windows 2000 и Linux), то существует способ перехватить обращения приложений к АРI и сымитировать поведение одной операционной системы средствами другой операционной системы. При таком подходе можно поставить одну операционную систему и работать одновременно как с ее приложениями, так и с приложениями другой операционной системы. Поскольку весь код приложения исполняется без эмуляции и лишь вызовы API эмулируются, потеря в производительности незначительная. Но из-за того, что многие приложения используют недокументированные функции API или обращаются к операционной системе в обход API, даже очень хорошие эмуляторы API имеют проблемы совместимости и позволяют запустить не более 70% от общего числа приложений. Кроме того, поддерживать эмуляцию API бурно развивающейся операционной системы (например, такой как Windows) очень нелегко, и большинство эмуляторов АРI так и остаются эмуляторами какой-то конкретной версии операционной системы.

Самый большой минус способа эмуляции API — это его строгая ориентация на конкретную операционную систему. Для того, чтобы запустить в нем приложения другой операционной системы, необходимо все переписывать с нуля.

· проект WINE, позволяющий запускать приложения DOS, Win16 и Win32 под операционными системами Unix/Linux;

· проект с открытым кодом User Mode Linux (UМL), позволяющий запускать несколько копий операционной системы Linux на одном компьютере (встроен в ядро Linux версий 2.6);

· технология, используемая во FreeBSD для запуска приложений Linux. Преимущество такого метода эмуляции, скорость работы. Недостаток, отсутствуют возможности многоплатформенного использования.

История

И системные виртуальные машины, и виртуальные машины процессов относятся к 1960-м годам и продолжают активно развиваться.

Системные виртуальные машины вырос из совместное времяпровождение, как это заметно реализовано в Совместимая система разделения времени (CTSS). Разделение времени позволило нескольким пользователям использовать компьютер одновременно: каждая программа имела полный доступ к машине, но одновременно выполнялась только одна программа, при этом система переключалась между программами во временных срезах, сохраняя и восстанавливая состояние каждый раз. Это превратилось в виртуальные машины, в частности с помощью исследовательских систем IBM: M44 / 44X, который использовал частичная виртуализация, а CP-40 и Симмон, который использовал полная виртуализация, и были ранними примерами гипервизоры. Первой широко доступной архитектурой виртуальных машин была CP-67 / CMS (см. История CP / CMS подробнее)

Важное различие заключалось в использовании нескольких виртуальных машин в одной хост-системе для разделения времени, как в M44 / 44X и CP-40, и использовании одной виртуальной машины в хост-системе для прототипирования, как в SIMMON. Эмуляторы, с аппаратной эмуляцией более ранних систем для совместимости, восходящей к IBM System / 360 в 1963 г., в то время как программная эмуляция (так называемая «симуляция») предшествует ей

Виртуальные машины процессов возникла первоначально как абстрактные платформы для промежуточный язык используется как промежуточное представление программы компилятор; ранние образцы датируются примерно 1966 годом. Примером начала 1966 года был О-код машина, виртуальная машина, которая выполняет О-код (объектный код), излучаемый из BCPL компилятор. Эта абстракция позволила легко перенести компилятор на новую архитектуру за счет реализации нового который взял существующий O-код и скомпилировал его в машинный код для базовой физической машины. В Эйлер язык использовал похожий дизайн, с промежуточным языком, названным п (переносной). Это было популяризировано примерно в 1970 г. Паскаль, особенно в Паскаль-П система (1973) и Паскаль-S компилятор (1975), в котором он был назван p-код и получившаяся машина как машина p-кода. Это оказало влияние, и виртуальные машины в этом смысле часто назывались машинами с p-кодом. Помимо того, что он был промежуточным языком, p-код Pascal также выполнялся напрямую интерпретатором, реализующим виртуальную машину, особенно в UCSD Паскаль (1978); это повлияло на более поздних интерпретаторов, особенно на Виртуальная машина Java (JVM). Другой ранний пример был СНОБОЛ4 (1967), который был написан на языке реализации SNOBOL (SIL), ассемблере для виртуальной машины, который затем был нацелен на физические машины путем переноса на их родной ассемблер через макроассемблер. Однако с тех пор макросы перестали быть популярными, поэтому такой подход оказался менее влиятельным. Виртуальные машины процессов были популярным подходом к внедрению раннего программного обеспечения микрокомпьютеров, включая и приключенческие игры, от разовых реализаций, таких как Пирамида 2000 к двигателю общего назначения, например Инфоком с z-машина, который Грэм Нельсон утверждает, что это «возможно, самая портативная виртуальная машина из когда-либо созданных».

Значительный прогресс произошел во внедрении Болтовня -80,особенно реализация Deutsch / Schiffmannкоторый толкнул своевременная (JIT) компиляция вперед как подход к реализации, использующий виртуальную машину процесса.Позже известные виртуальные машины Smalltalk были VisualWorks, то Виртуальная машина Squeak,и Strongtalk.Родственным языком, который привел к появлению множества инноваций в виртуальных машинах, был Себя язык программирования, который первым адаптивная оптимизация и . Эти методы оказались коммерчески успешными в 1999 г. HotSpot Виртуальная машина Java.Другие нововведения включают наличие виртуальной машины на основе регистров для лучшего соответствия базовому оборудованию, а не виртуальной машины на основе стека, которая больше соответствует языку программирования; в 1995 году это было впервые сделано Виртуальная машина Dis для Лимбо язык. OpenJ9 является альтернативой HotSpot JVM в OpenJDK и представляет собой проект eclipse с открытым исходным кодом, требующий лучшего запуска и меньшего потребления ресурсов по сравнению с HotSpot.

История

На заре развития компьютеры (или ЭВМ, электронно-вычислительные машины) были очень дорогим и штучным инструментом, позволить который могли себе только наиболее крупные институты и предприятия. Вычислительные ресурсы приходилось экономить всеми возможными способами. Первые разработчики писали код в режиме «офлайн» и передавали их оператору ЭВМ, который последовательно вводил программы в машину и производил расчеты. В начале 1960-х годов зародилась концепция разделения времени (time-sharing) – распределение вычислительных ресурсов между несколькими пользователями: пока один вводит данные, машина занимается расчетами других. Первые проекты с поддержкой данной концепции – Compatible Time-Sharing System (CTSS), и предшественница ОС семейства Unix Multics – стали настоящим прорывом, однако они были небезопасными, сложными и, как следствие, не слишком стабильными.

В поисках путей решения проблемы оптимизации использования вычислительных ресурсов командой инженеров IBM был предложен новый подход – в рамках одной ЭВМ предоставить каждому пользователю виртуальную машину со своей ОС. Так в 1964 году появился проект CP-40, который позволил запускать несколько экземпляров клиентских ОС, например CMS. В 1967 году на основе проекта CP-40/CMS появилась CP-67/CMS – многопользовательская операционная система с разделением времени. CP-67/CMS работала на аппаратном мейнфрейме IBM System/360-67 и состояла из двух компонентов:

CP (Control Program)Программа управления виртуализацией (прообраз современного гипервизора).
CMS (Cambridge Monitor System)Одна из наиболее распространенных однопользовательских операционных систем для запуска в виртуальном окружении CP (клиентская, или гостевая, ОС).

Пользователи подключались к гостевым ОС с помощью специальных устройств ввода-вывода – терминалов.

Виртуализация обладала существенными преимуществами над концепцией разделения времени:

Увеличенные надежность и безопасность за счет изоляции пользователей.
Запуск любых приложений (не только приспособленных к концепции разделения времени) за счет симуляции отдельного компьютера для каждого пользователя.
Увеличенная производительность за счет использования легковесных гостевых ОС.

Шло время, компьютеры уменьшались в размерах и дешевели. В 1980-х годах x86 серверы и персональные компьютеры стали доступны для широкого спектра потребителей, вследствие чего мейнфреймы с виртуализацией и терминалами для многопользовательской работы ушли в прошлое. Однако технологии виртуализации продолжали развиваться и решать насущные проблемы. В 1988 году компания Insignia Solutions представила эмулятор программного обеспечения SoftPC, с помощью которого можно было запускать приложения MS DOS на рабочих станциях Unix, что стало своеобразным прорывом. В 1997 году компания Connectix создала программу Virtual PC для запуска под Mac ОС Windows. В 1999 году ныне всемирно известная компания VMware представила VMware Workstation, которая позволила запускать различные ОС в рамках виртуальных машин.

В начале 2000-х годов стали появляться продукты для серверной виртуализации. Эти решения дали возможность запускать несколько изолированных гостевых ОС в виртуальной среде на одном физическом сервере, что упрощало администрирование инфраструктуры, повышало ее отказоустойчивость и снижало простои серверного оборудования. Идея серверной виртуализации быстро набирала популярность. В 2001 году VMware представила ESX Server и GSX Server. В 2003 году Microsoft купила вышеупомянутую Connectix и перезапустила проект Virtual PC, ставший предшественником Microsoft Virtual Server и современного Microsoft Hyper-V). В 2007 году компанией Innotek был представлен VirtualBox. Также в 2007 году на рынок корпоративной виртуализации вышла компания Citrix, которая купила компанию XenSource и начала развивать проект с открытым исходным кодом Xen, предоставляя для клиентов коммерческую версию продукта Citrix XenServer (в настоящее время переименован в Citrix Hypervisor).

Напоследок стоит отметить, что помимо серверной виртуализации появлялись также продукты для виртуализации рабочих столов (новое воплощение той самой связки мейнфрейм-терминал из 1960-70 г.г.), приложений и др. Многие из этих решений активно развиваются и сегодня.

Читать подробнее:

1.3.1. Абстракция и виртуализация

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

Абстракция и виртуализация в применение к дисковой памяти.

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

Концепция архитектуры системы команд компьютера (instruction set architecture, ISA) наглядно иллюстрирует преимущества хорошо определенных интерфейсов. Они позволяют разрабатывать взаимодействующие компьютерные подсистемы не только в разных организациях, но и в разные периоды, иногда разделенные годами. Например, Intel и AMD создают микропроцессоры с системой команд IA-32 (x86), в то время как разработчики Microsoft пишут программное обеспечение, которое компилируется в эту систему команд. Поскольку обе стороны соблюдают спецификацию ISA, можно ожидать, что программное обеспечение будет правильно выполняться любым ПК на базе микропроцессора с архитектурой IA-32.

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

Виртуализация позволяет обойти эту несовместимость. Виртуализация системы или компонента (например, процессора, памяти или устройства ввода/вывода) на конкретном уровне абстракции отображает его интерфейс и видимые ресурсы на интерфейс и ресурсы реальной системы. Следовательно, реальная система выступает в роли другой, виртуальной системы или даже нескольких виртуальных систем.

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

Использованная литература.

http://www.opennet.ru/
http://www.ixbt.com/
http://www.osp.ru/

Литература:

Алексей Гультяев — Виртуальные машины. Несколько компьютеров в одном (+ CD-ROM)

Судебный прецедент как источник международного гражданского процесса (Судебный прецедент в различных правовых семьях)
Административный порядок защиты прав потребителей
Понятие, цели, задачи и значение оценки бизнеса
Понятие, цели, задачи, значение оценки бизнеса
Договор аренды
Функции управляющей компании
Воинская преступность (Понятие воинского преступления)
Трудовой договор. Понятие и содержание (Трудовой договор)
Имущественные потери
Механизм преступного поведения
Правовые аспекты защиты права на средства индивидуализации в международном частном праве
Виртуальные машины и их возможности. (Виртуальные машины в целом)

Настройка виртуальной архитектуры NUMA

Вы можете настраивать и развертывать виртуальную архитектуру NUMA, а также управлять ею в VMM. Виртуальная архитектура NUMA имеет перечисленные ниже свойства.

NUMA — это архитектура, используемая в многопроцессорных системах. Скорость доступа процессора к памяти зависит от местоположения памяти по отношению к процессору. В системе NUMA процессор может получить доступ к локальной памяти (память, которая относится непосредственно к этому процессору) быстрее, чем к удаленной (памяти, которая является локальной для другого процессора в системе). NUMA пытается ликвидировать разрыв между скоростью процессоров и используемой ими памяти. Для этого NUMA предоставляет отдельную память по принципу «на процессор», позволяя избежать снижения производительности, которое возникает при доступе нескольких процессоров к одной и той же памяти. Каждый блок выделенной памяти называется узлом NUMA.
Виртуальная архитектура NUMA позволяет развертывать большое количество крупных и критически важных рабочих нагрузок, выполняемых в виртуализованной среде с минимальным снижением производительности, по сравнению с работой невиртуализованных компьютеров с физическим оборудованием NUMA. При создании виртуальной машины Hyper-V по умолчанию использует значения для гостевых параметров, синхронизированных с топологией узла NUMA Hyper-V. Например, если узел имеет 16 ядер, 64 ГБ распределены поровну между двумя узлами NUMA и на каждое гнездо физического процессора приходится два узла NUMA, то параметру «Максимум процессоров на узел» создаваемой на узле с 16 виртуальными процессорами виртуальной машины будет задано значение 8, параметру «Максимум узлов на гнездо» — значение 2 и параметру «Максимум памяти на узел» — значение 32 ГБ.
Можно включить или отключить функцию охвата NUMA. Если охват включен, отдельным виртуальным узлам NUMA можно выделить нелокальную память и администратор может развернуть виртуальную машину, количество виртуальных процессоров на виртуальный узел которой превышает количество процессоров, доступных в базовом аппаратном узле NUMA в узле Hyper-V. Охват NUMA для виртуальных машин приводит к дополнительным затратам на производительность, поскольку виртуальная машина обращается к памяти на удаленных узлах NUMA.

Чтобы настроить виртуальную архитектуру NUMA для виртуальных машин, выполните указанные ниже действия.

Добавление виртуального адаптера к виртуальной машине

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

Обратите внимание на следующее

Для добавления новых виртуальных сетевых адаптеров нужно создать или изменить аппаратный профиль VMM.
Эта функция доступна только для виртуальных машин версии 2.
По умолчанию добавляемые виртуальные сетевые адаптеры не подключены к виртуальной сети. В виртуальных машинах, которым назначен аппаратный профиль, можно настроить использование одного виртуального сетевого адаптера (или нескольких) после развертывания на узле.

В свойствах виртуальной машины щелкните Конфигурация оборудования, Сетевые адаптеры и выберите добавляемый сетевой адаптер.
Можно настроить несколько свойств для сетевого адаптера, включая следующие:
- Подключен к: выберите, к чему подключен адаптер.
- Не подключен: выберите этот вариант, если не желаете указывать сеть.
- Внутренняя сеть: выберите, если требуется подключиться к изолированной внутренней сети, которая позволяет виртуальным машинам взаимодействовать между собой в рамках одного узла. Виртуальные машины, подключенные к внутренней виртуальной сети, не могут взаимодействовать с узлом, с любыми другими физическими компьютерами в локальной сети узла или с ресурсами в Интернете.
- Внешняя сеть: выберите этот вариант, чтобы указать, что виртуальная машина, созданная с использованием этого аппаратного профиля, будет подключена к физическому сетевому адаптеру на данном узле. Виртуальные машины, подключенные к физическому сетевому адаптеру, могут взаимодействовать с любым физическим или виртуальным компьютером, с которым может взаимодействовать узел, а также с любыми ресурсами, доступными в интрасети и по Интернету, к которым у главного компьютера есть доступ.
- Адрес Ethernet (MAC): виртуальный MAC-адрес на виртуальных машинах, который однозначно обозначает каждый компьютер в одной подсети. Выберите один из следующих вариантов.
- Динамический. Выберите этот параметр, если хотите включить динамические MAC-адреса для виртуальной машины.
- Статический. Выберите этот параметр, если хотите включить статические MAC-адреса для виртуальной машины. Введите статический MAC-адрес в отведенном для этого поле.
- Режим магистрали: выберите этот параметр, чтобы включить магистральный режим.

VMM 2019 UR3 и более поздних версий поддерживает магистральный режим для виртуальных сетевых адаптеров виртуальной машины.

Заключение.

В заключение скажу, что среди описанных автором виртуальных машин, лидером среди эмуляторов, безусловно, является VMware Workstation. В отличие от того же Virtual PC VMware поддерживает не только Windows. Если сравнивать VMware с Sun Virtualbox, то стоит сказать, что они в скором времени могут стать одним из главных конкурентов VMware, у них ещё всё впереди. А пока советую вам использовать именно Sun Virtualbox для изучения и тестирования, она понятна и удобна, имеет достаточное количество функций, которые могут пригодиться вам в изучении. А так же, её главный плюс — бесплатность.

Во избежание недоразумений скажу вам, что виртуальная машина практически ничем не отличается от реальной машины. И то, что какая-либо программа, использованная на виртуальной машине, будет вести себя иначе, чем на реальной машине – ошибочное мнение.