" title="Написать письмо">Написать письмо
Донаты на карту ВТБ:
2200 4002 2461 6363

Статистика

Пользователи : 1
Статьи : 2207
Просмотры материалов : 8253954
 
Миграция ОС из реалки в виртуалку (18.06.2025). Печать E-mail
2025 - Июнь
18.06.2025 10:32
Save & Share
Миграция - это всегда боль (не ограничиваясь ссылками в этой ссылке: по сайту есть и ещё страдания). Что приводит к закреплению мысли: заставляют что-то мигрировать - слезай с задачи любой ценой, даже ценой депремирования/увольнения: здоровье-нервы сэкономишь.

Простой перенос Astra SE v.1.4 из реального мира в виртуальную машину VirtualBox - естественно, обернулся кошмаром (в т.ч. из-за зашлакованности ОС, установленной в 2014 году). В материале - описаны только первые 2 суток кошмара на улице Вязов, и количество суток до достижения результата - неизвестно. Раз, два, Фредди заберет тебя...



Сама миграция, перенос архивированием физического носителя и восстановления на виртуальный носитель с помощью TeraByte Image, - прошла условно-прекрасно:
- нельзя просто установить в виртуалке ОС с нуля и перенести файлы: это идеально настроенный сервер, выполняющий сразу 3 функции вместо привычной для сервера одной. При этом, настройкой занимались в т.ч. люди, которые уже физически уничтожены, - перенастройка невозможна из-за недостатка информации;
- долгие анализ и очень аккуратная чистка ОС и его содержимого (2 захода пришлось делать) - сократила объём данных с 1.8ТБ до 0.3ТБ: мусора, в т.ч. дублирующегося, - было невероятное количество;
- архивация на внешний диск. После чистки - время архивации уменьшилось с 3.5ч до 1.2ч, размер архива уменьшился в 2.5 раза;
- создание ISO-файла 200ГБ с TBI-файлом, для присоединения к виртуальной машине с целью восстановления в виртуалке;
- восстановление по USB 2.0: в новом ПК, почему-то, материнская плата держит везде USB 3.0 - а передние разъёмы корпуса оказались USB 2.0.

А вот после первого запуска виртуальной машины с ОС - начался форменный писец (Astra SE v.1.4 - кусок забагованного говна).

Разрешение в виртуальной машине - было 640x480 в виде малюсенького окошечка. Игры в настройками дисплея VirtualBox - приводили к изменению разрешения на 1024x768 - но не более, а надо - 1768x992 минимум (чтобы разрешение дочерней ОС было на 1 позицию режима меньше, чем родительской: отсутствие ползунков на экране виртуальной машины). Требуется в автозапуск (fly-admin-autostart, sh xrandr.txt) дочерней ОС поместить файл, содержащий название видеовхода и нужного разрешения:
#cvt 1920 1080 60
xrandr --newmode "1920x1080" 173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
xrandr --addmode 'Virtual1' '1920x1080'
xrandr --output 'Virtual1' --mode '1920x1080'

При настройке скорости виртуальной машины, есть ряд неочевидных вещей:
- ползунки ЦП и RAM ведут себя странно: зелёная линия занимает у ЦП половину доступных ЦП, а у RAM - только 24ГБ из 32ГБ. Выход за пределы зелёной линии - приводит к появлению жёлтого/оранжевого (зависит от версии VirtualBox) треугольника "обнаружены неправильные настройки";
- нужно забить болт на этот жёлтый треугольник. Если присмотреться, прямо вплотную, к линии - видно, что она разделена не на зелёную и красную зоны, а на зелёную, оранжевую и красную. ЦП при этом можно докрутить хоть на 12 поток из 12 - это оранжевая зона. RAM - до 29.5ГБ (если зайти в красную зону - кнопка OK перестаёт быть активной);
- если несколько виртуальных машин запущены вместе в родительской ОС - выгодно им сделать максимум потоков для всех. И когда у одной есть нагрузка на все ядра, а другая простаивает, - физический процессор используется максимально. Если же виртуалки обе пытаются использовать 12 потоков - они будут просто бороться за проценты, никаких критических ошибок не возникает. Также нет смысла выделять 11 потоков из 12, оставив 1 для родительской ОС: так как ручное управление потоками отсутствует - такая настройка не будет иметь смысла;
- по аналогии: если несколько виртуальных машин запущены вместе в родительской ОС - выгодно им сделать максимум RAM для всех. Пока нет загрузки виртуальной RAM - физически RAM не загружается (было запущено 2 виртуальной машины по 16ГБ RAM - когда в системе всего 16ГБ RAM). Физически RAM заполняется только по факту загрузки RAM виртуальной. Если виртуалки используют RAM попеременно и разными объёмами - никаких багов не будет. Однако если сразу вместе начнут использовать много RAM - вот именно эта ситуация не проверена на практике, так что тут возможны нюансы.

