Утилита Screen создает отдельные сессии, в рамках которых можно выполнять команды, работать. И при желании переключаться между этими сессиями, как между окнами графического интерфейса. Это не замена работе в терминальных сессиях на одном сервере нескольких пользователей, а отдельный инструмент. Больше всего это похоже на работу по RDP. У вас может быть открыто несколько rdp-сессий. Если коннект нарушится, вы потом просто переподключаетесь и продолжаете работать. Аналогично, если кто-то подключится к вашей сессии rdp, вас отключит, а работу продолжит уже другой человек.

Рано или поздно такая задача перед вами все равно появится - как узанать, какой IP адрес у конкретной виртуальной машины KVM. Даже если машина только одна - не подключаться же к ней, в самом деле. Я нашел три способа, причем третий мне очень понравился, на мой взгляд, потенциально, он самый лучший для траблшутинга при многих проблемах с сетью и совсем необязательно только с KVM.

CentOS меня почти всем всегда устраивала, но только не актуальностью программного обеспечения. В CentOS 8 внесли много изменений, но что осталось неизменным - это то, что установка софта по-прежнему достаточно консервативна по-умолчанию. Репозиторий EPEL, как и раньше, нам в помощь.

Хотелось бы предупредить владельцев Mikrotik. При обновлении до версии 6.46.5 слетела настройка IP адреса бриджа (bridge) локальной сети, из-за чего адрес микротика в локальной сети переназначился на интерфейс ether1 (вместо ether2-master)! А потому доступ к роутеру стал недоступен, кабелем winbox его увидел, но адрес при этом был 0.0.0.0/24, так что по сети на роутер был недоступен. Учитывайте при удаленном обновлении!

В CentOS 8 много что было изменено, в том числе это коснулось управления сетью. Для применения изменений в сетевые настройки в CentOS 8 используйте или NetworkManager:

Есть такой стандарт OVF (Open Virtualization Format) — это открытый стандарт для хранения и распространения виртуальных машин. Стандарт OVF не привязан к какой-либо реализации гипервизора или аппаратной архитектуре и удобен для экспорта и импорта виртуальных машин.  

Есть хост CentOS 7, KVM, гость vm1 (Windows 7 x64, но что Windows, что Linux, отличаться по сути будет только установка драйвера внутри гостевой vm). Пока виртуальная машина работает, копировать ее диск - идея неправильная. Непонятно, что будет скопировано и непонятно, восстановится ли потом. Идея live backup (т.е. backup без остановки) состоит в следующем - делаем снапшот виртуальной машины, при этом чтение/запись начинает выполняться в этот снапшот. Сразу после создания снапшота исходный диск виртуальной машины уже ничем не занят - все новое копируется в файл снапшота. Можно спокойно скопировать этот диск. Это займет какое-то время, в течении которого vm работает, что-то записывается, удаляется. После того, как мы спокойно скопируем диск, нужно будет дать команду все из снапшота залить в основной диск vm. Снапшот нам нужен был только как временная мера.

Если во время обновления, установки или удаления программ с помощью yum в CentOS внезапно прервался сеанс ssh или система подвисла, вы нажали Ctrl+C в процессе, то очень вероятно, что выполнение yum будет прервано и при повторе команды вы получите сообщение о незавершенных операциях с yum с предложением решить проблему с помощью yum-complete-transaction. Что это такое?

А зачем их удалять, собственно, если в CentOS по-умолчанию количество хранимых старых ядер равно 5 (привет, default Ubuntu 16 и 18, где весь boot рано или поздно будет забит до 100%), за что отвечает параметр installonly_limit в /etc/yum.conf? Например, при сбое установки обновлений система может зависать на определеном ядре, а если выбрать другую версию ядра, все будет в порядке. То есть задача может быть просто удалить конкретное ядро, которое точно не нужно. Или если у вас раздел boot слишком маленький и доводить его до заполнения не стоит. Причин может быть много.

Недавно столкнулся с проблемой восстановления MacBook из резервной копии TimeMachine. Копия есть, MacBook ее видит, если загрузиться в режим восстановления (там, где выбираете восстановить из резервной копии, запустить дисковую утилиту и др.). Но при попытке восстановления из копии выходило сообщение "Возникла проблема при подключении к серверу. Возможно, сервер не существует или недоступен в данный момент. Проверьте имя сервера или его IP-адрес, а также сетевое подключение, а затем повторите попытку.". Учитывая, что копия и так находилась на сетевом носителе, проблема была не в недоступности сервера.