Vampik s personal blog

Navigation

The requested page could not be found (404). Це є default page.

Пошкодження дисків віртуальної машини під час міграції в Proxmox, частина 2

Спочатку вирішив проблему простим патчем:

Але виявилося, що патч не зовсім коректний – виправляє LVM, але ламає LVM Thin. Оскільки LvmThinPlugin успадковується від LVMPlugin, він використовує той самий командний рядок для запуску dd. В результаті видалення аргументу conv = sparse диск після міграції починає займати свій повний обсяг, стає не розрідженим. Один із розробників запропонував коректне виправлення ось тут: https://pve.proxmox.com/pipermail/pve-devel/2019-January/035313.html

Пошкодження дисків віртуальної машини під час міграції в Proxmox

Несподівано зіткнувся з такою проблемою. Є кластер Proxmox VE, і віртуальна машина в ньому, яка працює на ноді A. Потрібно було перенести її на ноду B. Після перенесення вона не запускається. Операційна система лається на пошкодження системних файлів. Відновлення з бекапа і повторне перенесення проходять з таким самим результатом, тобто. це не випадковий збій. Перевірка контрольних сум файлів показує, що у ноді B вони справді пошкоджені.

Багато часу було вбито у спробах зрозуміти ймовірну причину, але виявилося ось що.

Якщо у вас кластер Proxmox VE і як сховища використовується LVM (звичайний, не thin), то при міграції між нодами вміст дисків може бути пошкоджений. Схема міграції дисків на LVM проста - вміст читається за допомогою dd, передається по мережі та записується в місці призначення за допомогою того ж самого dd. Запис здійснюється командним рядком виду:

Вже здогадалися, га? Чи ні?

Proxmox схиблений на тонких сховищах, де образидисків займають стільки ж місця, скільки дані всередині них – LVM Thin, ZFS, розріджені файли. Схоже, хтось із розробників забув, що з простим LVM таке не працює. Якщо на віртуальному диску є нульові блоки, то після перенесення диска на іншу ноду замість них виявляться невизначені дані, а саме те, що було раніше записано на цьому місці на диску хост-машини.

Добре, що вдалося помітити цю проблему зі псування системного файлу, а не якоїсь важливої бази даних, наприклад.

Все сказане актуально для останньої на даний момент версії:

Судячи з комітів у git, можу припустити, що цій проблемі можливо не менше півтора року. Невже досі ніхто не помітив такого критичного багу з пошкодженням даних? Що, ніхто не використовує кластер з локальним сховищем LVM? Усі сидять на ZFS, LVM Thin чи NAS/SAN сховищах?

Thermaltake DPS G App - згортання в трей під час автозапуску

Пощастило стати володарем "розумного" блоку живлення THERMALTAKE SMART DPS SPG-0750DPCG. У блок живлення вбудований чіп моніторингу, який дозволяє отримувати такі дані: напруга та струм по кожній з ліній (3.3V, 5V, 12V), вихідну потужність, коефіцієнт ефективності, температуру та швидкість вентилятора. Ідея хороша, але як завжди підкачало убогий поділ китайських програмістів, що додається до хорошого залозу.

Опустимо загальну кривість програми, ця нотатка не про це. Є один дуже дратівливий момент. Thermaltake DPS G App у 3 мажорній версії досі не вміє таку просту річ, як згортатись у трей під час автозапуску. У результаті при кожному запуску Windows вікно програми красується в центрі екрана і його доводиться вручну закривати.

Для вирішення цієї проблеми було складено невеликий скрипт на AutoIt. Справа трохиускладнилося тим, що програма написана на Qt, через що довелося застосувати банальну емуляцію кліку мишкою. Але на щастя, тут на руку грає те, що китайські програмісти чомусь зробили вікно програми фіксованого розміру.

Достатньо додати його в автозапуск і проблему вирішено.

PinTo10v2 v1.2

В рамках автоматичної інсталяції Windows або групових політиків іноді виникає необхідність прикріпити або відкріпити ярлик програми на панелі завдань або в меню "Пуск". Скрипти на базі VBS, призначені для Windows 7, перестали працювати у Windows 10. Для вирішення цієї проблеми Stuart Pearson створив утиліту PinTo10 на базі NSIS. А пізніше, тому що NSIS не дуже добре підходить для цієї мети, оновлену версію на C# - PinTo10v2. Її офіційна сторінка в Інтернеті: https://pinto10blog.wordpress.com/.

Програма універсальна та працює як на Windows 7, так і на Windows 10. Windows 8 та серверні ОС не підтримуються.

На жаль, у процесі використання даної утиліти виявився баг. Програма вилітає з помилкою при спробі роботи з ярликами на панелі завдань, якщо в запуску програми використовувалися короткі імена у форматі "8.3".

Небагато технічних деталей. Наприклад, програма запускається з тимчасової папки, і змінна %TEMP% у користувача LongUserName дорівнюватиме C:\Users\LONGUS

1\AppData\Local\Temp. Функція ChangeImagePathName(), за допомогою якої PinTo10v2 симулює Windows Explorer, через використання GetDirectoryName() розгорне це C:\Users\LongUserName\AppData\Local\Temp і викине виняток, т.к. новий шлях нібито довший за старий. Більше того, виняток не опрацьовується, і програма в результаті падає з помилкою.

Я зробив пару змін у вихідному коді для виправлення цієїпроблеми. По-перше, додав обробку винятку. Тепер у разі помилки програма просто виведе відповідне повідомлення та закриється. По-друге, позбувся GetDirectoryName() у ChangeImagePathName(). Знайшов вихідний код цієї функції на Github і взяв із неї буквально пару рядків, видаливши непотрібні перевірки та трансформації.

Моя модифікована версія PinTo10v2 v1.2. Містить вихідний код та бінарник, скомпільований Visual Studio 2015: PinTo10v2_1.2.7z

Модифікація прошивки від ентузіастів для маршрутизаторів Asus, D-Link, Netgear

Розробку модифікації припинено у 2013 р. у зв'язку зі старінням обладнання та відсутністю підтримки нових моделей у ядрі.

Останні версії прошивки:

Застаріла прошивка гілки -d