В дочерней ОС вообще не видится сетевая карта, как устройство. Приходится лезть в /etc/network/interfaces - и прямо создавать интерфейс руками:
auto eth1
iface eth1 inet static
address 10.0.1.221
netmask 255.255.255.0
gateway 10.0.1.10

Общие папки в дочерней ОС не работают, в отличие от родительской. Пришлось заимствовать решение из Astra 1.7 - но оно заработало только с дополнением:
- ярлык подключения общей папки (приложение): sh /home/astra/network.sh;
- содержимое файла: sudo mount -t cifs -o pass=12345678,vers=2.1 //10.0.1.30/ForAll /mnt;
- ярлык открытия общей папки (приложение): sudo fly-fm /mnt.

Неизвестно, как будет работать виртуальная машина с 2 мониторами.

Так как создан полный клон сервера - ему сразу нужно сменить IP, чтобы не было скрытного конфликта адресов. Так как виртуалка зашифрована и защищена надёжным паролем - выставить автовход в дочернюю ОС (примерно: Пуск→Панель_управления→Система→Вход_в_систему→Дополнительно→Разрешить_автоматический_вход_в_систему), а также убрать в ней гашение и блокировку экрана.

Совсем неисправимо: учётная запись Root - не пашет. Рабочий стол прогружается - но видно только его 1/5 часть справа, ничего не работает (в т.ч. горячие клавиши).

Пока неисправимо:
- современные процессоры, обычно, имеют функцию автоматического разгона в случае высокой нагрузки (другое дело, что в части процессоров это реализовано через жопу). Но как только процессор оказался в дочерней ОС - он стал работать исключительно с номинальной скоростью. Это привело к тому, что номинальный более поточный и менее гигагерцный процессор - стал одинаковым в скорости с авторазогнанным менее поточным и более гигагерцным (при применении многопоточности). А без многопоточности - проиграл сразу вдвойне авторазогнанному более гигагерцному;
- в виртуальной машине, по неведомой причине, 1 поток оказался всегда загруженным на 100%. В родительской ОС - постоянная загруженность на определённое и расчётное количество процентов CPU (тоже 1 поток). В дочерней ОС - отображалось в виде неотключаемого процесса v86d, жрущего расчётное количество процентов CPU относительно количества выделенных ЦП (в настройках виртуалки "ЦП" - реальный поток). Прикол в том, что не загружая дочернюю ОС (просто меню выбора режимов загрузки Astra), - поток как жрался, так и жрётся. Это оказалось не шифрование диска, не виртуальная периферия, не ЦП с RAM - полная загадка. Даже если загрузиться с WinPE - всё равно 5% (~2/3 потока) всегда жрётся, даже если жёсткий диск виртуальный отключен. Это влияет только на энергопотребление и скорость работы виртуалки - вроде, не критично - а, вроде, и критично.

(добавлено 19.06.2025) Как ни странно, убийство процесса с помощью sudo kill $(pidof v86d) - не привело к каким-либо багам и полностью разгрузило поток - поместил в автозагрузку. Однако выяснился другой баг: в Astra v.1.4 неважно, включен ли пункт в меню автозагрузки или нет, - он всё равно выполнится.

Изменение разрешения с 1920x1080 на 1768x992 - привело к такому же багу, что в Root: 1/5 рабочего стола, ни 1 значка, никакой реакции на устройства ввода. Пришлось грузиться с WinPE и исправлять обратно.

Всплыл ещё баг:
- скорость копирования (и работы в целом) HDD родительской ОС - 40МБ/с. Лампа красная моргает - проблема программная;
- на сайте производителя есть вопрос на эту тему - не думал, что эти пидоры придумают такое: вопрос есть - а ответ доступен только с платной техподдержкой (wiki.astralinux.ru/kb/fajlovaya-sistema-ntfs-medlennoe-kopirovanie-238761707.html). Решил кликнуть по форме обратной связи там же, высказать все мысли вслух и с матерком, - форма обратной связи зацикливается, при каждом нажатии делая ссылку в браузере всё длиннее и длиннее, - так и оставаясь, по итогу, недоступной;
- американское ядро версии 5.15 и выше (да, они его тупо скоммуниздили) - содержит в себе хороший драйвер NTFS от Paragon, приводящий скорость работы разделов NTFS к нормальной (к примерной скорости носителя или немного меньше). Разработчики не внедрили эту технологию в свой интерфейс корректно - везде, где монтируется NTFS, вместо "ntfs" нужно писать "ntfs3". А то скорость раздела 40МБ/с вместо 200МБ/с на HDD и 110МБ/с вместо 350МБ/с на SSD - ну такое себе.

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

(добавлено 19.06.2025) Интересно: что будет, если BAD-сектор попадёт на файл виртуального жёсткого диска.

