Продвинутые возможности систем виртуализации

Т. е. KVM в таком случае не работает? Тогда softmmu.

в xen будет сложно сделать снапшот. говорю «сложно» только потому, что уверен, что это нереально всего на 99 процентов.

xen будет сложно сделать снапшот

а в чем там сложность, если хранилище всех виртуалок кластера будет на san-e с zfs или lvm на борту?

Образ диска виртуальной машины - «черный ящик», открывающийся только изнутри, файловая система на нём зашифрована, на хостовой системе никакие ключи для расшифровки не содержатся, расшифровать может только загрузчик операционной системы, установленной на ВМ. И какой снапшот тут поможет?
А вообще тема шифрования стала уж слишком модна среди it-шников, на форумах все себя мнят великими криптопреступниками, криптошпионами и криптополицейскими. А с чего вы вообще решили, что данная схема с удалёнкой «винда — винда вм с хостовой системой Linux» может использоваться только для того, чтобы чего-то скрывать. Схема довольно часто применимая, может её используют для защиты от несанкционированных действий самих сотрудников или для повышения надёжности. И почему только RDP? VNC-доступ не заработает? Если libvirt позволяет настроить VNC-доступ, я разве не смогу подключаться к ВМ через какой-нибудь виндовый клиент, VNC Viewer например.

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

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

Образ диска виртуальной машины - «черный ящик», открывающийся только изнутри, файловая система на нём зашифрована, на хостовой системе никакие ключи для расшифровки не содержатся, расшифровать может только загрузчик операционной системы, установленной на ВМ. И какой снапшот тут поможет?

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

запускаешь ты виртуалку, вводишь пароля для рассшифровки и последующего монтирования ФС. Все после этого фс внутри вм смонтирована, и все твои данные доступны руту локалхоста на котором крутится виртуалка.

Или ты придумал способ в котором обычный юзер системы способен спрятать файлы от рута?

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

и вообще

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

т.е. ты арендуешь виртуалку, чтобы поставить виртуалку, чтобы в неё поставить побольше виртуалок, на которых будут виртуалки или контейнеры?

боюсь, что даже в этом случае стащить рандомный контейнер не выйдет.

Схема довольно часто применимая

да часто применяемая, но совсем не для защиты от несанкционированных действий

т.е. ты арендуешь виртуалку, чтобы поставить виртуалку, чтобы в неё поставить побольше виртуалок, на которых будут виртуалки или контейнеры?

что за поток сознания вникуда, речь о том что скрыть данные в вирталке от админов виртуалочного хостинга НЕВОЗМОЖНО.

расшифровать может только загрузчик операционной системы

вот этот момент освети, так понимаю, что ключики будут внутри ВМ? тогда какой от них смысл? Если ты не вводишь пароли на рассшифровку ФС при старте системы, то любой админ может копирнуть твой образ, контейнер, том и запустить где угодно, а так называемый «загрузчик» все расшифрует ведь ключики никуда из виртуалки не денутся.

это не поток сознания, это реакция на твой раскаленный поток паранойи через днище. ты всё никак не поймешь, что слово «невозможно» неприменимо в данном контексте.

Ну расскажи как ты сделаешь недоступными данные в виртуалке для рута локалхоста на котором она запущена?

вот этот момент освети, так понимаю, что ключики будут внутри ВМ? тогда какой от них смысл?

Ты понимаешь ведь, что физический доступ к компьютеру != доступ к данным на нём. То же самое касается и контейнеров. truecript позволяет зашифровать том так, что он останется загрузочным, винда будет с него грузиться, а со стороны хостовой системы он будет оставаться «черным ящиком». А хостовая система просто предоставляет ресурсы для запуска виртуалки и ничего более и пробрасывает на виртуалку порты, чтобы удалённый пользователь мог к ней подключаться. То есть, что удаленный пользователь там делает для хостовой системы остаётся полностью невидимым.
Кстати, а «виртуалка на виртуалке», что... взлетит? То есть я могу купить VPS, поставить на него виртуалку и заработает?

физический доступ к компьютеру != доступ к данным

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

Ну если мы просто теоретизируем - то да, может, только для этого сильно раскорячиться нужно. Допустим юзер раз в день в начале рабочего дня осуществляет подключение к ВМ. В этот момент какую-то долю секунды ключ в явном виде появляется в оперативной памяти хостовой системы. Чтобы получить доступ к данным юзера админу хостинга требуются «сущие пустяки»: написать анализатор памяти и поймать тот самый момент.

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

написать анализатор памяти и поймать тот самый момент.

накой ему момент ловить, он тупо привяжет выполнение этого скрипта к определенному моменту в системе - запуску твоей ВМ, но только это не нужно.

