У вас в туннеле подсеть 192.168.1.0/24, и в локалке, судя по IP-адресам, подсеть 192.168.1.0/24, из-за этого у PPTP-сервера едет крыша, и он не знает, как обрабатывать пакеты из этой подсети -- то ли слать их в туннель, то ли слать их в локалку. Так что спецэффекты возможны очень разные. Назначьте в туннеле IP-адреса из другой подсети, например, 192.168.2.0/24, и правильно распишите маршрутизацию.
hosts надо вообще зачистить, я согласен с Rainberd -- это костыли. Всё должно работать без hosts, иначе глюки могут вылезать самые разнообразные. При работе в домене машина резолвит кучу служебных специальных записей в DNS, это не просто имя домен контроллера.
Хотя WINS не такое уж большое зло, но в принципе, от него тоже надо уходить уже потихоньку -- грамотно настроенный DNS и отключенный NetBIOS на рабочих станциях позволяют спокойно обходиться и без WINS.
Tookuk: Ваш роутер получает какой-то адрес от провайдера. Проверьте прямо в интерфейсе управления роутера, какой адрес он получил. Это самый точный источник, в отличие от всяких myIp. Если IP-адрес серый, или не совпадает с тем, что у вас указан в личном кабинете провайдера -- это явно косяк провайдера, и нужно звонить в саппорт и просить починить. Мотивируя тем, что у вас в личном кабинете указан конкретный адрес <такой-то>, а по факту на роутер выдаётся <такой-то>.
Роутер, конечно, меняет адрес, но не внешний, а внутренний -- подменяет IP машины в локалке на свой внешний белый IP. Такова суть работы технологии NAT.
Вы не найдёте программу, позволяющую рулить групповыми политиками на нескольких компах одновременно. В существовании такой программы просто нет никакого смысла -- это всё делается из AD. Твикер, который на локальном компе что-то будет делать типа TweakUI -- да, они есть. Но для руления групповыми политиками по всей сети существует AD, поэтому нет никакого смыла разрабатывать какую-то программу, которая будет это делать вместо AD. Так что либо AD, либо на каждом компе отдельно политики крутить.
susnake: есть основания полагать, что в этом случае вам поможет только бинарное копирование этого диска на другой. Фактически, содержимое этого физического диска не будет ничем отличаться от физического диска обычного компа. Если вы его воткнёте в другой комп и попытаетесь загрузиться -- то может быть, система даже загрузится как обычно, если драйверов ей хватит нужных на новом железе.
Так что какой-нибудь Norton Ghost или Acronis Disk Director тут могут помочь, но Hyper-V таких средств не имеет.
А какой профит отдавать физические диски в виртуалки? Это половина смысла виртуализации теряется :-)
А зачем вам "миграция виртуальной машины с одного физического диска на другой"? Это делается без всякой миграции -- гасите машину, копируете vhd-файл и потом в настройках машины указываете путь к новому расположению vhd-диска :-) Если же нужна именно миграция -- то это вопрос скорее в ведении таких штук, как SC VMM.
Ну так сбросьте на клиента задачу настройку заббикса. Это ж он хочет "стороннее приложение" -- ну вот и пусть занимается, а вы потом только результаты мониторинга оцените.
Кирилл Авраменко: а в каких сценариях предполагается использовать проброс графических ядер в виртуалки?
Что касается Заббикса -- ну поскольку вы всё равно разворачиваете виртуальную инфраструктуру, заббикс по-любому лишним не будет, так что может быть, это как раз идеологически самое верное решение. Потом на этом же заббиксе можно будет доделать мониторинг всего серверного парка.
Кирилл Авраменко: Ну, если рюшечки важнее чем ехать, тогда можно развернуть какую-нибудь систему мониторинга. Zabbix, например. Это потребует сервера Zabbix, сервера БД, веб-сервера и установки агентов на каждую машину. Ну и настройки всей этой красоты. Это не бог весть как сложно, конечно, но определённой возни потребует.
Кроме того, добавление в заббикс виндовых параметров мониторинга технически возможно, конечно, но нетривиально, особенно если у вас русские версии винды. По дефолту заббикс умеет показывать загрузку CPU, по-моему, сетку, и, возможно, нагрузку по памяти.
Отдельный вопрос возникает про GPU -- как вы вообще предполагаете виртуализировать приложения, которые требуют наличия GPU?
Алексей Калинин: Оно может и как-то, но наличие домена существенно всё упрощает. Поэтому я даже не пытался реализовывать это без домена. Хотел кластер виртуализации без домена запилить, но там такое количество телодвижений нужно было проделать, что проще было развернуть в виртуалке временный контроллер домена :-)
А в чём проблема с доменом? Всё равно требуются сервера Win2012, и всё равно потребуется управление инфраструктурой -- хостами виртуализации, хранилищами. Домен позволяет всё это делать гораздо проще.
Подробностей не подскажу, я не занимаюсь публичными облаками, но могу указать направление. К SC VMM есть приблуда, которая называется Service Manager. Она умеет строить отчёты по потреблённым ресурсам, и вроде как именно эти отчёты используются для chargeback, т. е. для выставления счетов клиентам. Ну или можно копнуть в сторону Microsoft Azure -- там тоже есть функционал оценки по схеме pay-as-you-go.
