procself

vmware-tools vs. linux kernel

June 25, 2007 on 11:25 pm | In vmware, linux | No Comments

Antes de mais, o disclaimer: este artigo refere-se a uma versão antiga do VMware ESX, a 2.5.4. Nada disto se passa na série 3.*

Recentemente tive que actualizar uma máquina virtual ESX de Debian 3.1 para Debian 4.0. Apesar de não ser obrigatório, quis aproveitar a oportunidade para actualizar o kernel da versão 2.6.8 para a versão 2.6.18. Aqui começaram os problemas.

UTS_RELEASE
O symbol UTS_RELEASE contém a versão da source de um determinado kernel, no formato a que a maioria das pessoas está habituada, ou seja, A.B.C[.D]. Por esta razão, é frequentemente usado em scripts cuja execução depende da versão do kernel.

Até à versão 2.6.18 do kernel, este símbolo estava definido em:

./include/linux/version.h

mas a partir da versão 2.6.18 passou a estar num header file separado:

./include/linux/uts_release.h

Como consequência, o script vmware-config-tools.pl não conseguia detectar correctamente a versão da source contra a qual estava a tentar compilar as vmware tools e, para dificultar as coisas, limitou-se a queixar-se que a versão da source não correspondia à do kernel que estava a correr. Cheguei ao cúmulo de compilar um kernel novo e arrancar a máquina virtual com ele para ter a certeza absoluta que correspondia à source em questão!

Acabei por cheguar à origem do problema por sorte, graças a um comentário a esta entrada do kerneltrap, escrito por alguém que passou pelas mesmas dificuldades ao tentar compilar o módulo para as placas ATI.

Nesta caso a solução era trivial, bastava copiar a seguinte linha do utsrelease.h para o version.h:

#define UTS_RELEASE 2.6.18

e a detecção já funcionava devidamente.

Primeiro problema resolvido, vamos em frente.

VMW_HAVE_EPOLL
O primeiro módulo que o script vmware-config-tools.pl tenta compilar é o vmmon, responsável por melhorar a gestão de memória e cpu dentro da máquina virtual, e por funcionalidades como o memory ballooning (PDF). Durante a compilação surgiram warnings como este:

warning: "VMW_HAVE_EPOLL" is not defined

Que mais à frente acabam por degenerar em erros que impedem a compilação.

Confesso que não percebi exactamente qual o efeito desta alteração ao Makefile das vmware-tools, mas confirmo que funciona.

Com esta alteração o módulo vmmon já compila e carrega sem problemas.

HgfsGetsb()
O próximo módulo, vmhgfs, também não compila sem alterações. Apesar de não ser crítico para o funcionamento da máquina virtual (só fornece a funcionalidade de shared folders), acabei por gastar algum tempo e acabei por descobrir que alterações fazer e porquê.

A função get_sb_nodev que é invocada a partir da rotina HgfsGetsb() passou a ter mais um parâmetro a partir da versão 2.6.18 do kernel.

O fix não é trivial, mas está bem descrito no comentário de Jim Bachesta a este thread nos fóruns da vmware.

A partir daqui o módulo já compila e carrega sem problemas.

MODULE_PARM
E, para serem três em três, o módulo vmxnet - o terceiro e último componente das vmware tools e provavelmente o mais essencial de todos (fornece o driver para a placa de rede virtual) - também não compila à primeira.

Desta vez foi a macro MODULE_PARM que passou de deprecated a obsolete e foi, consequentemente, abandonada. No seu lugar ficou um substituto: module_param. Este artigo fez-me perceber o que tinha acontecido, agora só faltava descobrir como resolver.

Este mail da mailing-list da malta do pcmcia serviu-me de exemplo e bastou corrigir as duas ocorrências na source do vmxnet para que passasse, também, a compilar e carregar sem problemas.

No final de contas foram umas horitas de hack atrás de hack como há muito tempo já não me acontecia, mas acabou por valer a pena, nem que seja só pela satisfação de ter resolvido um problema que o pessoal da VMware ainda não se deu ao trabalho de corrigr e publicar.

Partilhar

dynamic disks vs. network shares

April 4, 2007 on 11:08 am | In vmware, windows | No Comments

Uma das vantagens de ter uma infra-estrutura virtualizada (sobre VMware, como é o caso, sobre Xen ou qualquer outro) é poder mudar o hardware físico com facilidade sem ter que mexer no “ferro”.

Um caso prático que ocorre frequentemente é “esticar” discos de máquinas virtuais que atingiram a capacidade máxima. Ontem tive de fazê-lo para uma máquina virtual de um cliente, uma vez que era preciso esticar o disco de um fileserver (que por acaso era um Small Business Server) de 40GB para 90GB.

À partida devia ser uma tarefa simples:

1. desligar a máquina virtual e esticar o ficheiro onde está encapsulado o disco virtual:
   vmkfstools -X 90G
2. ligar a máquina virtual e converter o disco de basic para dynamic (não era o disco de sistema)
3. reboot (what else…)
4. expandir o volume de 40 GB para 90GB, et voilà

Pois… só foi pena desaparecerem todas as shares de rede que estavam configuradas para o drive em questão. Como se trata do fileserver onde estão guardados os documentos dos utilizadores, as pastas de grupos, as caixas de correio e os perfis dos utilizadores, as consequências disto são dramáticas.

O pior é que não encontrei nenhuma justificação para isto acontecer, o procedimento que segui está documentado pela Microsoft e VMware como válido e já o tinha feito no passado sem qualquer problema. A única explicação que colegas mais experientes me deram, por incrível e rebuscada que possa parecer, é que se o Small Business Server fosse de língua Inglesa em vez de Portuguesa isto não acontecia…

E esta hein?…

Partilhar