#

1) Объективная реальность - сейчас 100 гигов под системный раздел мало. Если конечно это не специализированное рабочее место с очень узким набором задач. А на обычном компе "широкого профиля" - мало! Сейчас Вы эти гигабайты, как я понял, нашли. Но через месяц опять будете искать место. Нужно хотя бы раза в два больше.
2) Судя по уголку скриншота в вопросе, C и D у Вас - это разделы на одном физическом диске. Дробить диск на такие мелкие разделы нет никакого смысла. Я бы их объединил и спал спокойно!

Использовать xvfb (X virtual frame buffer). Устанавливаешь одноименный пакет, настраиваешь его запуск, используешь. Таких серверов может быть запущено несколько, но rustdesk может этого не ожидать (я сильно не копал но обычно если запустить rustdesk приложение с установленным DESKTOP на нужную тебе сессию, для нее он и запустится)

p.s. linux + xvfb + rustdesk это худший способ настройки удаленного подключения
Рекомендую x2go, сервер все сам настроит, а клиенты есть по до все. Работает на порядок эффективнее (плавнее и менее требовательный к сетевому каналу).
Для игр не подходит.

Acronis True Image, да и в принципе любая программа клонирования позволяет выбирать настройки целевого диска: либо точь-в-точь либо пропорциональное увеличение/уменьшение разделов.
Ну либо True Image склонировать, а потом Disk Director или тем же виндовым диспетчером дисков расширить на весь объем.

Проброс устройств в виртуальную машину бывает разный, в зависимости от вида подключения, самого устройства, действия могут отличаться от 'вставил и работает' (очень и очень редко) до 'работает только если звезда сойдутся и если запускать заранее подготовленный непростой набор команд перед вставкой устройства и после'.

Причина - нет адекватной поддержки проброса устройств, чаще всего она ограничена либо работает только при опредленных условиях и по разному на разных устройствах (в смысле компьютер), зависит от производителя процессора intel/amd, возможностей материнки и кучи других мелких нюансов (например десктопные материнки чаще всего ограничивают функционал в биосе). С момента активного использованиея EFI биосов, это еще сильнее усложнилось.

* Итак - проброс всего pci(-e) устройства вместе с контроллерами и соответственно устройствами, через него подключаемыми. Это самый удобный с точки зрения использования способ (потому как после запуска виртуальной машины контроллер уже доступен внутри и чаще всего без дополнительных движений видит устройство 'как родное'.

В linux мне известно что это поддерживает только qemu/kvm и поддержка требует соответствующие аппаратные возможности (IOMMU/VT-d плюс в принципе аппаратная виртуализация), даже некоторые gpu могут быть так проброшены внутрь виртуалки, производители видеокарт об этом знают и старательно ставят палки в колеса, так как такой функционал они хотят чтобы пользователи использовали только с их 10х дороже серверными вариантами видеокарт). Требует хорошего прогружения в настройки linux, хотя бы чтобы исключить инициализацию устройство самим linux (некоторые устройства не любят включаться два раза подряд без железной перезагрузки).

* Промежуточный вариант - проброс USB устройств. Это установка в гостевой операционной системе специального драйвера USB который по сети или каким-либо другим способом (например virtualbox usb при установке проприетарного guest additions) транслирует весь трафик, включая управляющий с хост машины для выбранного usb устройства или контроллера. Точно помню отдельные приложения для трансляции usb по сети между машинами даже без виртуализации, но лично сам не пользовался, гуглите решения обычно платные.

* Проброс 'блочного устройства' (читай дисков или отдельных разделов, и даже файлов), в этом случае гостевая ос не имеет доступа к самому устройству, но только к данным на нем. Формально это просто подключение диска из файла (потому как даже в windows диск и раздел это буквально файл, который можно открыть fopen по специальному имени). Разные системы виртуализации дают разный интерфейс и удобство. qemu с тем же libvirt - удобнее чем к примеру virtualbox (там нужно в консоли специальную 'скрытую' команду использовать)

p.s. Проброс видеоускорителя - есть еще протоколы spice но на сколько я знаю они не достаточно функциональны
Ну и проброс всякой мелочовки типа клавиатура, мышь, планшет/сенсорный экран, мониторы. Это все виртуальные сущности, реальное железо тут не пробрасывается.

p.p.s. драйвера windows для гостевых систем с каждым разом становятся все хуже и хуже, если я верно понял палки в колеса вставляет сама майкрософт, например windows 10 адекватно в virtualbox уже не работает gpu без глюков (я обхожу большинство проблем только с помощью rdp подключения)

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

P.S. надеюсь, в качестве гипервизора вы используете Qemu-KVM, а не богомерзкий VB.

P.P.S. мне-то на практике приходилось пробрасывать только аппаратный USB-ключ,
а вот есть человек Денис _______________ - он собаку съел на пробросе в виртуалку даже видеокарты (и статья на Хабре есть https://habr.com/ru/articles/575654/ https://habr.com/ru/articles/448312/ ). Это к тому, что при необходимости можно не только USB-устройства пробросить, но и PCI-устройства.

Диск неисправен или неверно подключён.

Я отправил запрос на pull (пулл-запрос) по адресу https://github.com/Zakarayaev/avproj1/pull/1. На основе вашего решения, я внес изменения, которые вы хотели бы видеть. Я надеюсь, что вы сможете разобраться с изменениями самостоятельно.

Также прилагаю свой репозиторий с переделанным проектом. Вы можете найти его по адресу https://github.com/namenavi/avproj1. Если не сложно, отметьте этот ответ как принятый.

Помимо пароля на архив вы можете указать опцию "Создать непрерывный архив", чтобы исключить возможность подобрать ключ по известному содержанию файла. Например, вы добавите в архив какой-нибудь readme файл от известной программной библиотеки, если он будет зашифрован отдельно от бинарного потока архива, то есть возможность подбирать ключ по заранее известному содержимому этого файла.
Также стоит зашифровать имена файлов, чтобы исключить в принципе анализ на известное содержимое.
Потеря тома никак не влияет на безопасность расшифровки архива - она влияет на невозможность расшифровать архив тому, кто имеет корректный ключ. Чтобы подстраховаться, добавляют информацию для восстановления, но ее может быть недостаточно при полной потере тома.