Виртуализация ввода-вывода

После рассмотрения виртуализации и памяти настал черед рассмотрения виртуализации ввода-вывода. Обычно гостевая операционная система при запуске начинает исследовать оборудование с целью определения типов подключенных устройств ввода-вывода.
Эти исследования будут вызывать системные прерывания с передачей управления гипервизору. А что должен сделать гипервизор? Он может послать в ответ отчет о тех дисках, принтерах и т. д., которые действительно входят в состав оборудования. Затем гостевая операционная система загружает драйверы для этих устройств и пытается ими воспользоваться. Когда драйверы устройств пытаются осуществить настоящий ввод-вывод, они считываются в аппаратные регистры устройства и ведут в них запись. Инструкции для выполнения этих действий являются служебными и приводят к передаче управления гипервизору, который затем может по мере надобности копировать необходимые значения в аппаратные регистры и обратно.

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

Возможно также, что диск, используемый гостевой операционной системой, будет отличаться от реального диска. Например, если реальный диск относится к дискам нового, высокопроизводительного типа (или является RAID-массивом) с новым интерфейсом, гипервизор может информировать гостевую операционную систему, что у него имеется обычный старый IDE-диск, и позволить гостевой операционной системе установить драйвер IDE-диска. Когда этот драйвер выдает команды управления IDE-диском, гипервизор преобразует их в команды управления новым диском. Эта стратегия может использоваться для обновления оборудования без изменения программного обеспечения. Фактически такая способность виртуальных машин переназначать аппаратные устройства была одной из причин приобретения популярности VM/370: компании хотели покупать новое и более быстродействующее оборудование, но не хотели вносить изменения в свое программное обеспечение. Технология виртуальных машин предоставляет такую возможность.

Еще одна интересная тенденция, связанная с вводом-выводом, заключается в том, что гипервизор может сыграть роль виртуального коммутатора. В этом случае у каждой виртуальной машины имеется MAC-адрес и гипервизор переключает фреймы от одной виртуальной машины к другой точно так же, как это делал бы Ethemet-коммутатор. Виртуальные коммутаторы имеют ряд преимуществ. Например, их очень просто переконфигурировать. Также можно расширить коммутатор, придав ему дополнительные функциональные возможности, например, для обеспечения дополнительной безопасности.

7.7.1.

<< | >>
Источник: Э. ТАНЕНБАУМ Х. БОС. СОВРЕМЕННЫЕ ОПЕРАЦИОННЫЕ СИСТЕМ Ы 4-е ИЗДАНИЕ. 2015

Еще по теме Виртуализация ввода-вывода:

  1. § 37 История вотчинной записки в России. – Явка актов в приказах. – Справка. – Юридическое и финансовое ее значение. – Аналогия нашей формы с западными. – Изменение старой формы при Петре I. – Новый крепостной порядок и новое значение справки и отказа. – Форма нового отказа и ввода во владение
  2. Выводы
  3. Выводы
  4. Выводы
  5. Выводы
  6. 7. Выводы, основанные на эмоциях
  7. 2.4.3. Выводы
  8. Выводы
  9. Выводы
  10. Выводы
  11. Выводы
  12. Выводы