LINUX.ORG.RU

Принципы работы kvm и qemu

 , , , ,


3

4

Добрый день! Знает ли кто-нибудь как организована память в kvm? Сохраняют ли гостевые ос какие-либо данные в свопе хост-машины или только в своем свопе? Здесь http://www.ibm.com/developerworks/ru/library/l-linux-kvm/сказано, что каждый гость это отдельный физический процесс хосте-машины. Где же тогда изоляция виртуальной и реальной среды???

каждый гость это отдельный физический процесс хосте-машины

а как еще может быть?

uspen ★★★★★
()
Ответ на: комментарий от uspen

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

IvanIvan
() автор топика

каждый гость это отдельный физический процесс хосте-машины. Где же тогда изоляция виртуальной и реальной среды???

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

Сохраняют ли гостевые ос какие-либо данные в свопе хост-машины или только в своем свопе?

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

dyasny ★★★★★
()

Да, гостевая ОС - отдельный процесс. Почему беспокоит именно своп? Если есть доступ к хосту - есть доступ ко всей его памяти. Пока что нет виртуалок/гипервизоров, которые можно было бы запускать на скомпрометированном хосте. Научные работы в эту сторону, хоть и медленно, но ведутся: Опубликованы исходные коды HElib

alt-x ★★★★★
()
Ответ на: комментарий от alt-x

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

Вот я и хочу узнать имеет ли смысл отключать своп только в ВМ или и на хосте нужно?

IvanIvan
() автор топика
Ответ на: комментарий от IvanIvan

Цель ограничить все возможные утечки информации с гостя на физическую ОС (на жесткий диск, в частности из-за свопа).

С хоста на гостя? А какой смысл? Рут на хосте может снять полный образ памяти виртуалки.

tailgunner ★★★★★
()
Ответ на: комментарий от IvanIvan

Можно и не отключать. Можно зашифровать. И сказать посредством madvise на хосте, чтобы процессы qemu/kvm высвопывались в последнюю очередь.

alt-x ★★★★★
()
Ответ на: комментарий от tailgunner

С хоста на гостя? А какой смысл? Рут на хосте может снять полный образ памяти виртуалки.

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

alt-x ★★★★★
()
Ответ на: комментарий от alt-x

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

Ну, может речь о данных, которые обрабатываются чисто в памяти b не сохраняются на диск. Но всё равно желание странное.

tailgunner ★★★★★
()
Ответ на: комментарий от IvanIvan

тебе Xen подойдёт для этого или какой-нить экзотический lynxsecure или что-то в этом духе http://www.ghs.com/products/rtos/integrity_virtualization.html

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

dimon555 ★★★★★
()
Ответ на: комментарий от alt-x

Образы можно шифровать. Проблема именно с памятью и с ее выгрузкой на физический жд как процесса основной ОС.

Цель: гость выключается->удаляется все,что было о нем из озу и свопа.

IvanIvan
() автор топика

KVM обеспечивает виртуализацию памяти с помощью /dev/kvm. Каждая гостевая операционная система имеет свое собственное адресное пространство, которое устанавливается, когда создается гостевая система.

Физическая память, которая назначается для гостевой операционной системы, является в действительности виртуальной памятью процесса.

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

Получается озу для kvm - своп физической ОС???

IvanIvan
() автор топика
Ответ на: комментарий от val-amart

Спасибо за совет, не поверишь, я представляю что это такое))

В процитированном написано так...

IvanIvan
() автор топика
Ответ на: комментарий от dimon555

Xen не подойдет,там Linux в dom0, а нужна чистая хост машина,т.е. гипервизор поверх физ. ос.

IvanIvan
() автор топика
Ответ на: комментарий от IvanIvan

Про madvise я ошибся, его недостаточно. Можно использовать mlock (http://linux.die.net/man/2/mlock), но с таким подходом легче выключить своп. Ещё можно попробовать как тут советуют http://unix.stackexchange.com/questions/10214/per-process-swapiness-for-linux

Что до шифрования - вот пример для убунты http://iwtf.net/2010/01/05/encrypting-your-ubuntu-swap-partition/

Ну, или можно зашифровать все разделы на хосте и использовать своп-файл на одном из них вместо раздела.

alt-x ★★★★★
()
Ответ на: комментарий от IvanIvan

Получается озу для kvm - своп физической ОС???

Нет. Получается озу для kvm - это в том числе и своп физической ОС.

alt-x ★★★★★
()
Ответ на: комментарий от alt-x

mlock было бы хорошим стандартным решением, но наверно проблемно будет найти начальный адрес, длину в памяти. mlockall с флагом MCL_CURRENT подошло бы - блокирует своппинг вызвавшего процесса,но как проникнуть в процесс гостя, перекомпилировать kvm если только.

Спасибо за ссылку, поизучаю этот способ

IvanIvan
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.