Как я откатил систему на месяц назад и все вернул? Опыт использования ESXi. Или как делать не надо


Всем привет. 
Это может показаться для кого-то поучительной историей того, как не стоит делать и почему какие-то важные технические работы в час ночи (в системе, в которой ты мало чего понимаешь), могут привести к огромному краху и простою на два дня.


image


Небольшая заметка-рассказ системного администратора-любителя, который только начинает погружение в мир виртуализации. История о том, как снапшоты не помогли, а помешали и сделали откат системы на месяц, а потом я с даунтаймом в 2 дня вытащил все файлы оттуда и вернул систему.



Предыстория


После двух лет сидения на nix системах, а в частности на ubuntu server (16.04 LTS), я решил попробовать себя в виртуализации. Знакомый посоветовал ESXi как бесплатное решение для небольших серверов (мой случай: 1 процессор + всего 8 GB RAM). Процесс переезда осложнялся тем, что надо было сначала на windows-компьютере поднять vmware workstation вместе с vmware converter`ом, перебросить туда готовую систему, после поднять на сервере esxi и уже после знакомым конвертером перебросить систему на esxi. Вот такой долгий и мучительный путь. Главная ошибка при переносе, которую я допустил и которая до сих пор мне аукается, заключается в том, что я использовал thin-диск. То есть будучи на чистом ubuntu server c диском, отформатированным в exfat-4, я имел где-то 223.8 гб места на ssd. Переезжая на esxi и форматируя диск в их непонятный ни для чего формат, я потерял всего 300мбайт, но именно из-за них я не смог сделать thick диск, который мне (впоследствии так оказалось) был так нужен.


Начало


Раньше я ломал дрова с ubuntu server (когда только «изучал» его), откатываясь и переустанавливая систему по раз в месяц-два. Сейчас я ломаю дрова с ESXi. Думаю, проблему thin-дисков описывать не надо (если вкратце, то они после расширения своего пространства его не «сужают» в обратную сторону. они так же могут выйти за пределы физического количества памяти на диске). Во-первых, я использовал swap на том же ssd диске, не настроив его должным образом в ESXi. Он жрал память, записывал туда какие-то временные файлы, а thin тем временем рос.
Во-вторых, я зачем-то сделал снапшоты. Руководствовался я в тот момент тем, что «ну это же удобно, быстро и все такое». Еще не подозревая, какую бяку и какую медленную бомбу они мне заложили. 
В-третьих, я не следил за стремительно уменьшающимся количеством памяти на диске.


image


Завязка


Первым звоночком стал стоп основной машины 17 июля. Пришло оповещение на почту о падении хоста. Зайдя в esxi, чтобы поднять его (ну вдруг что-то могло произойти), виртуалка мне выдала приятное известие (скриншота нет, к сожалению). Вольный пересказ всплывающего окна был примерно такой «Прости, место на диске закончилось. Твоя виртуальная машина остановлена. Очищай место и можешь продолжать пользоваться ВМ. «Повторить» «Отменить»». На тот момент проблема решилась удалением второй ВМ, которая занимала около 16гб. Но это было временное решение, так как с каждым днем куда-то по-прежнему пропадало по 5гб, хотя в системе не было прироста этих файлов.


В итоге 19 июля вечером прохладного четверга я написал сначала на тостер об этой проблеме. Ответа так и не было. Думаю, это из-за непопулярного тега esxi. После пошло безуспешное гугление, после — удаление снапшотов. В этот момент исчезло 5 гигабайт, free-space стало больше, но не на столько, чтобы забыть об этой проблеме. 



image


После, пораскинув мозгами, я стал изучать иерархию снапшотов. Последний, 000003, занимал 12гб места на тот момент. В настройках ВМ он числился как активный дисковый файл, с которого машина и загружалась. Недолго думая, я удалил с hard disk 1 disk file с активным диском снапшота и на его место вставил parent-диск всей виртуальной машины.


image


Система загрузилась (ура), а вместе с ней и файлы за 30 июня. Последняя дата изменения всех файлов на parent-диске. Подозреваю, именно в этот день я создал первый снапшот. Места, что логично, не прибавилось. В free-space по-прежнему около 5гб, а файлы пропали.


Первые мысли логичны: что я наделал, все файлы до 19 июля испарились. Потом я увидел, что файлы снапшотов не удалились. Однако при попытки загрузки их в качестве основного диска ESXi ругалось на измененный parent-диск, чего быть не должно «The parent virtual disk has been modified since the child was created» Моя вечная ошибка на протяжении двух последующих дней.


Гугление


Время подходило к двум часам ночи, и я оставил все тщетные попытки вытащить хоть какую-то информацию с этих несчастных *-0000?-.vmdk файлов снапшотов.



Утро пятницы началось с активного, действительно активного гугления наподобие «как вытащить файлы из vmdk». Статьи, Linux reader (программа на windows) и все подобное попадались очень часто. Я перебрасывал эти 223 гигабайта с сервера на windows-ноутбук по 100мбитному каналу, что было очень больно. Я пытался примонтировать ssd-диск формата vmware к linux системе, накатывал на нее vmware-tools, она ругалась на несовместимость версий (последняя поддерживаемая — 5, а у меня была 6.5). Попытки открыть через windows и java тоже были тщетными.


И даже после того как мне удалось получить доступ (с помощью программы Linux reader на windows) к файлу *-flat.vmdk, я получил файлы только до 30 июня. Все дальнейшие попытки примонтировать файлы снапшота ничего не давали, программа ругалась на недействительный диск и отказывалась работать дальше. 



Выход найден


Пятница закончилась, я был вымотан, а так же расстроен тем, что файлы вернуть нельзя. Но суббота началась успешно. По гуглению ошибки (почему я не сделал это сразу — неизвестно) «The parent virtual disk has been modified since the child was created» в первой же строке гугл выдал ссылку на страницу vmware. Куча страшных символов, красных строк и всего подобного сразу же испугало. Я открыл ссылку и оставил ее в надежде, что найду что-то более понятное.


И оно нашлось. https://communities.vmware.com/thread/323730 Русскоязычный форум VmWare и подобная проблема встретили меня на просторах интернета. Вероятно, это не тот же случай, что и у меня, но промотав вниз и вчитавшись в комментарии, я попытался сделать подобное.


В текстовом редакторе, подключившись к esxi по сфтп, я открыл файл с настройками parent-диска. .vmdk (не -flat.vmdk) я узнал CID диска, а после полез в *-00001.vmdk, делая так, как описал человек с ником apavlyuchenko на форуме.


В первом снапшоте в полях CID и parentCID стоило указать CID parent-диска. А после в файле .vmx в полях
scsi0:1.present = "false"
scsi0:1.fileName = «
.vmdk»
scsi0:1.deviceType = "scsi-hardDisk"
изменить параметр FALSE на TRUE и .vmdk на -00001.vmdk.


И действительно, после этого машина загрузилась и уже не ругалась на ошибку. И о чудо! Появились файлы до создания второго снапшота!


На форуме товарищ описал способ восстановления файлов только с одного снапшота. Но мой случай тяжелый (видимо, из-за моей болезни, которая называется «тыкать все руками на рабочей машине»). И у меня был не один снапшот, а три. Что логично, надо было продолжать менять файлы.


Итак, мои действия.


Открываем parent-диск. Узнаем его CID. Далее копируем CID parent-диска в строку parentCID диска -00001.vmdk (первый снапшот). Там же смотрим CID этого снапшота и копируем его в строку parentCID диска -00002.vmdk (второй снапшот). Там смотрим CID этого снапшота и копируем его в строку parentCID диска -00003.vmdk (третьего снапшота), ну а после — залезаем в .vmx и в строке fileName указываем имя файла снапшота (в моем случае *-0003.vmdk)


В итоге получилось следующее.


*.vmdk
CID=387edddf
parentCID=ffffffff


*-00001.vmdk
CID=0284jf712 (все CID`ы я взял от болды)
parentCID=387edddf