Вскрылся давно забытый баг: в Astra v.1.4 в Qt v.5.3 плохо работает скролл: при мотании вниз - примерно "вниз-вниз-вверх-вниз" получается, причем "вверх" может быть большой амплитуды. Как исправлять - традиционно, никто не знает, - самому решение искать надо; и простым x-mouse дело не обойдётся.

Виртуальный диск требует проверки на ошибки и дефрагментации, ведь это не делали более 10 лет. Т.к. в Astra v.1.4 - баги:
- утилиты есть, но их нельзя применить к примонтированному разделу, а системный раздел не размонтируется;
- fsck для ntfs - вообще отсутствует (нет ntfsfix из Astra 1.7);
- нужен именно сторонний именно линуксовый именно Live-диструбитив (были эксперименты, забыл уже: сторонние утилиты именно у Astra v.1.4 запарывали раздел). Остановился на Linux Mint - но он DVD, из него загрузочную флешку изготавливать ещё.

(добавлено 23.06.2025) Баг с рваным скроллом VirtualBox+Astra_1.4+Qt - оказался шире: VirtualBox+Astra_1.4. Исправление: в настройках виртуальной манипулятора курсора на "PS/2 мышь". Ложка дёгтя: мышь выйдет из виртуалки только после нажатия клавиши HOST.

Linux Mint - не грузится в VirtualBox. Пришлось в Recovery Mode, под рутом, umount всех разделов - и fsck -f. Ошибки - были найдены и исправлены. На функционале - не отразилось. Оценка фрагментации - e4defrag: менее 1%.

(добавлено 24.06.2025) Это какой-то сюр:
- ntfs3 - не выводит носитель на 100% его аппаратной скорости (есть ускорение в 2-2.5 раза - но это не предел);
- попытка переформатировать раздел в ext4 - приводит к тому, что mkfs имеет другой список параметров (mkfs = mkfs.ext4 = mke2s). Нет параметра -Q - хрен с ним (форматируется и так быстро). Но не даёт корректно выставить размер кластера 512 - несмотря на то, что диагностическая винда показывает размер кластера именно 512Б;
- носитель вышел на примерный предел скорости - но интересовало изменение размера кластера для оценки максимальной скорости (в NTFS и FAT32: больше размер кластера - быстрее скорость, но большие потери дискового пространства, если файлы мелкие). Попытка в Windows переформатировать созданный в Astra раздел Ext4 в Paragon Hard Disk Manager 15: пишет - раздел неформатированный, но при этом даёт возможность отформатировать раздел в ext4 - но при этом это вообще не тот раздел: программа по работе с дисками видит его как C:, а драйвер этой же фирмы - как G:;
- то есть, ext4 у Astra - нестандартная, с внедрением ими мандатных меток, - и глючит при работе с другими диагностическими утилитами. Этим же объясняется то, что видимый раздел ext4 (системный) грохается, если ему сделать fsck частью других утилит по работе с дисками.


Вышла версия Astra SE 18.1: тестирующие в соседней комнате говорят, что тоже полна багов, - только других.

(добавлено 25.06.2025) Linux Mint не грузится - потому что ему не нравится в VirtualBox режим UEFI - грузится только без галки "EFI...". Однако проверено на другом ПК (на котором Windows 10) - могут быть нюансы.

Решение со скоростью NTFS пришло внезапное и удобное:
- NTFS с драйвером ntfs3 вместо ntfs - быстрее в 2-3.5 раза (зависит от типа носителя и, скорее всего, самого носителя);
- ext4 быстрее NTFS с драйвером ntfs3 процентов на 10;
- но ext4 медленнее NTFS с драйвером ntfs3 и размером кластера 32КБ (64 сектора диска 512Б в одном кластере): 56МБ/с против 70МБ/с - проверено на гигантском файле 380ГБ, копируемым рядом с собой (система пишет ~половину реальной скорости носителя, т.к. идут одновременно чтение и запись). Когда файл большой - ext4 начинает лагать по скорости - тут размер кластера NTFS и получает решающее преимущество - суперлаги ext4 становятся более вредными, чем небольшие лаги NTFS. И с учётом того, что скорость важна для больших файлов (в большинстве своём Astra 1.7 будет использоваться для виртуальных машин, а не прямой работы) - это идеальное решение вопроса;
- проверено дополнительно на размере кластера 64КБ (максимальный из возможных, измерение проводилось на 164 гигабайте из 380, как и в прошлый раз): 72.5МБ/с.

Виртуальные диски NTFS - можно открывать с помощью 7-Zip. Виртуальные диски Ext4 - PowerISO.

Скорость сети у хаба 1Гб/с: из Windows 10 и Windows 7 - 125МБ/с, из Windows 7 в Astra 1.7 - 56МБ/с. Как будто, Astra не умеет включать режим хаба "полный дуплекс", оставаясь в полудуплексе.

