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

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

Требование перехода к физике возникает на сервисе, на котором мониторинг показывает удивительные вещи:
1. Внутренний мониторинг сервиса по производительности, например время ответа на запрос, ниже желаемого (SLA вы определяете сами).
2. Утилизация CPU не доходит до 100%
3. Переключение контекстов исполнения для виртуального процессора выше чем 14000 переключений в секунду на ядро.
4. Параметры uptime/load average на сервере виртуализации в этот момент нормальные, то есть соседние виртуалки вам не отобрали ресурсы.
Сочетание этих трёх пунктов - верный признак того, что пора ставить физический сервер. Любая попытка выдать больше ресурсов (ядер и RAM) не приведет к росту показателя 1, а лишь снизит утилизацию в показателе 2. В этой ситуации вы имеете дело с паразитной нагрузкой от виртуализации.
Опять же мы считаем по п.4 что это не проблема перегрузки самого сервера виртуализации.

Нужно запустить отладчик в ОС и посмотреть, а что отжимает себе процессорное время. Если это сетевой стек ядра, то у вас еще сть шанс решить проблему при помощи SR-IOV, если ваша инфраструктура виртуализации к этом готова и есть поддержка на железе, и это разрешено исходя из безопасности.

Самая частая проблема такого потолка производительности это receive datapath для сети:
1. Данные пришли на физический адаптер узла виртуализации
2. Данные попали на некую шину в ядре ОС для последующей передачи на виртуальный адаптер
3. Виртуальный адаптер выполняющийся на одних ядрах тоже имеет свой receive datapath в сетевой стек гостевой ОС
4. Виртуальный драйверы принимающие потоки могут находиться на других ядрах.
Из-за множественной пересылки, если все пункты на разных ядрах у вас возникнут задержки, а каждая операция приёма данных по сети имеет высокий приоритет и прерывает выполнения задач пространства пользователя в пользу операции приёма данных.
SR-IOV позволит вам пробросить виртуальные функции (SR-IOV VF) вашего физического сетевого адаптера напрямую в виртуалку, тогда это работает так:
1. Данные пришли на физический адаптер узла виртуализации
2. Виртуальные драйверы принимают поток напрямую с сетевки, проброшенной в виртуалку причем на тех же ядрах/vCPU, которые ждут данные, потому что у вас доступно использование Receive Side Scaling в этом случае.
Опять же, SR-IOV убирает изоляцию, ваша виртуалка смотрит тогда на ваш физический коммутатор, будто она в него включена веревкой. Однако это наряду с увеличением "приоритета" виртуалки - ваш последний шанс. Если и это не помогает вы меняете виртуалку на физику.

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

2. Сервера БД
Сервера SQL всегда требуют тюнинг параметров процессора. SQL-запросы работают так, что они никогда не работают со своими данными сразу. При выполнении запроса вы сначала вычисляете сам запрос, потом работаете с индексами данных и только потом с самими данными. Из-за этого всё интеллектуальное кэширование на L1/L2 кэше бесполезно. Там всегда cache miss, его нужно оключать, чтобы сама процедура интеллектуального кэширования не занимала процессорное время. Плюс в зависимости от развертывания там может быть заморочка со стораджем.

3. Сервера приложений, которые зависят от скорости хранилища и сети. Их тысячи, но самый известный в СНГ пример - это 1С. Если у вас тупит сторадж на SQL-сервере, то у вас начнется каскадная деградация всех сервисов-приложений. Причем, сам сервер приложения начнёт отъедать ресурсы RAM и CPU и на нем начнутся проблемы. Проблема здесь как раз про виртуализацию сторадж-подсистемы и сети. Виртуализация создаёт не просто дополнительную нагрузку. Она по цепочке всё замедляет.

4. Сессионные терминальные серверы
Это почему-то мало кому очевидно, но сессионный терминальный сервер это вообще-то реалтаймовый сервер по кодированию видео и аудио, на котором кроме всего прочего запущены приложения. То есть это гарантировано подпадает под п.1 и зачастую на него публикуют клиентские части от приложений п.3.
Если вам нужно виртуализировать пользовательские сессии примените Virtual Desktop и выдайте пользователям клиентские виртуалки. Если у вас сессионный терминал, на котором вы публикуете приложения, сделайте его физическим.