*-00002.vmdk
CID=732fhhtud
parentCID=0284jf712


*-00003.vmdk
CID=3747jfj4ff
parentCID=732fhhtud


.vmx
scsi0:1.present = "true"
scsi0:1.fileName = "
-00003.vmdk"
scsi0:1.deviceType = "scsi-hardDisk"


Включаю ВМ, вижу, что данные восстановлены. Кажется, отпустило. 
Копирую все на другой сервер, стопаю машину (она уже кричит о неисправности дисков и каких-то других критических проблемах), возвращаю настройки *.vmx назад и копирую файлы обратно на рабочую машину. Ура.


Заключение


Эта история научила меня нескольким золотым истинам, которые так и не удалось до этого понять.


Во-первых, бекапить все всегда и везде и не на диск внутри виртуалки, как я делал до этого. Надо иметь один, а то и два бекапных диска, чтобы не было такого двухдневного простоя. (удалились файлы? Откатываемся, копируем файлы из бекапа, и простой — не 48 часов, а часа 2 от силы)
Во-вторых, не делать ничего на тяжелую голову в час ночи (уйдя бы спать, я бы с чистой головой в пятницу пришел бы к другому выходу, а не наломал дров во втором часу ночи)
В-третьих, не делать какие-то важные поправки в рабочие машины. Накатать вторую виртуалку, там сделать снапшот, потом сделать parent-диск основным и посмотреть, что будет после — вот как надо было делать. 
Ну и в-четвертых, делать еще больше бекапов. Не просто ВМ, но и самой esxi в целом.


P.S. ресурсы, которые в конце-концов мне помогли:


Тот самый форум с потрясающим apavlyuchenko (мы не знакомы, если что)


Страница на knowledge base от вмваре с описанием моей проблемы и путях ее решения


Картинка, которую я использовал


если кому-то интересно, в комментариях смогу оставить те ресурсы, статьи которых мне не помогли 




P.S.S




