Comments 103
Во-первых, бекапить все всегда и везде и не на диск внутри виртуалки, как я делал до этого. Надо иметь один, а то и два бекапных диска, чтобы не было такого двухдневного простоя.
Наверное К.О. — бекапить нужно на отдельные физические диски прочитать с которых можно при железной поломке оборудования где они стоят. Бекапов должно быть несколько за последнее время (сделанных в разное время), и должны быть долгохранимые бэкапы. Ну и мест хранения возможно несколько — одно для быстрого восстановления (возможно только одна, две версии бэкапа), другое для долгохранимых бэкапов, и другое для партии последних бэкапов.
Ну и свободное места, его динамику и причину роста размера нужно контролировать всегда, особенно когда приходится удалять другие данные.
Например, сейчас настроил rshapshot на убутну сервере… Эдакая альтернатива TM на macos. Очень удобная вещь.
Ну и саму esxi стоит бекапить, правда пока где и чем — не знаю… Буду думать
Начните с малого — отдельного HDD или места HDD другого компьютера.
Лучше иметь два разных места хранения на случай… случаи разные бывают ;)
И при наличии времени лучше отработать на тестовой машине под письменную запись восстановления из бэкапов. Это помогает.
А лучше все перенести на другую материнку и сделать там raid… эх, деньги-деньги)))
Veeam. Есть беплатные решения.
Я могу понять во время настройки чего-то иметь возможность откатиться — ценно, но при вводе в продакшен — зачем держать снимок? Точно так же можно случайно на него откатиться и привет. Плюс скорость работы с диском падает при их наличии. Плюс убивать развесистый снепшот долго и тяжко.
В общем IMHO имеет смысл это для онлайн бекапа и только на время этого бекапа. Либо для экспериментов, но тогда без ценных данных. Тестовые машины, эталонные сервера…
Для начала была мысль «снапшоты, классно — откачусь, если все нае… сломается..» Ну, в общем, оно и сломалось в итоге…
Это не бэкап. Я даже помню что-то типа статьи от, кажется оракла с капсом в заголовке, что-то вроде «Snapshots are NOT BACKUPS».
Здесь ничего необычного нет — нужно ознакомиться с документацией до изменений на проде.
Но не знаю, как vmdk мигрировать на эту систему (вики на странице Proxmox пугает, я все никак не решусь на нее зайти второй раз)).
Да и к тому же мне правда лень заниматься опять переносом. Это же ведь поднять винду, потом на нее забекапить диск на всякий случай, после как-то на этой же винде перенести vmdk на виртуальный proxmox, после поднять proxmox на рабочем сервере и после перенести с виртуалки на сервер с proxmox`ом рабочую ВМ…
ох…
У самого на HP Gen 8 крутится Прося, на второй работе тоже. Сейчас и вовсе затеял на Селерон J1900 поставить PVE, вогнать в кластер и повесить туда малотребовательные LXC.
+ Proxmox — Если нет подписки, то есть форум, где ответят на вопрос либо кодеры, либо знатоки.
А так… В принципе, наверное, это и будет выходом.
Так как все равно у меня остался thin, и пока доступно 70гб. Но энивей пространство будет уменьшаться…
Видимо, в скором времени пойду отрубать сервер и переезжать на proxmox (или pve. что это?)
LXC -> Linux Container
oVirt в плане масштабируемости неописуем, но мой мозг не осилел установку типо hosted (когда хост выступает и как центр управления, и как сервер виртуализации. В обычном варианте предполагается, что у Вас есть две машины, одна из которых будет веб-мордой, а вторая гипервизором)
+ На PVE без проблем запустил Xpenology без всяких флешек. В качестве загрузчика был просто прописан файл). После виртуалки клонированы без проблем.
Правда этот пункт меня смущает
Использование vmdk на постоянной основе не рекомендуется, данный формат самый медленный в Proxmox, поэтому он годится лишь для выполнения миграции, не более. Вероятно в обозримом будущем этот недостаток будет устранен.
Несмотря на ССД, все равно как-то надо будет «адаптировать»(?) его под среду proxmox, но как это сделать только с одним рабочим диском — непоня-я-я-ятно…
Делается одной командой:
qemu-img convert -f vmdk test.vmdk -O qcow2 test.qcow2
настраиваю proxmox, после говорю ему преобразовать тестовый диск вм в его формат и смотрю, все ли работает. так?
а что, если захочется переехать обратно? это же не обратная совместимость…
Пойду накатывать proxmox (обсуждение этого есть в треде ниже))
Вопрос из оффтопика. Вы работаете в selectel? Занимаетесь сис.администрированием? Вдохновился вашими постами, особенно об устройстве Московского ЦОДа.
Можно на экскурсию к вам?)
И пока мало чего понял из вашего сообщения.
Что двигать, куда?)) Проблема как раз таки в том, что thick я не могу сделать (об этом написал в статье)
То есть будучи на чистом ubuntu server c диском, отформатированным в exfat-4, я имел где-то 223.8 гб места на ssd. Переезжая на esxi и форматируя диск в их непонятный ни для чего формат, я потерял всего 300мбайт, но именно из-за них я не смог сделать thick диск, который мне (впоследствии так оказалось) был так нужен.
onreader.mdl.ru/MasteringProxmox.2ed/content/Ch04.html
Другое дело, чтобы понять о чем там не в теории, а на практике, нужна уже где-то установленная система.
По поводу миграции систем, если есть одновременно работающая система и гипервизор, то проще всего переносить систему через clonezilla напрямую через сеть без промежуточных образов.
Для переноса системы с минимальным простоем можно использовать disk2vhd, рабочую машину можно не останавливать, а с образом потом можно по всякому работать.
Хотя везде могут быть нюансы, если изначально система загружалась в режиме UEFI, то при переносе в виртуалку она может перестать загружаться.
простой не так важен, даунтайм может расти.
вот к сожалению без промежуточных образов никак, как и с чем-либо еще.
нужно перенести esxi с машины на эту же машину, на которой нужно настроить PVE. и с тем же ssd
то есть видимо где-то все-таки нужно будет оставить на всякий случай файлы с esxi. если что-то пойдет не так…
И вообще LVM Thick ужасен в быстродействие/занимаемом месте.
Игрался с ним, прелесть только в Снапшотах для Proxmox (про eSXI не скажу). В остальном — сразу падала производительности по сравнению с обычным LVM. А в случае чистки смонтированного thick, места больше не становилась, т.к. часть инфы прописывается в meta. Как решение — создавать новое thick устройство и старое удалять.
Стоп, а если я перееду на proxmox со своими thin дисками, я смогу там провернуть
qemu-img convert -f vmdk test.vmdk -O qcow2 test.qcow2
?Или я могу создать просто две тестовые ВМ — одну на thick, другую на thin и там уже протестировать, получится или нет…
Thin LVM довольно стрёмная штука. Если надо thin, то лучше ZFS брать, где всё это работает.
Proxmox Installer поддерживает только ZFS Raid. Так и не смог победить его из за высокого I/O.
У себя гипервизор вообще на Micro SD стоит, на второй работе debian установлен на mdraid
у меня esxi крутится на флешке, и это очень удобно.
а тут как? сначала на флешку дебиан, а после — proxmox?
иначе, как я понял, на сервере, собранном на коленке, у меня ничего не запустится? (рейда, что ожидаемо, у меня нет)
У самого система крутится на micro sd :)
В случае успеха и при желании изучать LXC сразу рекомендую обратить внимание на Alpine Linux (весит добро не более 5мб)
Darksa использовал в комментарии этот термин, вы тоже. а что это — мне непонятно)
Но спасибо, пойду… экспериментировать, по всей видимости)
У меня тдельно каждый контейнер под каждый сервис — dnsmasq, nginx, plex, transmission. Ибо если что то и грохнется, то одно, а не все скопом.
Потихоньку перевожу все на Alpine из за легковесности онной.
Просто если так, то что выбрать — первое или второе?
Сама же виртуализация реализована при помощи QEMU для машин и при помощи LXC для контейнеров.
Потому да, LXC != PVE, т.к. PVE это только Management
Заказать Дебиан 9, сделать Снапшот и поставить после Proxmox и поразвлекаться удаленно.
В дальнейшем сгодится как забугорный VPS. (Сам остановился на голом Дебе, поставил lxc и веб-панель к lxc)
У самого яркий пример, что Дебиан, ЦентОС контейнер нормально работали с кастомным профилем AppArmor, Арч нет. Перешёл на Alpine пока тех же граблей нет.
Мой опыт работы с esxi показал что это удивительно стабильная и неубиваемая система, если сначала немного почитать RTFM и HWL, что вы не сделали, ибо в любой статье про снапшоты обязательно хотя бы 1 раз упоминают в чем опасность их использования. Про типы дисков аналогично — коварство thin дисков обязательно упомянут.
ProxMox это конечно интересная система, с большим функционалом, превосходящим голый ESXi, но без чтения RTFM по LVM, qemu-kvm и прочим приблудам которые в нем есть — можете поймать значительно более серьезные проблемы на ровном месте. В общем постоянно что-то приходится по нему гуглить
Ибо proxmox «это не энтерпрайз»Это значит его нестабильность, раз вы указали
24/7 сервисы на него я бы поостерегся.Верно?
почитать RTFM и HWLЕсли не сложно, можете расшифровать эти понятия?
(в принципе, я так тоже думал. но товарищи из треда выше уверили, что PVE — лучше есхи)
Ошибки не запуска систем, это обычно или нет кворума в кластере, или предыдущая команда к этой виртуалке не завершилась и ждет какого-то тайм-аута.
Проблемы с сетью бывают обычно, если что-то изменить на хосте в настройках сети. Еще бывают глюки с virtio-драйверами, что в винде (раз в полгода может зависнуть интерфейс какой-нибудь), что в линуксе, например, в гугле полно virtio network ubuntu bug.
Еще пару лет назад наткнулся на волшебную ситуацию на Dell PowerEdge R720.
Стоял несколько лет проксмокс 3 версии, работал, есть не просил. Для объединения в новый кластер решили обновить до 4 версии. Обновились ночью, все запустилось сразу и с полпинка. С утра начались глюки с сетью на хосте. Через некоторое время гипервизор не пингуется, а виртуалки нормально работают. Кое-как мигрировали следующей ночью. Начали копать, глюк в драйвере igb для сетевой карты, пересобирали драйвера, меняли версию ядра. Даже откатывались на 3 версию проксмокса на старый образ с iso без новых обновлений, сеть отваливается. Как будто в новом linux-ядре драйвер что-то изменил в firmware-сетевой карты. firmware перепрошивали, с ethtool игрались, бестолку. Помогла только замена сетевой карты.
В общем и целом все глюки сетевой — чисто линуксовая специфика. VMware, после установки просто скажет, не хочу работать с этими сетевыми картами, ставьте драйвера на свой страх и риск.
вот, нашел инфу по самой первой виртуалке
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
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 лет прошло. Как же давно это было…
С вмваре однажды попали на мощный глюк — сетка могла неожиданно упасть в смерть(например когда сервер включался, еще до биоса). Долго искали проблему, потом наконец документацию HWL Вмвари почитали вдумчиво, разобрались с драйверами вендора, сравнили документации и выравняли версии фирмвари и дров и все работает как часы с тех пор. Но это было практически единственное что было неприятное c VMware.
да?
ещё
Я чет ни одного бесплатного слова не нашел :(
так не делать
du -h --max-depth=1 /
и по чуть искать где все место +)
ну и глянуть не висят ли занятые файлы для удаления =) lsof -lXs |grep deleted или перезагрузить ESXi =) если перегружали то это не про вас
2.Для бесплатного esxi, существует прекраснейший скрипт для бэкапов «ghettoVCB».как им пользоваться статей полно.и самое главное при бэкапе он сжимает vmdk диск до реально занимаемого кол-во данных.
3.Сжать диск нельзя стандартными средствами не thin, не thick, у тонкого лишь один минус перед толстым, это в быстродействии.да и то незначительно.
Но сжать диски можно, это не проблема, и диски можно так же легко конвертировать из одного в другой.
4. вытащить данные из vmdk можно ещё при помощи HPE VM Explorer
Ну и чтобы хотелось добавить, что бесплатный ESXi+GhettoVCB, это прекраснейший гипервизор для небольшой организации, если не требуются HA, vmotion и т.д.
Если что пиши, любой вопрос по esxi подскажу как что лучше сделать!)
2. спасибо, посмотрю в его сторону (хотя уже в тредах выше думаю о переезде на PVE)
3. да? хорошо. не знал. а конвертировать как? я вот не могу, ибо у меня выскакивает ошибка «недостаточно места» (из тонкого в толстый)
4. а эта утилита вытаскивает информацию с дисков снапшотов? потому что вытащить инфу из корневого диска у меня то получилось, но на тот момент она была за 30 июня…
обязательно, если будут какие-то вопросы, вам напишу. спасибо :)
2.на мой чисто субъективный взгляд, переезд только либо на esxi, либо на Hyper-v от Microsoft.(если у вас всего один сервак, то самое надёжное и легко восстановляемое это esxi)
3.для начала его необходимо сжать, чтобы освободить место на datastore, а затем конвертируется он простым щелчком правой кнопкой мыши по диску.
Главное ответить себе на вопрос, зачем вам нужен именно тонкий диск? ведь тем более при наличии ssd, разница в скорости между ними ощутима не будет. и при ограниченном объёма datastore, выгоднее использовать именно тонкий диск.
4.Не могу точно сказать, уже не припомню
2. сейчас я на esxi. почему считаете, что стоит оставаться на ней?
3. да, у меня ограниченное место. но именно из-за тонкого диска у меня все и поломалось. разве не удобнее использовать толстый, чтобы сразу ограничить место и сказать «вот у тебя есть 150гб, ты не можешь выходить за рамки этого места»?
2. потому что стабильно, быстро и функционально
3. тонкий диск хорош, когда у Вас много виртуальных систем на одном диске. можно выделить больше места, чем реально есть. когда у Вас одна виртуалка то смысла нет никакого.
Но этот совет неприменим, если проблема связана с неисправностью диска.
3. У вас поломалось всё не из-за тонкого диска, а опять же, а из-за неправильного его использования. А проблема у вас из-за того что вы в самой OS, которая установлена в вашей VM, указали размер диска превышающий ваш реальный размер, а тонкий диск и растёт само собой. а если вы изначально в OS сделаете раздел 150 гб, то система не разрастётся, а упрётся в ограничения.посмотрите размер вашего раздела который вы создали, вы там явно указали размер больше доступного, вот вам и результат.
Преимущество тонкого диска, в том что вы всегда сможете его расширить при необходимости и занимает он реально, столько сколько вы на него записали, а это огромный плюс при ограниченном пространстве.
Какая у вас стоит OS на VM?
у вас возможно остался мусор в виде старых снапшотов, которые уже не используются, тем самым отнимая место.
вот, теперь я доступно и понятно понял преимущество thin… действительно удобно, спасибо.
мусор со снапшотами я примитивно удалил, сделав rm -rf ?-*.vmdk где? — название диска
посмотрите на предмет логов. лежат в папке с машиной, называются vmware-?.log и могут занимать изрядно места
так же в условиях недостаточного места можно отключить динамическое выделение памяти: галочка reserve all guest memory. Ставите, перезапускаете виртуальную машину. После этого можно удалить *.vswp
логи в совокупности весят не больше 200мб.
по поводу reserve… а как это влияет? что за динамическое выделение памяти?
сейчас у меня так


и это, как я понимаю, своп именно на уровне esxi. то есть тот своп, что я использовал раньше в убунту сервере (в ВМ) не то же самое, что своп на уровне esxi?
Позиция limit позволяет задать порог, после которого память будет выдавливаться в своп. Unlimited значит что это будет происходить при исчерпании физической памяти. любое другое значение — память будет убираться в своп при достижении этого лимита, независимо от наличия свободной памяти на хосте.
а вообще, штука удобная… не хочется отключать, тем более я выделил ВМ памяти меньше, чем надо.
да и 5гб ПОКА ЧТО не так критично
кстати, может, вы мне сможете растолковать: использовать своп на ссд резонно? он быстрый? точнее, можно ли на нем «прожить»? используя ВМ нормально, без последствий и фризов и т.п.
Нет, своп, тем более на бытовых ssd, использовать в обычной жизни не стоит. работать будет очень медленно, да и на времени жизни ssd это скажется негативно. Своп нужен, чтобы пережить кратковременные всплески потребления без болезненных последствий.
Думаю, проблему thin-дисков описывать не надо (если вкратце, то они после расширения своего пространства его не «сужают» в обратную сторону. они так же могут выйти за пределы физического количества памяти на диске).
Говоря честно и откровенно, это не проблема thin-дисков, это скорее всего проблема настроек (ну и ограничений ESXi) — при разрешенном unmap внутри guests и выполнении ряда условий всё отлично должно «сжиматься» (подробней тут: www.codyhosterman.com/2016/11/whats-new-in-esxi-6-5-storage-part-i-unmap).
Выйти за пределы они могут только если имеет место быть overcommit, если же сумма всего выделенного пространства для thin-дисков не превышает физического, то этого, разумеется, не случится. Overcommit это зло, кроме редких изолированных случаев.
«Эта история научила меня нескольким золотым истинам, которые так и не удалось до этого понять.»…
К сожалению, эта история не научила автора одной простой истине — читать документацию. Ее много, как официальной, так и от сторонних авторов (есть и на русском). Увы, но с таким подходом замена ESXi на Proxmox (как советовали выше), не поможет.
"exfat-4" — это что?
Как я откатил систему на месяц назад и все вернул? Опыт использования ESXi. Или как делать не надо