Личен блог на Vampik
Навигация
Заявената страница не можа да бъде намерена (404). Това е страницата по подразбиране.
Повреда на диска на виртуална машина по време на миграция към Proxmox, част 2
Първоначално реших проблема с обикновена корекция:
Но се оказа, че пластирът не е съвсем правилен - той поправя LVM, но прекъсва LVM Thin. Тъй като LvmThinPlugin наследява от LVMPlugin, той използва същия команден ред за стартиране на dd. В резултат на премахването на аргумента conv = sparse, дискът след миграцията започва да заема пълния си обем и става нередък. Един от разработчиците предложи правилната корекция тук: https://pve.proxmox.com/pipermail/pve-devel/2019-January/035313.html
Повреда на диска на виртуална машина по време на миграция към Proxmox
Изведнъж се сблъсках с такъв проблем. Има клъстер Proxmox VE и виртуална машина в него, която работи на възел А. Трябваше да го прехвърля на възел Б. След прехвърлянето той не стартира. Операционната система се кълне в повреда на системните файлове. Възстановяването от архивиране и повторно прехвърляне се извършват с абсолютно същия резултат, т.е. това не е случаен бъг. Проверката на контролните суми на файловете показва, че те наистина са повредени на възел Б.
Много време беше убито, опитвайки се да разбере вероятната причина, но се оказа, че.
Ако имате Proxmox VE клъстер и използвате LVM (нормален, не тънък) като място за съхранение, тогава съдържанието на дисковете може да бъде повредено по време на миграцията между възлите. Схемата за мигриране на дискове към LVM е проста - съдържанието се чете с помощта на dd, прехвърля се по мрежата и се записва до местоназначението със същия dd. Записът се извършва с помощта на командния ред на формуляра:
Познахте, нали? Или не?
Proxmox е обсебен от тънкото съхранение, където дисковите изображения заемат толкова място, колкото данните вътре в тях - LVM Thin, ZFS, оскъдни файлове. Изглежда един от разработчиците е забравил, че това не работи с обикновени LVM. Ако на виртуалния диск има нула блокове, след прехвърляне на диска на друг възел вместо това ще има неопределени данни, а именно това, което преди това е било записано на това място на диска на хост машината.
Добре е, че успяхме да забележим този проблем, като повредиме системния файл, а не някаква важна база данни например.
Всичко по-горе е актуално за последната версия в момента:
Въз основа на ангажиментите в git, мога да предположа, че този проблем може да е поне година и половина. Никой ли не е забелязал толкова критична грешка в корупцията на данни досега? Какво, никой не използва клъстер с локално LVM съхранение? Всички седят на хранилища ZFS, LVM Thin или NAS/SAN?