К сожалению, проблема исчезания места по-прежнему актуальна. Если у вас есть мысли или желание помочь мне разобраться с этим, прошу в комментарии. Мы можем там поговорить об этом. 
Или если вы знаете другой способ восстановления файлов из дисков снапшотов и тоже хотите им поделиться, то мне будет интересно это прочитать. Спасибо

Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 103

    0
    Во-первых, бекапить все всегда и везде и не на диск внутри виртуалки, как я делал до этого. Надо иметь один, а то и два бекапных диска, чтобы не было такого двухдневного простоя.

    Наверное К.О. — бекапить нужно на отдельные физические диски прочитать с которых можно при железной поломке оборудования где они стоят. Бекапов должно быть несколько за последнее время (сделанных в разное время), и должны быть долгохранимые бэкапы. Ну и мест хранения возможно несколько — одно для быстрого восстановления (возможно только одна, две версии бэкапа), другое для долгохранимых бэкапов, и другое для партии последних бэкапов.
    Ну и свободное места, его динамику и причину роста размера нужно контролировать всегда, особенно когда приходится удалять другие данные.

      0
      Был бы бюджет на raid, долгохранимые бэкапы и вот-это-все… А так приходится обходиться тем, что есть. :)
      Например, сейчас настроил rshapshot на убутну сервере… Эдакая альтернатива TM на macos. Очень удобная вещь.
      Ну и саму esxi стоит бекапить, правда пока где и чем — не знаю… Буду думать
        0

        Начните с малого — отдельного HDD или места HDD другого компьютера.

          0
          Так уже и есть. Бекаплю все на внешний hdd))
            0

            Лучше иметь два разных места хранения на случай… случаи разные бывают ;)


            И при наличии времени лучше отработать на тестовой машине под письменную запись восстановления из бэкапов. Это помогает.

              0
              Придется еще sata to usb покупать.
              А лучше все перенести на другую материнку и сделать там raid… эх, деньги-деньги)))
                0
                RAID и бэкап — вещи очень разные. Если на физической машине в результате пробоя блока питания 220В попадут в цепь +5В, то они окажутся в том числе на всех дисках машины и выведут их из строя; возможно, необратимо. Поэтому не надо смешивать эти вещи.
                  0
                  хорошо.
                  тогда будут отдельные юсб-диски
          0

          Veeam. Есть беплатные решения.

            0
            спасибо, я обязательно ознакомлюсь
              0
              На vSphere не работает.
                0
                Зато работают стандартные скрипты типа ghettoVCB и busybox для связи с внешним миром. В принципе, этого хватает для закрытия всех базовых потребностей.
            0
            Ну и правило 3-2-1.
            0
            А зачем вообще создавать надолго снепшоты? Какой use case?
            Я могу понять во время настройки чего-то иметь возможность откатиться — ценно, но при вводе в продакшен — зачем держать снимок? Точно так же можно случайно на него откатиться и привет. Плюс скорость работы с диском падает при их наличии. Плюс убивать развесистый снепшот долго и тяжко.
            В общем IMHO имеет смысл это для онлайн бекапа и только на время этого бекапа. Либо для экспериментов, но тогда без ценных данных. Тестовые машины, эталонные сервера…
              0
              Это я понял после того, как все поломал.
              Для начала была мысль «снапшоты, классно — откачусь, если все нае… сломается..» Ну, в общем, оно и сломалось в итоге…
                0
                Снэпшоты, по большому счёту, должны быть табу в продакшн-среде.
                Это не бэкап. Я даже помню что-то типа статьи от, кажется оракла с капсом в заголовке, что-то вроде «Snapshots are NOT BACKUPS».
                Здесь ничего необычного нет — нужно ознакомиться с документацией до изменений на проде.
                  0
                  спасибо
                    0
                    вы вообще-то не поняли. снепшот нужен, что бы сделать онлайн бекап. и после оного сразу же удалиться. откуда вы взяли, что я говорил Snapshots are BACKUPS — я лично не очень понимаю
                  0
                  Я бы на вашем месте смотрел в сторону Proxmox'a или oVirt'a вместо ESXi (который очень ограничен в бесплатной версии). Proxmox и oVirt являются так же решениями Enterprise уровня, и дадут полное представление о гипервизорах и навыки для работы с гипервизорами.
                    0
                    Уже читал о Proxmox и думал о переходе на него.
                    Но не знаю, как vmdk мигрировать на эту систему (вики на странице Proxmox пугает, я все никак не решусь на нее зайти второй раз)).
                    Да и к тому же мне правда лень заниматься опять переносом. Это же ведь поднять винду, потом на нее забекапить диск на всякий случай, после как-то на этой же винде перенести vmdk на виртуальный proxmox, после поднять proxmox на рабочем сервере и после перенести с виртуалки на сервер с proxmox`ом рабочую ВМ…
                    ох…
                      0
                      Один раз сделаете и забудете, а т.к. PVE крутится на Debian, то все настройки ОС можно делать как угодно.
                      У самого на HP Gen 8 крутится Прося, на второй работе тоже. Сейчас и вовсе затеял на Селерон J1900 поставить PVE, вогнать в кластер и повесить туда малотребовательные LXC.
                      + Proxmox — Если нет подписки, то есть форум, где ответят на вопрос либо кодеры, либо знатоки.
                        0
                        PVE, LXC, если не затруднит, можете расшифровать?))
                        А так… В принципе, наверное, это и будет выходом.
                        Так как все равно у меня остался thin, и пока доступно 70гб. Но энивей пространство будет уменьшаться…
                        Видимо, в скором времени пойду отрубать сервер и переезжать на proxmox (или pve. что это?)
                          0
                          PVE -> Proxmox Virtual Environment(он же Proxmox)
                          LXC -> Linux Container

                          oVirt в плане масштабируемости неописуем, но мой мозг не осилел установку типо hosted (когда хост выступает и как центр управления, и как сервер виртуализации. В обычном варианте предполагается, что у Вас есть две машины, одна из которых будет веб-мордой, а вторая гипервизором)

                          + На PVE без проблем запустил Xpenology без всяких флешек. В качестве загрузчика был просто прописан файл). После виртуалки клонированы без проблем.
                            0
                            Спасибо за расшифровку!
                            Думаю, oVirt пока не мой уровень (второй сервер есть, но на нем чистая убунту сервер на случай «а если шо отвалится»). А так — proxmox, о нем уже много кто говорит. ПОйду ставить
                        0
                        Формат vmdk на данный момент поддерживается Proxmox «из коробки». Загляните сюда — тынц, возможно это развеет Ваши сомнения.
                          0
                          ухты-ухты-ухты!!! Это что, я бегу на флешку накатывать проксмокс и пробовать его?
                          Правда этот пункт меня смущает
                          Использование vmdk на постоянной основе не рекомендуется, данный формат самый медленный в Proxmox, поэтому он годится лишь для выполнения миграции, не более. Вероятно в обозримом будущем этот недостаток будет устранен.

                          Несмотря на ССД, все равно как-то надо будет «адаптировать»(?) его под среду proxmox, но как это сделать только с одним рабочим диском — непоня-я-я-ятно…
                            0
                            Рекомендую преобразовать vmdk в qcow2 и смело его использовать.
                            Делается одной командой:
                            qemu-img convert -f vmdk test.vmdk -O qcow2 test.qcow2
                              0
                              то есть план действий такой: заводим proxmox на usb, предварительно на esxi заведу вторую виртуальную машину, тестовую
                              настраиваю proxmox, после говорю ему преобразовать тестовый диск вм в его формат и смотрю, все ли работает. так?

                              а что, если захочется переехать обратно? это же не обратная совместимость…
                                0
                                Да, можно и так попробовать. Обратно тоже можно переехать, правда я такого сам еще не пробовал. При помощи той же утилиты qemu-img конвертируете обратно в vmdk и с помощью vmkfstools делаете его совместимым с ESXi. Обсужалось на StackOverflow. В любом случае сделайте бэкап и попробуйте.
                                  0
                                  Спасибо огромное!
                                  Пойду накатывать proxmox (обсуждение этого есть в треде ниже))
                                    0
                                    Напишите потом о своих впечатлениях.
                                      0
                                      Конечно, хорошо.
                                      Вопрос из оффтопика. Вы работаете в selectel? Занимаетесь сис.администрированием? Вдохновился вашими постами, особенно об устройстве Московского ЦОДа.
                                      Можно на экскурсию к вам?)
                                        0
                                        Давайте в ЛС, дабы не засорять комментарии.
                                        0
                                        Сейчас он поставит проксмокс и вообще не найдет файлов образов, потому что там Thin LVM. А чтобы переключиться на обычную работу с образами, нужно двигать LVM-разделы, что для новичка окажется полной магией.
                                          0
                                          Ага, я новичок.
                                          И пока мало чего понял из вашего сообщения.
                                          Что двигать, куда?)) Проблема как раз таки в том, что thick я не могу сделать (об этом написал в статье)

                                          То есть будучи на чистом ubuntu server c диском, отформатированным в exfat-4, я имел где-то 223.8 гб места на ssd. Переезжая на esxi и форматируя диск в их непонятный ни для чего формат, я потерял всего 300мбайт, но именно из-за них я не смог сделать thick диск, который мне (впоследствии так оказалось) был так нужен.
                                            0
                                            Почитайте книжку, даже на русском
                                            onreader.mdl.ru/MasteringProxmox.2ed/content/Ch04.html
                                            Другое дело, чтобы понять о чем там не в теории, а на практике, нужна уже где-то установленная система.
                                            По поводу миграции систем, если есть одновременно работающая система и гипервизор, то проще всего переносить систему через clonezilla напрямую через сеть без промежуточных образов.
                                            Для переноса системы с минимальным простоем можно использовать disk2vhd, рабочую машину можно не останавливать, а с образом потом можно по всякому работать.
                                            Хотя везде могут быть нюансы, если изначально система загружалась в режиме UEFI, то при переносе в виртуалку она может перестать загружаться.
                                              0
                                              да, UEFI.
                                              простой не так важен, даунтайм может расти.
                                              вот к сожалению без промежуточных образов никак, как и с чем-либо еще.
                                              нужно перенести esxi с машины на эту же машину, на которой нужно настроить PVE. и с тем же ssd
                                              то есть видимо где-то все-таки нужно будет оставить на всякий случай файлы с esxi. если что-то пойдет не так…
                                            0
                                            Выше дана рекомендация конвертнуть файл в qcow2 формат, который хранится только в виде блочного файла, потому Thick не будет задействован.
                                            И вообще LVM Thick ужасен в быстродействие/занимаемом месте.
                                            Игрался с ним, прелесть только в Снапшотах для Proxmox (про eSXI не скажу). В остальном — сразу падала производительности по сравнению с обычным LVM. А в случае чистки смонтированного thick, места больше не становилась, т.к. часть инфы прописывается в meta. Как решение — создавать новое thick устройство и старое удалять.
                                              0
                                              Я вот пробовал чистить свой thin, и очистилось не больше 5гб, черт побери…
                                              Стоп, а если я перееду на proxmox со своими thin дисками, я смогу там провернуть qemu-img convert -f vmdk test.vmdk -O qcow2 test.qcow2?
                                              Или я могу создать просто две тестовые ВМ — одну на thick, другую на thin и там уже протестировать, получится или нет…
                                              0

                                              Thin LVM довольно стрёмная штука. Если надо thin, то лучше ZFS брать, где всё это работает.

                                                0
                                                я вообще решил отказаться и все в thick перевести.
                                                от греха, как говорится…
                                    0
                                    Мои рекомендации — ставить Debian, а после накатывать Оболочку по инструкции — Proxmox Debian Stretch)

                                    Proxmox Installer поддерживает только ZFS Raid. Так и не смог победить его из за высокого I/O.
                                    У себя гипервизор вообще на Micro SD стоит, на второй работе debian установлен на mdraid
                                      0
                                      ах, вот и первые трудности
                                      у меня esxi крутится на флешке, и это очень удобно.
                                      а тут как? сначала на флешку дебиан, а после — proxmox?
                                      иначе, как я понял, на сервере, собранном на коленке, у меня ничего не запустится? (рейда, что ожидаемо, у меня нет)
                                        0
                                        Можно поставить Дебиан на флешку и поверх накатить Proxmox. Только соответственно подготовить отдельно раздел для свопа и логов на каком нибудь hdd, а то флешка прикажет долго жить.
                                        У самого система крутится на micro sd :)

                                        В случае успеха и при желании изучать LXC сразу рекомендую обратить внимание на Alpine Linux (весит добро не более 5мб)
                                          0
                                          Да что же такое LXC?
                                          Darksa использовал в комментарии этот термин, вы тоже. а что это — мне непонятно)
                                          Но спасибо, пойду… экспериментировать, по всей видимости)
                                            0
                                            Выше давал ответ, что такое LXC. Если простым языком, то это типо аля Docker, но здесь выступает полноценный самостоятельный Linux любой доступной редакции.
                                            У меня тдельно каждый контейнер под каждый сервис — dnsmasq, nginx, plex, transmission. Ибо если что то и грохнется, то одно, а не все скопом.
                                            Потихоньку перевожу все на Alpine из за легковесности онной.
                                              0
                                              а LXC != PVE?
                                              Просто если так, то что выбрать — первое или второе?
                                                0
                                                PVE это система управления виртуализацией, если вдоваться в подробности. Позволяет управлять виртуальными машинами, контейнерами, всякие бэкапы, снапшоты.
                                                Сама же виртуализация реализована при помощи QEMU для машин и при помощи LXC для контейнеров.
                                                Потому да, LXC != PVE, т.к. PVE это только Management
                                                  0
                                                  Моя рекомендация. Не сочтите за рекламу. На arubacloud за 1 евро можно заказать полноценный VPS на KVM.
                                                  Заказать Дебиан 9, сделать Снапшот и поставить после Proxmox и поразвлекаться удаленно.
                                                  В дальнейшем сгодится как забугорный VPS. (Сам остановился на голом Дебе, поставил lxc и веб-панель к lxc)
                                                    0
                                                    Я уже на каком-то зарубежном хостинге арендую vds для прокси.

                                                    А для тестов использую третий, старый шумный ibm`овский 1U сервер)) Но чую, что пока остановлюсь на PVE — так проще, чем еще погружаться в LXC…

                                                    (господи, как же много всего на свете… и как мало я знаю))
                                                0
                                                LXC это, грубо говоря, изолированный контейнер. Все запущенное в контейнере будет исполнено на ядре хоста. Не рекомендую использовать, т.к. в отличие от старого доброго OpenVZ полно багов.
                                                  +1
                                                  Увы, от OpenVZ из коробки разрабы отказались. Сам с этим дело не имел. Но на текущий момент lxc более менее устраивает. Либо все решается ращрабами, либо гуглеж.

                                                  У самого яркий пример, что Дебиан, ЦентОС контейнер нормально работали с кастомным профилем AppArmor, Арч нет. Перешёл на Alpine пока тех же граблей нет.
                                                    0
                                                    Спасибо за расшифровку!
                                        0
                                        Вот уже 2 года пользуемся proxmox… И вот я бы не стал переходить на него с esxi в вашем случае (одинокий хост, не требуется API управления хостом). Ибо proxmox «это не энтерпрайз», вот прям совсем и ставить 24/7 сервисы на него я бы поостерегся.
                                        Мой опыт работы с esxi показал что это удивительно стабильная и неубиваемая система, если сначала немного почитать RTFM и HWL, что вы не сделали, ибо в любой статье про снапшоты обязательно хотя бы 1 раз упоминают в чем опасность их использования. Про типы дисков аналогично — коварство thin дисков обязательно упомянут.
                                        ProxMox это конечно интересная система, с большим функционалом, превосходящим голый ESXi, но без чтения RTFM по LVM, qemu-kvm и прочим приблудам которые в нем есть — можете поймать значительно более серьезные проблемы на ровном месте. В общем постоянно что-то приходится по нему гуглить
                                          0
                                          Ибо proxmox «это не энтерпрайз»
                                          Это значит его нестабильность, раз вы указали
                                          24/7 сервисы на него я бы поостерегся.
                                          Верно?

                                          почитать RTFM и HWL
                                          Если не сложно, можете расшифровать эти понятия?

                                            0
                                            То есть ваш вердикт: оставайся на esxi и попробуй решить проблему тонких дисков? нефиг тебе лезть в PVE, ты и так еще с esxi не до конца разобрался?

                                            (в принципе, я так тоже думал. но товарищи из треда выше уверили, что PVE — лучше есхи)
                                              0
                                              не совсем. скорее «если уж вкусил возможности и стабильность ESXi, то откатываться на проксмокс может быть больно»
                                                0
                                                но можно протестировать его на еще одном сервере…
                                                в общем, пойду смотреть, думать. хотя все-таки (последний комментарий от nikos7 указал на плюс тонких дисков) мне что-то по душе остаться на есхи
                                              0
                                              Вы два года пользуетесь proxmox, но для вас «это не энтерпрайз», можно узнать почему?
                                                0
                                                Тут иногда вылезают ошибки из ничего, одни из самих забавных — перестают запускаться виртуалки или контейнеры (не помню как решил), бывают проблемы с сеткой ну и т.п. Некоторые как ни странно удалось решить только перезагрузкой хоста (понимаю что не спортивно, но гугл молчал, а в линуксе так глубоко лезть не было времени). На том же esxi я не словил(хотя скорее не помню) за много лет ни одного глюка
                                                  0
                                                  Странно.
                                                  Ошибки не запуска систем, это обычно или нет кворума в кластере, или предыдущая команда к этой виртуалке не завершилась и ждет какого-то тайм-аута.
                                                  Проблемы с сетью бывают обычно, если что-то изменить на хосте в настройках сети. Еще бывают глюки с virtio-драйверами, что в винде (раз в полгода может зависнуть интерфейс какой-нибудь), что в линуксе, например, в гугле полно virtio network ubuntu bug.
                                                  Еще пару лет назад наткнулся на волшебную ситуацию на Dell PowerEdge R720.
                                                  Стоял несколько лет проксмокс 3 версии, работал, есть не просил. Для объединения в новый кластер решили обновить до 4 версии. Обновились ночью, все запустилось сразу и с полпинка. С утра начались глюки с сетью на хосте. Через некоторое время гипервизор не пингуется, а виртуалки нормально работают. Кое-как мигрировали следующей ночью. Начали копать, глюк в драйвере igb для сетевой карты, пересобирали драйвера, меняли версию ядра. Даже откатывались на 3 версию проксмокса на старый образ с iso без новых обновлений, сеть отваливается. Как будто в новом linux-ядре драйвер что-то изменил в firmware-сетевой карты. firmware перепрошивали, с ethtool игрались, бестолку. Помогла только замена сетевой карты.
                                                  В общем и целом все глюки сетевой — чисто линуксовая специфика. VMware, после установки просто скажет, не хочу работать с этими сетевыми картами, ставьте драйвера на свой страх и риск.
                                                  вот, нашел инфу по самой первой виртуалке
                                                  systeminfo.txt от 2013 года
                                                  Host Name: KVMSRV-1
                                                  OS Name: Microsoft® Windows® Server 2003, Enterprise Edition
                                                  OS Version: 5.2.3790 Service Pack 2 Build 3790
                                                  OS Manufacturer: Microsoft Corporation
                                                  OS Configuration: Member Server
                                                  OS Build Type: Uniprocessor Free
                                                  Registered Owner: name
                                                  Registered Organization:
                                                  Product ID: 69713-650-9188916-453хх
                                                  Original Install Date: 30.09.2010, 17:56:16
                                                  System Up Time: 5 Days, 8 Hours, 29 Minutes, 30 Seconds
                                                  System Manufacturer: Bochs
                                                  System Model: Bochs
                                                  System Type: X86-based PC
                                                  Processor(s): 1 Processor(s) Installed.
                                                  [01]: x86 Family 6 Model 2 Stepping 3 GenuineIntel ~2266 Mhz
                                                  BIOS Version: BOCHS — 1


                                                  а вот текущий статус
                                                  Host Name: KVMSRV-1
                                                  OS Name: Microsoft® Windows® Server 2003, Enterprise Editi
                                                  on
                                                  OS Version: 5.2.3790 Service Pack 2 Build 3790
                                                  OS Manufacturer: Microsoft Corporation
                                                  OS Configuration: Member Server
                                                  OS Build Type: Multiprocessor Free
                                                  Registered Owner: user
                                                  Registered Organization:
                                                  Product ID: 69713-650-9188916-455хх
                                                  Original Install Date: 06.03.2014, 19:44:35
                                                  System Up Time: 18 Days, 2 Hours, 4 Minutes, 16 Seconds
                                                  System Manufacturer: QEMU
                                                  System Model: Standard PC (i440FX + PIIX, 1996)
                                                  System Type: X86-based PC
                                                  Processor(s): 4 Processor(s) Installed.
                                                  [01]: x86 Family 15 Model 6 Stepping 1 GenuineIntel ~
                                                  2599 Mhz
                                                  [02]: x86 Family 15 Model 6 Stepping 1 GenuineIntel ~
                                                  2599 Mhz
                                                  [03]: x86 Family 15 Model 6 Stepping 1 GenuineIntel ~
                                                  2600 Mhz
                                                  [04]: x86 Family 15 Model 6 Stepping 1 GenuineIntel ~
                                                  2599 Mhz
                                                  BIOS Version: BOCHS — 1

                                                  видимо при переносе в 2014 году Original Install Date обновился. 2003 end of support, but who cares
                                                  Уже почти 8 лет прошло. Как же давно это было…
                                                    0
                                                    Собственно вы и обрисовали типичный proxmox кластер :) То есть не просит и радуется родителей, то голову ломаешь что же ему не нравится. С вмваре имхо как-то попроще.
                                                    С вмваре однажды попали на мощный глюк — сетка могла неожиданно упасть в смерть(например когда сервер включался, еще до биоса). Долго искали проблему, потом наконец документацию HWL Вмвари почитали вдумчиво, разобрались с драйверами вендора, сравнили документации и выравняли версии фирмвари и дров и все работает как часы с тех пор. Но это было практически единственное что было неприятное c VMware.
                                          0
                                          Знакомый посоветовал ESXi как бесплатное решение для небольших серверов (мой случай: 1 процессор + всего 8 GB RAM). Процесс переезда осложнялся тем, что надо было сначала на windows-компьютере поднять vmware workstation вместе с vmware converter

                                          да?
                                          ещё

                                          Я чет ни одного бесплатного слова не нашел :(

                                          так не делать
                                            0
                                            Я имел в виду как раз бесплатный лицензионный ключ.
                                            Кажется, там есть ограничение в 2 камня и 32ГБ оперативки
                                            image
                                              0
                                              Платные — сфера и подобные утилиты. Чистый ESXi хост бесплатен, если у тебя 1 проц в сервере.
                                                0
                                                у меня 1 камень))
                                                  0
                                                  Да вроде бы неважно сколько процов. Просто в одну виртуалку оно больше 8 ядер в бесплатной версии не выдаст.
                                                    0
                                                    да оно мне и не надо больше
                                                      0
                                                      Речь как бы и совсем не о вас идет ;)
                                              0
                                              это же unix система.
                                              du -h --max-depth=1 /

                                              и по чуть искать где все место +)

                                              ну и глянуть не висят ли занятые файлы для удаления =) lsof -lXs |grep deleted или перезагрузить ESXi =) если перегружали то это не про вас
                                                0
                                                Если виртуалка весит 100 ГБ, ты делаешь снепшот, то вот уже максимальный размер виртуалки со снепшотом стал близок к 200 ГБ. А если снепшотов много, то еще плюс дельта изменений между ними.
                                                  0
                                                  к сожалению, об этом я подумал только после создания снапшота
                                                  0
                                                  1. Никогда не используй снапшоты, именно из-за них система и разрастается.снапшоты зло, если не знать для чего они нужны.
                                                  2.Для бесплатного esxi, существует прекраснейший скрипт для бэкапов «ghettoVCB».как им пользоваться статей полно.и самое главное при бэкапе он сжимает vmdk диск до реально занимаемого кол-во данных.
                                                  3.Сжать диск нельзя стандартными средствами не thin, не thick, у тонкого лишь один минус перед толстым, это в быстродействии.да и то незначительно.
                                                  Но сжать диски можно, это не проблема, и диски можно так же легко конвертировать из одного в другой.
                                                  4. вытащить данные из vmdk можно ещё при помощи HPE VM Explorer
                                                  Ну и чтобы хотелось добавить, что бесплатный ESXi+GhettoVCB, это прекраснейший гипервизор для небольшой организации, если не требуются HA, vmotion и т.д.
                                                  Если что пиши, любой вопрос по esxi подскажу как что лучше сделать!)
                                                    0
                                                    1. никогда-никогда больше в жизни, это точно
                                                    2. спасибо, посмотрю в его сторону (хотя уже в тредах выше думаю о переезде на PVE)
                                                    3. да? хорошо. не знал. а конвертировать как? я вот не могу, ибо у меня выскакивает ошибка «недостаточно места» (из тонкого в толстый)
                                                    4. а эта утилита вытаскивает информацию с дисков снапшотов? потому что вытащить инфу из корневого диска у меня то получилось, но на тот момент она была за 30 июня…
                                                    обязательно, если будут какие-то вопросы, вам напишу. спасибо :)
                                                    0
                                                    1.Ну вообще снапшоты полезная вещь, если проводите эксперименты над ос, то тут на помощь приходят снапшоты.
                                                    2.на мой чисто субъективный взгляд, переезд только либо на esxi, либо на Hyper-v от Microsoft.(если у вас всего один сервак, то самое надёжное и легко восстановляемое это esxi)
                                                    3.для начала его необходимо сжать, чтобы освободить место на datastore, а затем конвертируется он простым щелчком правой кнопкой мыши по диску.
                                                    Главное ответить себе на вопрос, зачем вам нужен именно тонкий диск? ведь тем более при наличии ssd, разница в скорости между ними ощутима не будет. и при ограниченном объёма datastore, выгоднее использовать именно тонкий диск.
                                                    4.Не могу точно сказать, уже не припомню
                                                      0
                                                      1. это да, я так делал. но в данном случае снапшоты были как гарант безопасности, т.е. как обычный бекап. видимо я ошибался
                                                      2. сейчас я на esxi. почему считаете, что стоит оставаться на ней?
                                                      3. да, у меня ограниченное место. но именно из-за тонкого диска у меня все и поломалось. разве не удобнее использовать толстый, чтобы сразу ограничить место и сказать «вот у тебя есть 150гб, ты не можешь выходить за рамки этого места»?
                                                        0
                                                        1. ошибались, снепшоты в качестве бекапов имеют очень ограниченную применимость. только кейс «сделал снапшот, внутри ОС провел опасные действия(обновление, специфические действия), убедился что работает, удалил снапшот».
                                                        2. потому что стабильно, быстро и функционально
                                                        3. тонкий диск хорош, когда у Вас много виртуальных систем на одном диске. можно выделить больше места, чем реально есть. когда у Вас одна виртуалка то смысла нет никакого.
                                                    0
                                                    Если нет бекапов, а все сломалось, то перед тем как заниматься лечением хорошо бы сделать бекап текущего состояния (т.е. полную копию диска). Полно ситуаций, когда лечение наносит несравнимо больший вред данным, чем болезнь от которой лечили.
                                                    Но этот совет неприменим, если проблема связана с неисправностью диска.
                                                      0
                                                      А какая версия ESXi и VMFS использовалась у вас?
                                                        0
                                                        6.5, кажется.
                                                        самая последняя в общем
                                                        0
                                                        2.Ну это моё чисто субъективное мнение, сложившееся исходя из использования esxi уже более 5 лет, и с ним если и были какие-то проблемы, то только из-за неправильной эксплуатации вроде вашей)а так с накопленным опытом, он превращается в удобную и неубиваемую систему.
                                                        3. У вас поломалось всё не из-за тонкого диска, а опять же, а из-за неправильного его использования. А проблема у вас из-за того что вы в самой OS, которая установлена в вашей VM, указали размер диска превышающий ваш реальный размер, а тонкий диск и растёт само собой. а если вы изначально в OS сделаете раздел 150 гб, то система не разрастётся, а упрётся в ограничения.посмотрите размер вашего раздела который вы создали, вы там явно указали размер больше доступного, вот вам и результат.
                                                        Преимущество тонкого диска, в том что вы всегда сможете его расширить при необходимости и занимает он реально, столько сколько вы на него записали, а это огромный плюс при ограниченном пространстве.
                                                        Какая у вас стоит OS на VM?
                                                        у вас возможно остался мусор в виде старых снапшотов, которые уже не используются, тем самым отнимая место.
                                                          0
                                                          3. а ведь действительно, я не подумал. в ubuntu server 16.04 стоит кажется 223.8, а размер диска в самой esxi 223.5… у меня занято порядка 120гб, можно сейчас УРЕЗАТЬ максимальный объем в ubuntu server?
                                                          вот, теперь я доступно и понятно понял преимущество thin… действительно удобно, спасибо.

                                                          мусор со снапшотами я примитивно удалил, сделав rm -rf ?-*.vmdk где? — название диска
                                                            0
                                                            «примитивно rm -rf» можно делать только когда вы точно понимаете что и для чего вы делаете. во всех остальных случаях не надо так.
                                                            посмотрите на предмет логов. лежат в папке с машиной, называются vmware-?.log и могут занимать изрядно места
                                                            так же в условиях недостаточного места можно отключить динамическое выделение памяти: галочка reserve all guest memory. Ставите, перезапускаете виртуальную машину. После этого можно удалить *.vswp
                                                              0
                                                              кажется, тогда я понимал, что и зачем удаляю.

                                                              логи в совокупности весят не больше 200мб.

                                                              по поводу reserve… а как это влияет? что за динамическое выделение памяти?
                                                              сейчас у меня так



                                                                0
                                                                при установке этой галки виртуалка съест сразу всю оперативную память, назначенную ей. соответственно Вы не сможете назначить всем виртуалкам, расположенным на этом гипервизоре памяти больше, чем есть на физической машине. Без галки же можете, и нехватка будет компенсироваться из того самого свопа.
                                                                  0
                                                                  а своп может увеличиться (как я вижу, это позиция limit)?
                                                                  и это, как я понимаю, своп именно на уровне esxi. то есть тот своп, что я использовал раньше в убунту сервере (в ВМ) не то же самое, что своп на уровне esxi?
                                                                    0
                                                                    Этот своп по размеру равен назначенной оперативной памяти ВМ. Туда вытесняется гостевая память при нехватке физической хостовой, и соответственно больше чем выделено гостевой туда выдавлено быть не может. Да, этот своп на уровне ESXi, и гостевая система о нём ничего не знает.
                                                                    Позиция limit позволяет задать порог, после которого память будет выдавливаться в своп. Unlimited значит что это будет происходить при исчерпании физической памяти. любое другое значение — память будет убираться в своп при достижении этого лимита, независимо от наличия свободной памяти на хосте.
                                                                      0
                                                                      ага… но при этом по-прежднему, если я выделю ВМ 5gb RAM (которая настоящая память, не своп), то в метрике будет отображаться 5 гигов, даже если их по-факту 10 (на уровне esxi 5gb ram + 5 swap), так?
                                                                      а вообще, штука удобная… не хочется отключать, тем более я выделил ВМ памяти меньше, чем надо.
                                                                      да и 5гб ПОКА ЧТО не так критично
                                                                        0
                                                                        если ВМ выделено 5gb RAM, то вм может использовать именно 5gb RAM. И ВМ при этом будет уверена, что вся память физическая. На уровне ESXi же будет либо 5Г физической, либо 3 физической и 2 свопа, либо… суммарно всегда будет занято 5. а соотношение физическая-своп определяется из параметра LIMIT и реально доступной на хосте RAM. В случае если на хосте 8gb RAM, а виртуалка одна, и выделено ей 5gb, и лимиты не установлены, своп использоваться не будет
                                                                          0
                                                                          то есть в теории я могу выделить ВМ 32гб оперативной памяти, а по факту у меня будет 8 RAM физической и еще 24 из свопа на ссд (правда будет ли это эффективно..)
                                                                          кстати, может, вы мне сможете растолковать: использовать своп на ссд резонно? он быстрый? точнее, можно ли на нем «прожить»? используя ВМ нормально, без последствий и фризов и т.п.
                                                                            0
                                                                            в теории да, но как только реально использованная виртуалкой память попадёт в своп, работать будет печально.
                                                                            Нет, своп, тем более на бытовых ssd, использовать в обычной жизни не стоит. работать будет очень медленно, да и на времени жизни ssd это скажется негативно. Своп нужен, чтобы пережить кратковременные всплески потребления без болезненных последствий.
                                                                              0
                                                                              спасибо за пояснение. теперь буду знать, когда и в каких случаях его настраивать
                                                          0
                                                          Думаю, проблему thin-дисков описывать не надо (если вкратце, то они после расширения своего пространства его не «сужают» в обратную сторону. они так же могут выйти за пределы физического количества памяти на диске).

                                                          Говоря честно и откровенно, это не проблема thin-дисков, это скорее всего проблема настроек (ну и ограничений ESXi) — при разрешенном unmap внутри guests и выполнении ряда условий всё отлично должно «сжиматься» (подробней тут: www.codyhosterman.com/2016/11/whats-new-in-esxi-6-5-storage-part-i-unmap).

                                                          Выйти за пределы они могут только если имеет место быть overcommit, если же сумма всего выделенного пространства для thin-дисков не превышает физического, то этого, разумеется, не случится. Overcommit это зло, кроме редких изолированных случаев.
                                                            0
                                                            ну вот у меня изначально что-то пошло не так…
                                                            поэтому видимо все редкие изолированные случаи — мои)))
                                                            0

                                                            «Эта история научила меня нескольким золотым истинам, которые так и не удалось до этого понять.»…
                                                            К сожалению, эта история не научила автора одной простой истине — читать документацию. Ее много, как официальной, так и от сторонних авторов (есть и на русском). Увы, но с таким подходом замена ESXi на Proxmox (как советовали выше), не поможет.

                                                              0
                                                              тоже верно, документация для этого и создается.
                                                              но что-то я люблю бегать впереди паровоза и наступать на грабли :)
                                                              0
                                                              Вот классная книга Михаила Михеева тыц. Она хоть и про 5 версию, но из нее сможете узнать принцип работы гипервизора на уровне достаточном, что бы «не ходить по таким граблям».
                                                              0
                                                              Бу сервера HP покаления G6+ можно купить от 200 уе(без хдд), если коммерческая организация не может позволить себе даже такой сервер (как продакшен и второй сервер для хранения резервных копий) — пора задуматься о том что вы занимаетесь не своим делом…
                                                                0
                                                                это не коммерческая организация. а домашний сервер мой)
                                                                0

                                                                "exfat-4" — это что?

                                                                Only users with full accounts can post comments. Log in, please.