ответь мне на два вопроса (считаем, что под вм используется файл-образ):

1. ты будешь шифровать том или фс на которой будет расположен образ вм или же будешь шифровать ФС внутри образа?

2. доступ к твоим зашифрованным сущностям будет по ключам или по паролям?

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

уже какирский план продумываешь? оба ответа совсем пофигу, потому что изначальный твой посыл был «вы, клоуны, хоть обшифруйтесь, чувак из дц вас поимеет при любых раскладах»

а ничего что при таком раскладе эти данные доступны третьим лицам, админам датацентра?

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

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

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

Чувачок ты поделу хоть раз бы ответил.

хоть обшифруйтесь, чувак из дц вас поимеет при любых раскладах

100%

вы, клоуны

а вот оскорблять людей не надо!

если твой единственный аргумент - то что «они там все руты на моей тачке», то никак, конечно.

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

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

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

Вот кстати да, изначально задача ставилась так, что сервер компании размещён в датацентре http://www.linux.org.ru/forum/admin/11681144?cid=11684286 (комментарий)

То есть нужно сначала получить доступ к нему, а только потом к запущенной на нём виртуалке. Даже если диски на сервере не зашифрованы первое действие потребует от админов некоторых усилий - нужно будет перезагружать сервер, изменять его конфигурацию, админ фирмы наверняка факт подобного вмешательства просечёт и откатит внесённые изменения либо вообще перестанет пользоваться данным сервисом. Если диски на сервере зашифрованы - то админы будут видеть только черный ящик к которому идёт шифрованный трафик. Но ладно, допустим root-доступ к серверу админы получили, что дальше? Нужно проникнуть внутрь виртуалки. Она также зашифрована, но поскольку к ней организован RDP/VNC-доступ, не исключено что к этому RDP можно подключиться не только удалённо, но и локально, то есть да, админы как бы смогут увидеть конфиденциальный рабочий стол.

теоретег, почитай здесь - Можно ли скрыть информацию, хранящуюся на VDS/VPS от администратора хостинга?

желание предоставить в доступ третьим лицам важную комерческую инфу еще осталось?

шел 2015-й год, всего лишь 100% серверов умели VT/AMD-V, но на ЛОР-е все еще считалось уместным обсуждать их отсутствие

так о том и речь, мы и о VB говорим.

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

Я тут короче от теории перешёл к практике с QEMU-KVM и libvirt. Только я немного запутался.

Я вижу, что в пакете qemu есть множество эмуляторов: qemu-x86_64, qemu-system-x86_64, qemu-kvm. Мне я так понимаю нужен qemu-kvm, который будет эффективно использовать ресурсы, используя мощь модулей ядра kvm.ko и kvm-amd.ko. Но мне нужно написать скрипт, который будет модпробать эти могули и запускать эмулятор со кучей параметров, такие как тип процессора, память, образ диска, конфигурация сети. Я так понимаю утилиты libvirt: virsh и virt-install нужны как раз для того, чтобы этот скрипт не писать, они обеспечивают автоматизацию. Или для чего-то ещё?
А вот как с утилитами libvirt работать я не разобрался.
Запускаю ВМ:

iskatel@iskatel-dsk:~$ virsh -c qemu:///system start virtual1
Домен virtual1 запущен

Домен это просто виртуальная машина, насколько я знаю.

И в каком каталоге хранятся настройки виртуальных машин

/etc/libvirt/qemu/

И как мне изменить конфигурацию виртуальной машины

virsh edit vmname, или в гуйне через virt-manager.

что значит «домен»

имя виртуалки и его конфига

в каком каталоге хранятся

ls /etc/libvirt/qemu/

как мне изменить конфигурацию виртуальной машины

тупо редактируешь xml-конфиг машины и пересоздаешь ее, типа так:

nano /etc/libvirt/qemu/vm2.xml
virsh create /etc/libvirt/qemu/vm2.xml

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

да все уже есть

virt-install -n vm2 -r 1024 --vcpus=1 --disk path=/kvmpool/vm2/vm2.raw,bus=virtio,cache=writeback --vnc --os-type linux --accelerate --network=bridge:br0,model=virtio --hvm -c /kvmpool/data/debian-7.2.0-amd64-DVD-1.iso

и забудь о шифрование вм, это фуфел и бессмысленная нагрузка на железо.

Возник вопрос про ещё одну продвинутую возможность.
Когда игрался в wmware и virtualbox там в составе пакета шёл iso-образ с расширениями для гостевой винды, ставишь их и можешь окно программы, запущенной в винде, переносить на рабочий стол linux. В qemu-kvm такая плюшка есть? Я сейчас использую libvirt + virt-manager с доступом через окно virt-manager по spice или vnc (разницы не заметил).