Комментарии 17
hyper-v на одиночном win 2019 server
в списке 9 машин, работает только 3
после перезапуска сервера (на важно, штатного или аварийного) с очень большой вероятностью в списке будет только 1 машина (всё время одна и та же) да ещё и не запустится, несмотря на то что в настройках стоит запускаться с задержкой 30 секунд
если сказать импортировать и сказать машины, (не важно что выбрать из опций про id машины при импорте) всегда говорит ошибкой, но тут же в списке появляется машина и прекрасно запускается и работает
Выделенная память у ВМ динамическая? если да, весьма вероятно, что на остальные две ВМ не хватает активной памяти на сервере. HyperV не умеет работать, если есть overprovisioning по памяти, плюс при запуске ВМ выделяет им максимум.
Поправлю — при запуске выделяется не максимум, а указанное в настройках виртуалки "стартовое значение". А уже после загрузки системы выделенная память может как уменьшиться, так и увеличиться.
на виртуалки выделено жёстко 8192, 512, 1024. dynamic memory НЕ включено
Теории о том, что:
есть проблемная машина или ряд проблемных машин;
есть проблемная Hyper-V нода;
отпадают, так как почти все машины из списка хоть раз да падали.
Собственно у меня сразу возник вопрос — почему исключили ноду в качестве пациента? С ВМками то понятно, это из отчёта ясно, но HTML отчёт нам ничего не говорит про ноды и расположение машин на них.
Логика следующая — если все машины на одной ноде, и часть из них падает а часть отрабатывает — то это не похоже на проблемную ноду. Если машины расположены на нескольких нодах, и все машины успешно отрабатывались, и падали, это тоже не похоже на проблему с конкретной нодой. В сценарии с проблемной нодой, в отчете обычно можно увидеть группу машин которая постоянно падает.
В общем, после анализа отчета стало ясно, что проблема глубже, чем просто проблемная ВМка или нода. И как Вы верно заметили, отчет не дает нам деталей, для этого мы пошли смотреть логи.
Я показал свою ветку развития расследования — сбор детальной информации об ошибке затем построение теории и её проверка.
Мы открываем файл, начинающийся с Task и содержащий название VM. В нем просто ищем ошибку. Обычно нажимаем CTRL+End — это перебрасывает нас в самый низ лога, и потом крутим колесико вверх, пока не увидим нужную нам ошибку.
А что мешает воспользоваться поиском и найти ту самую ошибку по «Failed to get VM»? Так же быстрее, чем скроллить руками через весь лог?
Почему я обычно делаю так?
В HTML репорте мы смотрим сверху вниз — от самого свежего выполения листая вниз более старые.
Имея открытый репорт, желая проанализировать именно самое свежее выполнение в логах, открываю файл и перескакиваю в самый низ (CTRL+End), и снизу вверх начинаю смотреть — видно как завершалось задание, и я анализирую все этапы один за одним. То есть, самое последнее выполение задания в логах всегда в самом конце.
Почему мне более предпочтителен этот способ чем поиск по «Failed to get VM»
Открывая файл с логами, и делая поиск по ошибке вы найдете ошибку, но нужно ориентироваться на какое именно выполнение задания вы смотрите — самое свежее, самое старое, или промежуточное.
В одном выполнении задания ошибка может пробрасываться в логи много раз, и просто найдя место где написано сообщение об ошибке нужно ещё с ориентироваться, что происходит в задании в этот момент в целом — полистать вниз и вверх.
В общем, когда задача сложная, и непонятная, то я анализирую всё выполение задания с конца и до начала и потом наоборот, чтобы не упустить деталей и сформировать картину происходящего.
techcommunity.microsoft.com/t5/failover-clustering/failover-cluster-vm-load-balancing-in-windows-server-2016/ba-p/372084
Proxmox VE — открытая альтернатива этому «чуду» от MS — forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-и-все-все-все
Автобэкапы, кластеризация, ZFS (не нужен железный raid-контроллер) с мгновенными снепшотами — из коробки. Можно прикрутить Proxmox Backup Server для инкрементных бэкапов.
Two types of virtualization are supported: container-based with LXC, and full virtualization with KVM.
Hyper-V хорош тем, что у него очень маленький оверхед. Особенно в Gen2 виртуалках.
Linux KVM (Proxmox VE основан на нем) хорош тем, что у него очень-очень маленький оверхед.
Amazon (https://www.opennet.ru/opennews/art.shtml?num=47556), Google, Oracle и (внезапно) MS (или думаете, что MS для Azure windows пользуют?) не дадут соврать.
Судя по тому, что вижу я, по процессору и диску у Hyper-V оверхед меньше, чем у KVM. По памяти и сети Hyper-V некритично хуже. Кто что использует — дело другое.
Плюс у Hyper-V свои плюшки есть вроде AVMA, PSSession в виртуалку, Hyper-V WMI provider и т.д. Кому что.
Это я всё к тому, что не такое уж он и «чудо».
В целом оверхед на виртуализацию в 2021-м ~1-2% в зависимости от железа и задач.
Спор ни о чем, имхо.
Зы. Плюшки - они такие и бывают https://winitpro.ru/index.php/2021/09/01/nizkaya-skorost-seti-hyper-v-windows-server/
Детектив с Кластером Hyper-V: шаг за шагом ищем решение проблемы