SQL Конфигурация связанного сервера между виртуальной машиной и хостом - PullRequest
Новая
       112

SQL Конфигурация связанного сервера между виртуальной машиной и хостом

0 голосов
/ 08 мая 2020

Я пытаюсь установить связь между двумя серверами SQL, один на моем ноутбуке, а второй - на виртуальной машине на том же ноутбуке. Однако я столкнулся с неприятным поведением.

Настройка:

  1. Хост: W10 x64 enterprise, SQL Server 2019, Developer. Windows Брандмауэр отключен

  2. ВМ: W7 Pro x64, SQL Server 2014, Express. Windows Брандмауэр выключен

С этой настройкой я могу:

  1. Пинговать ВМ с хоста
  2. Пинговать хосту с ВМ
  3. На хосте используйте студию управления SQL для подключения к экземпляру SQL на виртуальной машине
  4. На виртуальной машине используйте студию управления SQL для подключения к SQL экземпляр на хосте
  5. От хоста создайте связанный сервер с виртуальной машиной (с помощью мастера New Linked Server ...)

Но то, что я не могу сделать, это из виртуальная машина создает связанный сервер с узлом, используя тот же мастер создания связанного сервера. Что происходит, так это то, что я получаю ошибку тайм-аута в процессе входа в систему.

Я использую те же учетные данные, что и для подключения через студию управления. Я попытался создать связанный сервер как «SQL Сервер» и «Другой источник данных» (с использованием поставщика SQLNCLI), и ни один из этих методов не работает.

Что могло вызвать этот тайм-аут:

Может быть:

  1. Различные версии SQL?

  2. Разница между Express и версиями для разработчиков? (Я знаю, что могу установить серверные ссылки между двумя разными Express 2012 экземплярами)

  3. Что-то, чего мне совсем не хватает?

1 Ответ

0 голосов
/ 12 мая 2020

Оказалось, «3. То, что мне совсем не хватает»

Немного предыстории. Для поддержки / тестирования различных сетевых моделей на моем столе аппаратные порты Ethe rnet на всех моих компьютерах настроены для ответа на две разные подсети: 192.168.0.xxx (используется в качестве основного транспорта между 5 различными компьютерами) и 192.168.100.xxx (используется для тестирования различного сетевого оборудования).

В настройке, описанной в моем вопросе, у меня был следующий IP-адрес: 

Host: Primary: 192.168.0.99    Secondary: 192.168.100.80
VM:   Primary: 192.168.100.78

Поскольку виртуальная машина нужно было только поговорить с хостом на 192.168.100 su bnet, я дал ему только один (основной) IP-адрес. Это обеспечило достаточное сетевое подключение, чтобы я мог выполнять все задачи, упомянутые в вопросе (и не удалось выполнить задачу Linked Server).

Решение оказалось простым изменением основного и дополнительного IP-адресов виртуальной машины, чтобы они находились в совпадающих подсетях, которые были настроены для первичного и вторичного IP-адресов хоста. EG: 

 Host: Primary: 192.168.0.99 Secondary: 192.168.100.80 
 VM:   Primary: 192.168.0.49 Secondary: 192.168.100.78

Таким образом, я дал виртуальной машине IP-адрес, который ей не нужен. Как только это было сделано, я мог мгновенно создать связанный сервер от виртуальной машины к хосту.

Требование совпадения подсетей для Первичного и Вторичного адресов кажется некоторым артефактом сети Windows в сочетании с SQL Сервером. Я обнаружил это, когда пытался настроить тест с другим ящиком Windows 10, и имел те же симптомы, что и изначально для виртуальной машины.

...