Existe um método que permite a configuração de parâmetros específicos de um sistema operacional através da passagem de seus valores ao realizar o deploy de um OVF. Isso é feito por meio do recurso vApp disponibilizado pela VMware, parcialmente (logo mais o motivo ficará explícito). Existem outras facilidades dele, mas nessa postagem somente é mostrado como preparar uma estratégia para que o SUSE Linux Enterprise Server 11 SP3 seja autoconfigurado no âmbito de estrutura básica de rede como IP, máscara, gateway, DNS primário, DNS secundário, NTP, hostname e domínio.
O primeiro passo é habilitar o vApp options na edição da VM. No tree view dessa opção surgirá mais 4 itens: Properties, IP Allocation Policy, OVF Settings e Advanced.
Na opção Advanced clique no botão IP Allocation e marque a opção OVF Environment.
Os parâmetros para o usuário digitar ao realizar o deploy são configurados na janela mostrada abaixo ao clicar no botão Properties.
Veja um exemplo da configuração de um campo do tipo IP.
Na opção OVF Settings marque a opção VMware Tools. Isso permite que obtemos os valores configurados a partir de um XML no contexto de execução do sistema operacional pelo comando vmtoolsd --cmd "info-get guestinfo.ovfenv" no shell.
Veja que o botão View fica bloqueado. Ele só é liberado ao ligar a VM.
Por fim na opção Properties podemos visualizar como será mostrado os campos no deploy do OVF.
Agora se clicarmos no botão View depois de a VM ter sido iniciada ele pode mostrar, por exemplo, o seguinte XML:
É justamente ele que será disponibilizado pela VMware Tools.
Um ponto importante é que podemos testar a configuração em função desses valores até funcionar para distribuir o OVF. Para fazer isso eu desenvolvi o seguinte script em python (a leitura do XML eu achei na postagem do Martin Amdisen):
Caso seja feita a execução dele os valores já serão obtidos e configurados no SLES.
Depois dos testes é necessário preparar a VM para exportar um OVF. Existem alguns pré-requisitos como não ter entradas no /etc/resolv.conf e na tabela de consultas do NTP, mas o principal é garantir que o script seja executado uma única vez no SLES. No meu caso criei um serviço para ser iniciado no runlevel 3 (depois de network) que chama o script em python, exclui ele depois da configuração, desfaz o registro para ele próprio não ser mais executado como serviço para, no final, se auto excluir não deixando rastros no SLES, mas é claro, isso é só uma sugestão.
Para maiores detalhes sugiro os seguintes links:
O primeiro passo é habilitar o vApp options na edição da VM. No tree view dessa opção surgirá mais 4 itens: Properties, IP Allocation Policy, OVF Settings e Advanced.
Na opção Advanced clique no botão IP Allocation e marque a opção OVF Environment.
Os parâmetros para o usuário digitar ao realizar o deploy são configurados na janela mostrada abaixo ao clicar no botão Properties.
Veja um exemplo da configuração de um campo do tipo IP.
Na opção OVF Settings marque a opção VMware Tools. Isso permite que obtemos os valores configurados a partir de um XML no contexto de execução do sistema operacional pelo comando vmtoolsd --cmd "info-get guestinfo.ovfenv" no shell.
Veja que o botão View fica bloqueado. Ele só é liberado ao ligar a VM.
Por fim na opção Properties podemos visualizar como será mostrado os campos no deploy do OVF.
Agora se clicarmos no botão View depois de a VM ter sido iniciada ele pode mostrar, por exemplo, o seguinte XML:
Um ponto importante é que podemos testar a configuração em função desses valores até funcionar para distribuir o OVF. Para fazer isso eu desenvolvi o seguinte script em python (a leitura do XML eu achei na postagem do Martin Amdisen):
Depois dos testes é necessário preparar a VM para exportar um OVF. Existem alguns pré-requisitos como não ter entradas no /etc/resolv.conf e na tabela de consultas do NTP, mas o principal é garantir que o script seja executado uma única vez no SLES. No meu caso criei um serviço para ser iniciado no runlevel 3 (depois de network) que chama o script em python, exclui ele depois da configuração, desfaz o registro para ele próprio não ser mais executado como serviço para, no final, se auto excluir não deixando rastros no SLES, mas é claro, isso é só uma sugestão.
Para maiores detalhes sugiro os seguintes links:
Comentários
Postar um comentário