Servidor real, vários endereços IP, servidor virtual HyperV, como particionar IPs entre NICs reais e virtuais

Servidor real, vários endereços IP, servidor virtual HyperV, como particionar IPs entre NICs reais e virtuais

Este é um problema um pouco difícil de explicar sem as mesmas informações básicas - tentarei refinar a questão mais tarde, conforme necessário


Originalmente, tenho um único servidor hospedado (Win 2008R2) com o seguinte intervalo de 8 endereços IP.

- Single NIC ( IP: x.x.128.72 -> x.x.128.79 // Subnet: x.x.255.192 // GW: x.x.128.65 )

Depois de instalar o Hyper-V e configurar um único servidor virtual na mesma caixa, quis então atribuir um dos endereços IP ao servidor virtual, deixando todo o resto funcionando normalmente.

--

Primeiramente tentei usar a rede "Externa", mas (mesmo depois de configurar IPs no "Adaptador Virtual" semelhante aAquimas tive dificuldade para fazer a rede funcionar).

Eu precisava manter o servidor funcionando (caso contrário, teria passado mais tempo seguindo essa abordagem)

Q1... Foi sensato fazer isso? Eu deveria ter continuado por esse caminho?

--

Decidi então tentar uma abordagem diferente - definir a rede HyperV como "Interna" (visível para o sistema operacional de gerenciamento)

- Physical NIC ( IP: x.x.128.72 to .75 // Subnet: x.x.255.192 // GW: x.x.128.65 )
- Virtual NIC ( IP: x.x.128.78 // Subnet: x.x.255.252 // GW: x.x.128.72 ) 
     - Gateway was the same as the IP of the physical NIC )
- Virtual OS-NIC ( IP: x.x.128.77 // Subnet: x.x.255.252 //  GW: x.x.128.78 ) 
     - Gateway was the same as the IP of the host virtual-NIC )

--

Surpreendentemente, essa abordagem realmente funcionou e consegui me conectar a partir de todos os seguintes: - Internet de/para NIC física (xx128.72) - NIC física (xx128.72) para NIC de sistema operacional virtual (xx128.77) por exemplo, teste via ping + FTP - Internet de/para virtual-OS-NIC (xx128.72)

--

O problema que tenho é que essa abordagem parece durar pouco tempo (algumas horas).

Após esse período, parece que perco a capacidade de me conectar do Virtual-OS-NIC para/da Internet (mas ainda consigo me conectar do sistema operacional host ao sistema operacional virtual e do sistema operacional host à Internet)

Testei novamente algumas vezes com os mesmos resultados... Deixo o servidor ligado por algumas horas (por exemplo, durante a noite) e quando volto pela manhã, o Virtual-OS perde a capacidade de rotear para a Internet

--

Não tenho certeza do que ver a seguir (ou se estou fazendo isso da maneira completamente errada)

Um "possível item relevante" é que o sistema operacional host também está executando RRAS (Roteamento e Acesso Remoto), mas isso é apenas para executar uma VPN simples

--

Q2 - Devo olhar para o trigo a seguir? (Quaisquer boas referências/recomendações sobre o que tentar)

Agradeceríamos quaisquer pensamentos ou comentários (mesmo se você me disser que estou fazendo isso da maneira errada)

--

*EDIT - Segunda tentativa de usar "Externo" *

Depois de tentar novamente a abordagem "Externa", novamente NÃO obtive acesso à rede...

Em seguida, desmarquei a opção "Ativar identificação de LAN virtual para sistema operacional de gerenciamento" ... Ei, pronto, tudo ganhou vida.

O texto crítico estava oculto no link "mais sobre como gerenciar redes virtuais" que afirma

Especifica um número de identificação que pode ser usado para isolar o tráfego de rede do sistema operacional de gerenciamento

Resultado final...SUCESSO(mas sem solução de por que funcionou PARCIALMENTE por tempo limitado)

Mais tarde, achei interessante a seguinte postagem no blog do MSDN ...Compreendendo as VLANs do Hyper-V

Responder1

Na verdade, o Hyper-V não é um complemento do Windows; na verdade, é um hipervisor completo que assume o controle. O sistema operacional originalmente instalado torna-se então uma partição raiz, subordinada ao Hyper-V. Então, o que era o sistema operacional base é tecnicamente uma VM especial agora. Nessa medida, a VM "especial" pode ter hardware passado (para dar a aparência de um sistema operacional normal). Esta é a configuração padrão para quase todos os hardwares após a ativação do Hyper-V. No entanto, quando você cria uma rede virtual para o Hyper-V conectada a uma NIC física, o Hyper-V assume a propriedade da NIC e ela não é mais transmitida.

A configuração da sua NIC deve ser a seguinte:

A NIC física deve ter o protocolo "Microsoft Virtual Network Switch" habilitado apenas (a única exceção é quando esta não é uma NIC física real, como uma equipe configurada por software, você geralmente terá algum tipo de outro protocolo que não pode ser desabilitado).

No Gerenciador de Rede Virtual do Hyper-V Manager; crie uma "Rede", isso criará um switch de rede virtual no Hyper-V. Torne-o Externo, anexado à NIC Física, marque também a caixa para permitir o acesso ao SO de Gerenciamento. Isso criará um novo vNIC para o sistema operacional base (lembre-se de que na verdade é uma VM especial, então você está adicionando um vNIC a esta VM...). A nova NIC pode precisar ser configurada para os IPs retirados da antiga NIC física (depende da versão do Hyper-V que você está usando, se isso será feito automaticamente ou não).

Crie VMs conforme desejado, adicione vNICs a elas e anexe esses vNICs à rede virtual apropriada.

As redes virtuais externas são anexadas a uma NIC física. Eles permitem que as VMs se conectem às NICs físicas. As redes virtuais internas sempre criam um novo vNIC para o sistema operacional de gerenciamento (não há caixa de seleção, é sempre feito). Isso permite que as VMs se comuniquem com o sistema operacional base, mas não com nenhuma NIC física. As Redes Virtuais Privadas são apenas para VMs e não se conectam de forma alguma ao sistema operacional de gerenciamento.

Você também mencionou problemas para manter as coisas funcionando. Se você não estiver usando chips NIC de nível de servidor (particularmente Intel, Broadcom, QLogic, Emulex, NexGen, Mellanox, etc), espere problemas. Da mesma forma, certifique-se de ter o firmware mais recente. Se você estiver executando chips Via ou Realtek, poderá economizar seu tempo e descartar a ideia de hipervisores confiáveis ​​de nível 1 (Hyper-V, ESXi, KVM, etc).

informação relacionada