Pull to refresh

Comments 103

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(в принципе, я так тоже думал. но товарищи из треда выше уверили, что PVE — лучше есхи)
не совсем. скорее «если уж вкусил возможности и стабильность ESXi, то откатываться на проксмокс может быть больно»
но можно протестировать его на еще одном сервере…
в общем, пойду смотреть, думать. хотя все-таки (последний комментарий от nikos7 указал на плюс тонких дисков) мне что-то по душе остаться на есхи
Вы два года пользуетесь proxmox, но для вас «это не энтерпрайз», можно узнать почему?
Тут иногда вылезают ошибки из ничего, одни из самих забавных — перестают запускаться виртуалки или контейнеры (не помню как решил), бывают проблемы с сеткой ну и т.п. Некоторые как ни странно удалось решить только перезагрузкой хоста (понимаю что не спортивно, но гугл молчал, а в линуксе так глубоко лезть не было времени). На том же esxi я не словил(хотя скорее не помню) за много лет ни одного глюка
Странно.
Ошибки не запуска систем, это обычно или нет кворума в кластере, или предыдущая команда к этой виртуалке не завершилась и ждет какого-то тайм-аута.
Проблемы с сетью бывают обычно, если что-то изменить на хосте в настройках сети. Еще бывают глюки с 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 лет прошло. Как же давно это было…
Собственно вы и обрисовали типичный proxmox кластер :) То есть не просит и радуется родителей, то голову ломаешь что же ему не нравится. С вмваре имхо как-то попроще.
С вмваре однажды попали на мощный глюк — сетка могла неожиданно упасть в смерть(например когда сервер включался, еще до биоса). Долго искали проблему, потом наконец документацию HWL Вмвари почитали вдумчиво, разобрались с драйверами вендора, сравнили документации и выравняли версии фирмвари и дров и все работает как часы с тех пор. Но это было практически единственное что было неприятное c VMware.
Знакомый посоветовал ESXi как бесплатное решение для небольших серверов (мой случай: 1 процессор + всего 8 GB RAM). Процесс переезда осложнялся тем, что надо было сначала на windows-компьютере поднять vmware workstation вместе с vmware converter

да?
ещё

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

так не делать
Я имел в виду как раз бесплатный лицензионный ключ.
Кажется, там есть ограничение в 2 камня и 32ГБ оперативки
image
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
это же unix система.
du -h --max-depth=1 /

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

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

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

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

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



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

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

Articles