Tails – VirtualBox – USB-флэшка

Я этот вариант и не подразумевал. Имелось в виду, что Tails будет хостовой ОС, в нём будет запущена виртуалка, в виртуалке в качестве гостевой ОС ещё какая-то из вам нужных, как-то так. Я вас так понял.

Трукрипт и виртуалка установлены на основной ОС – не знаю правильно это или нет..

Эту информацию куда приделать?

Я думал о возможности их установки на ту же флэшку где расположена Tails...

Это ещё можно так понять, что на флэшку вы хотите поставить: портабл-версию TrueCrypt, портабл-версию виртуалки и ещё Tails. Но вы не можете сами себя из болота вытянуть: как полностью зашифровать флэшку через TrueCrypt при том, что TrueCrypt будет находиться на ней же? Если не скрывать наличие TrueCrypt'а на ней, то можно выделить два раздела, в одном будет TC установленный, второй будет этим TC'ом шифроваться. В шифрованный раздел можно положить как портабл-версию виртуалки, так и образ Tails. Впрочем, хорошие виртуалки (гипервизоры, они работают быстро), так не настраиваются, поскольку должны стартовать ещё до стадии загрузки (хостовой) ОС.

Тем неменее, вы предполагаете что товарищ имеет ввиду ).
Может он хочет записать tails на зашифрованный раздел, а может разместить образ, а может разместить папку вирт машины с образом и носителями вирт машины. Может он хочет разместить туда portable версии truecrypt и virtualbox, а может и использовать на основной системе (хосте). Может хочет запускать флеш с tails в вирт машине, а может хочет создать вирт машину tails.
Вот и приходится гадать, что же он хочет.

Что есть «виртуальная машина "Tails"»?

Virtualbox – Создать вирт машину – Вводим имя, Тип-Linux, Версия-Debian32 – Указываем объем памяти – Не подключать вирт жд (можно создать, но смысл).
Вирт машина создана.
Заходим в настройки машины:
1. Система – Материнская плата – Порядок загрузки – Поднимаем СД/ДВД вверх (с остального снимаем галки).
2. Носители – Контроллер IDE – Выбираем образ Tails.
3. Сеть – Nat

Больше настраивать ничего не надо.
Виртуальная машина создана. Можно запускать.

Это такая виндовая терминология? То, что вы называете виртуальной машиной, назвают гостевой ОС. Сама «виртуальная машина», «виртуалка» полностью отвязана от конкретики — это нечто третье (в случае производительных виртуалок), так называемый гипервизор, который запускается на голом железе. Потом гипервизор загружает ядро хостовой ОС, после чего грузится сама хостовая ОС, имеющая права на управление как гипервизором, так и гостевыми ОС. Внутри хостовой ОС можно создавать iso-файлы/образы или иные загрузочные разделы/носители, которые потом могут быть загружены (командами внутри хостовой ОС) как гостевые ОС.

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

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

Да нет. Это такая терминология самого софта. Если использовать термины "хостовая система" и "гостевая система", то не искушенный пользователь может путаться и неправильно формулировать мысли.
Зайдите в сабж и посмотрите. Только из этих соображений был написан алгоритм таким "языком".
Лично я пользуюсь гипервизорами более 10 лет и терминологию знаю.

Это вы сейчас о xen? Но большая часть программного обеспечения все-таки ставится на хост.

Есть такой термин, «bare-metal hypervisor» [1], [2], термин из википедии:

Type-1: native or bare-metal hypervisors

These hypervisors run directly on the host's hardware to control the hardware and to manage guest operating systems. For this reason, they are sometimes called bare metal hypervisors. A guest operating system runs as a process on the host.

Modern equivalents include Oracle VM Server for SPARC, Oracle VM Server for x86, the Citrix XenServer, VMware ESX/ESXi and Microsoft Hyper-V 2008/2012.

However, the distinction between these two types is not necessarily clear. Linux's Kernel-based Virtual Machine (KVM) and FreeBSD's bhyve are kernel modules that effectively convert the host operating system to a type-1 hypervisor. Nevertheless, since Linux distributions and FreeBSD are still general-purpose operating systems, with other applications competing for VM resources, KVM and bhyve can also be categorized as type-2 hypervisors.

Здесь это тоже вскольз упоминалось. Короче, терминология не Xen-специфичная, а специфичная, как минимум, для всех гипервизоров первого типа, к которым относится не только Xen.


Это уже как настроите. Например, в мануалах по настройке Xen продвигалась мысль, что хостовая ОС должна использоваться только для того, чтобы рулить ресурсами для гостевых и сетью. На хостингах оно так и происходит. В принципе, если видеокарту и звуковую пробросить в гостевую ОС через PCI pass through, а загрузку гостевой ОС сделать автоматической при старте хостовой, можно после загрузки машины сразу логиниться в некоторую гостевую и из неё управлять всем (ssh на хостовую, и оттуда рулить всем остальным; звук и видео будет работать; сеть — как настроим; что ещё нужно?).

Да все так, но понятно что выбор гипервизора и способ его использования обусловлен тем, какие задачи решаются. Администрирование, тестирование, сетевое решение, игры и т.д. причем в рамках предприятия или персонального использования. Очень важный критерий при выборе – какие гостевые ОС поддерживаются в гипервизоре.
https://ru.wikipedia.org/wiki/.....ие_виртуальных_машин

То она будет нести информацию о существующем железе. Хорошо ли это? Опять что важнее анонимность или функционал. Какие задачи, такие и решения.

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

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

СПАСИБО всем за советы, вопрос с Вашей помощью решен, Спасибо за просветления)

Другими словами, если Xen не поддерживает Win, то ее все равно можно запихать в domU? Речь идет о возможностях по-умолчанию, а не через костыли. Решить подобную задачу удалось, то что на слуху, только Рутковской. В инете, лично я, встретил только одну статью на тему как запихать в xen win, но описание такое, что нужен хороший багаж знаний если пойдет что не так (иными словами не настолько подробная).

Ну если тестирование, то разницы нет, если поиграть – тоже. Коли важна анонимность – важно.

Да, через HVM:

Virtualization hardware extensions are used to boost performance of the emulation. Fully virtualized guests do not require any kernel support. This means that Windows operating systems can be used as a Xen Project HVM guest. Fully virtualized guests are usually slower than paravirtualized guests, because of the required emulation.

Лень гуглить, но вот тут упоминалось, что в винде даже паравиртуализацию пилят:

паравиртуализация в юнихах есть уже тринадцать лет хрен знает сколько лет, а в винде нет (недопиленные поделки и развивающиеся идеи/проекты пока не в счёт)

Не знаю статус винды в паравиртуализации, но через HVM должно работать.