VM
Но все очень сильно устарело у них.
Вот тут был:
https://github.com/telcat/vagrant-proxmox
Size: a a a
2020 February 14
R
сейчас бы вагрант советовать, когда есть плагин для terraform
VM
сейчас бы вагрант советовать, когда есть плагин для terraform
Я не советую, я отвечаю на вопрос =) Но в общем согласен, сейчас вагрант, ну такое. Но если человек умеет с ним работать, и уже использует в продакшине - why not?
VM
Пока тот или иной проект жив и развивается, значит он кому-то нужен, значит у него есть те или иные преимущества. Но как и везде, что бы реализовать их надо найти подходящую сферу.
VM
К слову стало интересна разница, и вот что разработчик пишет про вагрант и терраформ:
Vagrant is for development environments. Terraform is for more general infrastructure management.
Vagrant is for development environments. Terraform is for more general infrastructure management.
РП
Vladimir Manko
Я не советую, я отвечаю на вопрос =) Но в общем согласен, сейчас вагрант, ну такое. Но если человек умеет с ним работать, и уже использует в продакшине - why not?
вообще, vagrant и terraform - продукты одной конторы, vagrant для управления средами разработки, terraform - для управления инфраструктурами
РП
Vladimir Manko
К слову стало интересна разница, и вот что разработчик пишет про вагрант и терраформ:
Vagrant is for development environments. Terraform is for more general infrastructure management.
Vagrant is for development environments. Terraform is for more general infrastructure management.
опередил, да )
VM
вообще, vagrant и terraform - продукты одной конторы, vagrant для управления средами разработки, terraform - для управления инфраструктурами
Все верно =) Тоже подумал, если хашикорп делает и то и то и оно живет, то должно быть отличие.
VM
А у них там целая статья оказывается есть на эту тему.
РП
разная цель у продуктов, их сравнивать не имеет смысла ))
М
Всем привет, есть гипер с 12 CPU, на машины раскидано 16 CPU, есть одна машина с которой крайне не желательно делать CPU steal, в proxmox это реально как-то зафиксировать, что с этой машины стилить нельзя?
I
Всем привет, есть гипер с 12 CPU, на машины раскидано 16 CPU, есть одна машина с которой крайне не желательно делать CPU steal, в proxmox это реально как-то зафиксировать, что с этой машины стилить нельзя?
хз, насчет можно ли гарантированно застолбить, но есть cpu shares для приоритета задач
I
есть еще через костыли в конфиге cpu affinity, но хз не будут ли другие вм покушаться на это ядро
VM
Всем привет, есть гипер с 12 CPU, на машины раскидано 16 CPU, есть одна машина с которой крайне не желательно делать CPU steal, в proxmox это реально как-то зафиксировать, что с этой машины стилить нельзя?
Жесткой привязки нет. Но можно поиграть с параметром CPU limit. Он указывает сколько процессорного времени виртуальная машина может "отобрать" себе относительно других виртуальных машин и хоста.
М
Спасибо, покрутил, вроде лучше стало 👍
VM
Спасибо, покрутил, вроде лучше стало 👍
Главное понять принцип работы - там "покрутит" лучше не у той виртуалки которой требуется гарантированное время а у тех которые стоило бы ограничить. Хотя и основную тоже можно.
VM
Фишка в чем - например есть VM с 2-я ядрами. Если ей поставить цпу лимит 1.0 то при попытке "сожрать" мощности процессора гипервизор заблочит ее на 50% от 2-х ядер, т.е. только на одном. Как то так.
VM
Т.е. например имей я 8 физических ядер и 6 виртуалок в такой схеме:
вм1 - 4 ядра
вм2 - 2 ядра
вм3 - 2 ядра
вм4 - 2 ядра
я бы сделал так:
вм1 цпу лимит - 3.0
вм2 цпу лимит - 1.0
вм3 цпу лимит - 1.0
вм4 цпу лимит - 1.0
вм1 - 4 ядра
вм2 - 2 ядра
вм3 - 2 ядра
вм4 - 2 ядра
я бы сделал так:
вм1 цпу лимит - 3.0
вм2 цпу лимит - 1.0
вм3 цпу лимит - 1.0
вм4 цпу лимит - 1.0
VM
Тогда если вдруг они все решать активно "поработать" - то у первой гарантированно должно быть около 3-х ядер, у трех оставшихся по одному. Т.е. в сумме 6 ядер они смогут все вместе грузануть на 100%. Хотя на них распихан оверпровизионинг на 10 ядер при 8 физических.
VM
Но это все приблизительно, т.к. как оно в реале будет сложно предуагать.