Как мне безопасно выйти из этой ситуации?
Подробности следующие:
На сервере xen выделены блочные устройства для виртуальных машин. Но эти устройства также были установлены внутри Xen.
Фактически 44 из этих блочных устройств были установлены таким образом. Что еще хуже, каждое физическое устройство видно по 4 путям, и каждый из них монтируется в отдельной точке монтирования. Другими словами, устройства фактически монтируются по 5 раз каждое.
Гостевая ОС ВМ видит путь через псевдоустройство PowerPath (выделено как устройство phy: block для domU)
Некоторые из устройств отформатированы как ext2 и reiserfs.
Нет необходимости объяснять мне риски повреждения файловой системы, связанные с этим.
Я боюсь, что даже простое отключение файловых систем может привести к повреждению, и чувствую, что на этом этапе отключение питания от хоста - самый безопасный вариант .
Обратите внимание, что приложения, базы данных Oracle по большей части, во всех виртуальных машинах все еще работают и используются.
Я обнаружил это при исследовании высокой загрузки ЦП на dom0. Существует неубиваемый процесс поиска, с помощью cwd -> / media / disk-12, который монтируется из / dev / sdf1, который принадлежит / dev / emcpowerr
Прежде чем кто-либо спросит, один раз, когда я видел, что процессы не могут быть уничтожены и продолжают использовать ЦП и ОЗУ (в отличие от процесса несуществующего / зомби), это когда есть невыполненные зафиксированные операции ввода-вывода, например, возвращена синхронизация, но физически на диске пока нет , Чаще это происходит на ленте ввода / вывода.
Предложения !?
PS Я бы ожидал, что устройства будут «зарезервированы» после установки, чтобы предотвратить подобные вещи? Или это невозможно в Linux?
РЕДАКТИРОВАТЬ: Во-первых, я убежден, что KDE внутри гипервизора) является виновником. Похоже, что KDE монтирует устройства при входе в систему для создания значков на рабочем столе. Однако то же самое не происходит на других серверах Xen, но на всех других серверах установлена гораздо более старая версия SLES, и KDE ... V4 выглядит оскорбительно, а 3.4 ведет себя лучше).
Более того, две некритические виртуальные машины зависли. После их закрытия они не будут загружаться снова из-за повреждения файловой системы. Основная / рабочая виртуальная машина все еще работает, и база данных на ней все еще работает, но очевидно, что это бомба замедленного действия. Клиент пытается перестроить среду на другой виртуальной машине на другом сервере, но застрял в проблемах с настройкой некоторых компонентов, поэтому мы ждем ...
В любом случае я чувствую, что до сих пор ни один из ответов не был больше, чем «лучшая практика всегда закрыта изящно», и я надеюсь получить что-то более конкретное ... В любом случае, я чувствую, что эта ситуация может потребовать более осторожного мышление. Будет ли завершение работы причиной синхронизации ожидающих операций ввода-вывода, в частности обновлений метаданных файловой системы от гипервизора, и может привести к серьезному повреждению файловой системы?
источник
Ответы:
Если диски записываются с одной точки монтирования, никакого вреда не причиняется. Сделайте чистое отключение, (верните его из приостановленного состояния, если хотите) исправьте крепления. Не запускайте ничего, кроме необходимых приложений на Dom0. Если, OTOH, разделы пишутся с нескольких путей, это ПЛОХО и ухудшается со второго. Потяните пробку.
источник
У меня нет конкретной причины, но мое внутреннее чувство подсказывает мне, что лучшим подходом может быть следующее:
Альтернатива 11: Запустите ВМ и смонтируйте файловые системы без полного fsck.
Причина заключается в том, что я не хочу, чтобы гипервизор Xen имел больше шансов, которые абсолютно необходимы для повреждения файловых систем domU.
источник
Я не эксперт по Xen и еще не имел опыта работы с ним. Но мой подход, если бы я был на вашем месте, был бы следующим: сначала я знаю, что могу потерять данные (возможно, даже все); во-вторых, я бы попытался создать моментальные снимки, а затем приостановить работу виртуальных машин, восстановив их в безопасной другой среде.
Я не хочу давать вам ложных надежд, но я думаю, что вам повезет, если вы сможете что-нибудь восстановить.
Предупреждение : следование этим советам может привести к потере всех данных. Вам решать, стоит ли рисковать или нет.
Если повезет, ваши приложения все еще работают, потому что все данные, которые они используют, находятся в энергозависимой памяти. Вы должны попытаться воспользоваться этой ситуацией (попытаться оценить, может ли это иметь место для каждого приложения) и экспортировать оперативные данные в общий сетевой ресурс, если приложения предлагают такую функцию. Если какие-либо данные находятся на диске, эта функция экспорта может быть либо «заблокирована», как ваш
findоператор, либо аварийно завершить работу (и вывести из строя приложение или ОС) из-за измененных / поврежденных данных на диске.Затем вы можете попытаться сделать живой снимок, следуя инструкциям в следующей статье: Создание снимков в Xen . Я бы пошел за побайтовым снимком, хотя он мог застрять так же, как ваша
findкоманда ... Однако я бы не давал такой большой надежды.Перед выполнением предыдущей команды вы должны прочитать этот документ из Citrix, который помогает понять снимки в Xen (PDF) .
Я желаю вам удачи.
источник