(добавлено 26.06.2025) С помощью HWiNFO удалось выяснить: то, что процессор не может в виртуалке на турбо-режим выйти - виновата не Astra, а VirtualBox. Установка Guest Additions также не помогла исправить проблему, все настройки ЦП виртуалки ситуацию не исправляют - тупик.

Виртуалка запоминает свою полноэкранность - разрешение дочерней ОС можно делать равным разрешению родительской.


(добавлено 27.06.2025) Никак не получается устранить дельту в 3ч дочерней ОС относительно времени родительской. И это при условии, что обе ОС - Astra, т.е. этой дельты вообще не должно было произойти.

(добавлено 30.06.2025) Решение с часами для виртуалки: отключить в ней опцию "Enable Hardware Clock in UTC Time", запустить в ОС "sudo dpkg-reconfigure tzdata".

Вероятное решение для реалки: отключение RTC in local TZ с помощью команды "sudo timedatectl set-local-rtc 0 --adjust-system-clock".

Логическая ошибка: при разворачивании образа - его не надо сохранять как ISO-файл, если диск внешний: достаточно подключить внешний диск в настройках USB виртуалки. При этом, он может называться совершенно по-идиотски - в моём случае, "Best...".

Баг просто безумный (родительская ОС Astra Linux SE v.1.7.4.0 (7)):
- пусть подключен внешний HDD. Не знаю, в чём причина, - но ОС отрубает его через какое-то время, если нет нагрузки;
- когда этот HDD подключается к виртуалке VirtualBox - он исчезает из родительской ОС и появляется в дочерней;
- но родительская ОС продолжает его видеть наполовину. В виртуальной машине идёт чтение с HDD 100МБ/с - а родительская ОС считает, что HDD простаивает;
- в один прекрасный момент, ОС принудительно снимает питание с HDD - и процессы на виртуальной машине сваливаются с ошибками. Спасибо ещё, что чтение с HDD шло, а не запись: словить ошибки файловой системы на архивном диске сотрудников - это катастрофа.

(добавлено 01.07.2025) Катастрофа - произошла, просто была скрыта. Контрольные суммы архивных копий босса на архивном носителе - отличаются от контрольной суммы архивной копии босса на архивном архивном носителе. То есть, ОС чуть не остановила работу сектора на несколько недель.

В данной ситуации - единственные разумные действия: размножить архивную архивную копию босса на разные носители - и только потом проводить его миграцию дальше. Причём, выбрать устаревший - но проверенный временем способ: создание на ОС Windows VMDK-диска с файлом архивной копии - и подключение его к виртуалке на родительской ОС Astra.

(добавлено 03.07.2025) Катастрофа - оказалась двойной. Тестировал связку БП+салазка+носитель - именно в астре был этот глюк; в WinPE терабайты данных тестово гонял в обе стороны - всё нормально. Однако при более глубоком анализе, выяснилось: связка хорошо читает все ранее созданные архивные копии (кроме тех, что были убиты нештатными отключениями) - но плохо записывает в себя новые файлы (контрольные суммы не совпадают - файлы оказываются битыми).

Что из этих 3 компонентов повреждено - решится только макетированием: есть и БП ПК, и другая салазка, и другой носитель. Но абсолютно точно ясно: эта ОС нанесла уже не программный, а вдобавок и аппаратный ущерб.

Выяснилось: у салазки повреждена микросхема - она и глючила. То есть, Astra меня конкретно на бабки поставила.

(добавлено 05.07.2025) Астра вырубает ноутбук: при простое пользователя и работе от батареи - даже если нагрузка на жёсткий диск в этот момент максимальная (виртуалка шифровалась). Как отключить - непонятно. Менеджер батарей есть, а настроек отключения выключения нет (или, как обычно, запрятано где-то далеко).
Обновлено ( 05.07.2025 11:57 )
 
 

Последние новости


©2008-2025. All Rights Reserved. Разработчик - " title="Сергей Белов">Сергей Белов. Материалы сайта предоставляются по принципу "как есть". Автор не несет никакой ответственности и не гарантирует отсутствие неправильных сведений и ошибок. Вся ответственность за использование материалов лежит полностью на читателях. Размещение материалов данного сайта на иных сайтах запрещено без указания активной ссылки на данный сайт-первоисточник (ГК РФ: ст.1259 п.1 + ст.1274 п.1-3).

Много статей не имеет срока устаревания. Есть смысл смотреть и 2011, и даже 2008 год. Политика сайта: написать статью, а потом обновлять ее много лет.
Рекламодателям! Перестаньте спамить мне на почту с предложениями о размещении рекламы на этом сайте. Я никогда спамером/рекламщиком не был и не буду!
Top.Mail.Ru