terça-feira, 17 de junho de 2008

Invertendo adaptadores de rede no ESX - via linha de comando

Problema clássico: configuramos o console de gerenciamento do ESX num adaptador de rede qualquer. Ao espetar o cabo de rede, você percebeu que o Service Console foi conectado à placa errada. Para quem não pode ir fisicamente ao servidor e trocar os cabos (meu caso!) ou simplesmente é preguiçoso (meu caso também!), o jeito é recorrer à linha de comando para resolver o problema.

Nota para os novatos em ESX: não existe interface gráfica local para gerenciamento do ESX, a única opção para gerenciamento quando não temos rede é usar a linha de comando. Para os administradores de ESX, nenhum problema. Para os implementadores ou engenheiros de suporte: fique íntimo da linha de comando :-)

Um pouco de teoria

No ESX, os endereços ip não são associados a uma placa de rede diretamente, mas sim a uma interface virtual, que é associada a um switch virtual que, por sua

vez, uma placa física como uplink. Algo assim:

Interface Virtual do Service console (vswif0) ----> Grupo de portas "Service Console" no switch virtual vSwitch0 ----> vmnicx

O gráfico abaixo, tirado da interface de gerenciamento Virtual Center, ilustra esta conexão:

Você pode observar isto pelo resultado de um ifconfig na linha de comando: o único adaptador de rede com IP será o vswif0 em uma instalação nova de ESX.

Suponhamos que você tenha dois adaptadores de rede no servidor. No VMware ESX 3.5 estas interfaces não são nomeadas como no Linux, como eth0, eth1, mas sim como vmnic0, vmnic1, e assim por diante.

Mas o que acontece se alguém ligou o cabo de rede no adaptador de rede errado? O que fazer, se estamos a milhões de quilômetros de distância do servidor?

Oras, mudar a placa de rede. Isto é trivial, tanto na interface de gerenciamento do ESX quanto na linha de comando. Como não temos a inteface, vamos à linha de comando:

esxcfg-nics -l

O resultado é algo parecido com isto:

Name PCI Driver Link Speed Duplex Description
vmnic0 01:01.00 tg3 Down 1000Mbps Full Broadcom Corporation

vmnic1 01:02.00 tg3 Up 100Mbps Full Broadcom Corporation

Você também pode usar

ethtool vmnicx

Para obter maiores informações sobre cada adaptador de rede.

Sabemos agora que a vmnic0 está sem cabo de rede. Para descobrir qual vmnic serve de uplink para o switch virtual do Service Console use:

esxcfg-vmswitch -l

Que resulta em algo parecido com:

Switch Name Ports Used Configured Uplinks
vSwitch0 64 1 64 vmnic0

PortGroup Name Internal ID VLAN ID Used Ports Uplinks
Service Console portgroup0 0 1 vmnic0


Ok, sabemos que a vmnic0 está sem cabo de rede. Vamos então removê-la com o comando abaixo:

esxcfg-vswitch vSwitch0 -U vmnic0

Note que a sintaxe do comando acima é: esxcfg-vswitch -. O vSwitch0 foi criado automagicamente na instalação, contendo um port group chamado "Service Console". Nota: os nomes do switch e do port group são case-sensitive.

Para ligar outro adaptador de rede como uplink para este switch:

esxcfg-vswitch vSwitch0 -L vmnic1

Voila! A mudançã foi efetuada. Eventuais problemas transientes depois disto podem ser resolvidos com:

service network restart

Nota: estes procedimentos só se aplicam ao VMware 3.x. As versões anteriores são bem diferentes!

Marcadores: , , , , ,

quarta-feira, 11 de junho de 2008

Exportando o console do Enteprise Manager no SQL 2000/2005

Certa vez, em uma das minhas andanças pelo mundo de TI, herdei o gerenciamento de vários servidores SQL2000 em um cliente, mas não herdei o desktop do antigo DBA.

Eu pensei "hmm, fácil, exporto o .msc do console antigo e uso no meu desktop, assim não tenho que perder horas digitando endereços, contas e senhas".

Bzzz. Achou que seria fácil assim? O EM do SQL 2000 (e do 2005 também) armazena as informações de grupos e servidores registrados no console no registry do Windows, junto com a conta e senha configuradas para cada servidor. Infelizmente um export/import da chave do registry não resolve o problema, apenas os grupos são criados, sequer os servidores - eu nem me importaria muito em digitar a senha em todos um a um.

Como sou extremamente preguiçoso, procurei na internet por scripts que fizessem este trabalho, já que eu desconfiava que o SQL-DMO expusesse todas as informações necessárias.

Exportar

Para exportar o EM inteiro - incluindo grupos, servidores, contas e senhas utilizados para adminstração, para um arquivo .xml. Faça o download do arquivo abaixo, renomeie para dump.js e execute com cscript dump.js export.xml na linha de comando no desktop do qual você deseja exportar a configuração do EM:

dump.js

Importar

Para importar no desktop de destino, faça o download do arquivo abaixo, renomeie para load.js e execute com cscript load.js export.xml para magicamente recriar a configuração exportada.

load.js

Nota: estes scripts não foram criados por mim e não pude identificar o autor. Já os utilizei e posso garantir que funcionam.

Marcadores: , , ,

Como verificar WWPN no ESX pela linha de comando

Precisei verificar o WWPN de novos servidores ESX que não foram ligados ao Virtual Center ainda e que sequer possuem rede, logo, não consigo sequer conectar no hostd diretamente com o cliente do VC.

Só para constar, esta informação aparece no Virtual Center na guia Configuration - Storage Adapters - Details para cada host ESX gerenciado.

Como eu não tinha outra opção, fui até a boa e velha linha de comando para salvar o dia:


esxcfg-mpath -a

O resultado é algo assim:

vmhba0 XXXXXXXX 1:0:0

Sendo XXXXXXX o WWPN.

Ou ainda:

esxcfg-mpath -l

Cujo resultado é:

FC 1:0:0 XXXXXXXXXXX <-> YYYYYYYYYYYY vmhba0:0:0

Sendo YYYYYYYY o WWNN do Storage Processor na SAN. Outras opções do comando permitem mudar o estado dos links, preferência de caminhos e outras diversões.

Detalhe: este comando existe na versão 3.5. Nas versões anteriores havia um script perl wwpn.pl para o mesmo resultado. Obviamente, este script foi descontinuado.

Marcadores: , ,