Почему гостевая ОС сильно замедлилась после полугода "простоя"?

Не думаю. Если бы было так, то за полчаса всё бы точно обновилось и перестало тормозить, но этого не произошло. У меня быстрый интернет.
Да и обновляться там, наверное, особо не чему. Это же свежеустановленная гостевая Ubuntu и всего 5-10 дополнительно мною установленных небольших программ по типу браузера, редактора кода, программы для скриншотов и тд.
И это при том, что, при установке ОС, в стандартном установочном меню выбирал "кастомный" вариант - без предустановленных пакетов типа офиса и игр. А после установки увидел, что какой-то лишний софт всё же был добавлен автоматически - ну и почистил его.

Какой гипервизор (на базе основной ОС, а не автономный) из популярных (VirtualBox, VMWare и др) больше подходит для бэкенд разработки и тестирования?

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

Какой гипервизор (на базе основной ОС, а не автономный) из популярных (VirtualBox, VMWare и др) больше подходит для бэкенд разработки и тестирования?

Ziptar,

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

А если планируется в будущем перейти на хостовую Ubuntu и перенести туда все бэкапы в ova-файлах, то виртуалбокс будет так же лучше других гипервизоров?

виртуалбокс всегда считался "любительским" решением, популярным у "народа"

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

Какой гипервизор (на базе основной ОС, а не автономный) из популярных (VirtualBox, VMWare и др) больше подходит для бэкенд разработки и тестирования?

Зачем снапшоты, когда код в гите?
Из моего опыта разработки, публичных чатов разработчиков и случайных вузовских методичек, найденных мною в сети, отмечу основные причины:

1) "Завести" проект, особенно с БД, означает не только где-то взять код, но также в правильной последовательности и ритме всё подключить - библиотеки, зависимости, артефакты, фреймворки, БД и прочее, настроить. Общей универсальной схемы по установке проектов нет. Всё зависит от используемых технологий и делается часто "на глаз, как рука набита", по крайней мере так себя вели многие разработчики всех уровней, с которыми мы вместе что-то делали. В общем, процесс занимает много возни руками и нервов. Гораздо проще иметь ветки снапшотов для экспериментов, а не ставить всё заново в случае сбоя зависимостей/настроек проекта.
К тому же либы, IDE, версии браузера и прочее могут меняться.

Докер не всегда используется. Даже если используется, то хорошо, когда его установку или установку подобных вещей можно легко откатить.
Приведу свой пример вкатывания в докер: после установки докера на ubuntu (очевидно, не правильной) часть функциональности докера не работала, как надо. И было непонятно, в чём причина. Очевидно, мы при вкатывании не можем быть специалистами во всём сразу и можем не знать "фишки" по устройству и настройке Linux-программ. В таких случаях, особенно для новичков, чтобы не создавать новых проблем, гораздо проще откатить состояние в "до установки", иметь запасные ветки снапшотов, экспериментировать и так далее. Очевидно, такая ситуация не только с докером, а и с аналогичными программами.

2) Безопасность. Не всегда разработчик досконально проверяет, что скачивает на компьютер и какие права дает. Некоторые ограничиваются оправданием "ну на гите выложили, скачивания есть, значит много людей проверили, скачали, значит всё ок" или "ну типа друзья-коллеги качали, им норм".
Тем не менее, известен случай, как из-за загрузки и подключения кода из одного публичного репозитория у человека угнали аккаунт из какой-то соцсети, в которой он был авторизирован на компьютере. И не использовал он ВМ и прочее, а всё делал в одной ОС.

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

Какой гипервизор (на базе основной ОС, а не автономный) из популярных (VirtualBox, VMWare и др) больше подходит для бэкенд разработки и тестирования?

В перспективе хостовая будет ubuntu, поэтому отказ от WSL2 и Hyper-V.
Также, насколько я знаю, через бэкапы в ova-файлах вроде можно переносить ВМ в VirtualBox на другие компьютеры, базирующиеся на других ОС (хостовых). А WSL2 и Hyper-V вроде таким не могут похвастаться.

Какой гипервизор (на базе основной ОС, а не автономный) из популярных (VirtualBox, VMWare и др) больше подходит для бэкенд разработки и тестирования?

пока что хостовая windows, но в перспективе хостовая будет ubuntu

Подключение/отключение устройств при импорте/экспорте виртуальных машин Virtualbox?

res2001, просто хотелось бы узнать, а в чём преимущество так делать: пересоздавать гостевую ОС каждый раз и переносить-подключать старый диск? Казалось, гораздо проще перенести всё вместе в ova-файле, меньше действий руками. Или тут подводные камни?

Подключение/отключение устройств при импорте/экспорте виртуальных машин Virtualbox?

res2001,

Если бы ты пробрасывал в виртуальную машину реальные устройства, то ты бы это знал

Кстати, во многих гайдах есть установка "Дополнений гостевой ОС" (VirtualBox_Extension_Pack), которые позволяют сделать общую папку, общий буфер обмена и нормальный полноэкранный режим.
Накладывают ли эти дополнения какую-то связь виртуальной машины со старым компьютером? Или экспортируются в общем ova-файле и отлично будут работать на новом компьютере? Предчувствие, что эти дополнения как-то связываются может с драйверами старого компьютера и могут быть проблемы, если хостовая система на новом компьютере уже будет не Windows, а Ubuntu.

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

А мне казалось, что проще засунуть вообще всю виртуальную в ova (не только диск) и потом восстанавливать бэкап оттуда, особенно для новичков и особенно когда это надо делать пару раз в неделю.

Подключение/отключение устройств при импорте/экспорте виртуальных машин Virtualbox?

SunTechnik,

А там именно Ваше реальное оборудование, или то, которое эмулируется внутри виртуалки?

Кстати, хороший вопрос. Открыл диспетчер устройств старого компьютера и не нашел там таких, как показывает VirtualBox при импорте/экспорте. Значит, скорее всего, эти устройства эмулировались самой виртуальной машиной.
Виртуальная машина создавалась стандартным образом, обычная Ubuntu для новичков по гайдам из интернета. Хостовая симтема - Windows.

Подключение/отключение устройств при импорте/экспорте виртуальных машин Virtualbox?

Valentin Barbolin, то есть проще оставить конфигурацию устройств, которая была задана на старом компьютере при создании виртуальной машины, потому что в ином случае может дать сбой какое-то ПО?
А может ли быть наоборот, что оставлю старую конфигурацию старых устройств, а она со временем даст сбой, потому что на новом компьютере нет таких устройств?

И что значит дефолтная конфигурация? Та, которая сама по себе создастся на основе устройств нового компьютера? Или же какая-то наперёд заданная разработчиками VirtualBox конфигурация?

Кстати, вспомнил картинку из учебника, где, насколько я помню, от виртуальной машины и её устройств шли стрелочки к ОЗУ реального компьютера. То есть, как я понимаю, виртуальная машина не имеет доступа к реальным устройствам, а поэтому безразлично какие они?