WebDebug, ну так это же обычный хостинг вырисовывается. Кто будет ходить на дурацкий адрес, если есть нормальный ?

Идея приблизительно понятна.

авторДа мне не нужны указания типа "что тут сложного?" и "в чем проблема-то?". Мне нужны советы от тех, кто это делал, или кто хорошо знает как это лучше сделать и какие могут быть сложности. Чтобы сделать удобнее, универсальнее и избежать проблем в дальнейшем.
Как удобно добавлять, редактировать и управлять большим кол-во таких виртуальных хостов?

Да обязательно у вас будут проблемы. Как же без них ?
Ни одно ПО класса "панель управления хостингом" этого не предоставит. Нет никакого нормального способа.
Хостинг обычно данные клиентов отделяет между собой, а вы собираетесь заделать один сайт с доступом ко всем.

В apache есть mod_vhost_alias.
В nginx (а он у вас или уже есть или потом будет) придется накручивать какие-то правила.
Поизучайте, но, опять же, никакого готового рецепта.

автор Какие ограничения по производительности могут быть, напр., 1000 отдельных доменов способна как-то повлиять на производительность?
Допустим, в стандартной конфигурации есть незначительные проблемы , которые могут возникнуть как раз при управлении из скриптов. Там же нужно делать apachectl restart или configtest. Подтормаживает это если число сайтов тысячами измеряется.
При обычном обслуживании ничего страшного. mod_vhost_alias это все не важно.

авторКоллега сообщал о необходимости внесения правок для htacess после настройки виртуалхоста, а можно без этого обойтись нормальным способом?

Тут можно только предполагать что именно он имел ввиду.
Скорее всего, речь была о том, что есть хостинг с панелью управления (причем, не он не думал даже какой именно, произвольной) и некий каталог, в котором с помощью rewrite заделаны перенаправления.
Ну конечно, надо будет править такой .htaccess. Так ведь вам все равно писать и писать.

автор Также коллега сообщал о необходимости абсолютных путей для указания статики, а возможно как-то избежать этого другими нормальными путями?

Та же история - не понятно какой он план выбрал.
Скорее всего, это связано с версткой html и каким-то принятыми у вас техниками на уже сделанных сайтах. Может оно уже сверстано с абсолютными ? Ну так переверстайте без абсолютных путей. Как раз к весне успеете.

автор Можно ли как-то на VPS сделать автоматическое создание и полную настройку виртуалхоста из CMS? И в случае необходимости - удаление настроенных ранее виртуалхостов?
Формальный ответ - конечно, можно !
Практичный ответ : а кто это все будет писать, если в команде только php и немного битрикс знают?

Из php можно запускать любые программы, а с помощью sudo контролировать любые системные действия или запускать скрипты как root. Теоретических проблем нет.

miksoftWebDebugТ.е. там будет CMS для управления всем сайтом (Битрикс)WebDebugнапр., 1000 отдельных доменовКак-то у меня не сопрягается одно с другим.
Вы планируете лицензировать 1000 дополнительных сайтов для Битрикса?
там вроде есть лицензии без ограничения числа сайтов.
Хотя не понятно как оно потянет в плане нагрузки. Так что в перспективе ситуация осложняется еще и многосерверной конфигурацией.

WebDebugНа данном этапе вопросов больше нет, кроме одного: если мы самостоятельно добавляем виртуалхосты, могут ли быть какие-то проблемы с панелями администрирования (ISPmanager, CPanel и др) - не будет ли конфликтов(напр., мы записали, а панель внесла изменения)?
Могут . Или не могут. 50% . Там же наверняка не один сайт и специфичные настройки старые были.
Я бы выделил отдельный сервер ispmanager под это дело только с одним сайтом + клиентские. nginx эта панель сама подергает и настроит. И управлять ей лучше через веб.

Если самим через system('sudo ...'), то слишком много внимания нужно уделить безопасности всего этого кода работающего от root.
А тут вроде как пароль лишь бы спрятан был и все.

А почему вы не выбрали домены типа *.pages.хитрая-контора.ru ?
В этом случае услуги отдельной услуги регистрации домена просто не потребуется. Имя можно и покороче придумать. И зарегистрировать отдельное короткое.
Этот вариант крайне удобен, потому что конфигурация становится как раз очень традиционной.

WebDebugУ нас планируется самый обычный сайт, где обычные урлы типа /компании/моя-компания/. И планируется приобретение компаниями опций по прикреплению к "своему" урлу своего домена. Поэтому поддомены ни там ни там не к месту.

Ну так перепланируйте.