Executando software de desktop baseado em gui em uma VM sem cabeçalho

Question

Estou lidando com algum software que "quer" ser executado a partir de um sistema que tenha uma área de trabalho (chame-o de pacote principal). Este software invoca outros pacotes que também são executados como aplicativos de nível de usuário na área de trabalho (chamá-los de pacotes secundários).

A maioria desses aplicativos secundários são programas baseados em Windows que requerem sua GUI para serem executados, e o pacote principal envia os botões programaticamente nos pacotes secundários para obter os resultados desejados. Um dos pacotes secundários é um aplicativo baseado em DOS que usa a técnica de envio de botões, enquanto outro pode realmente ser invocado por automação OLE e orientado diretamente. (Para referência, os programas secundários analisam dados e geram relatórios que o pacote principal envia por e-mail)

O desejo é mover essa configuração para uma VM e, talvez, usar algo como SrvAny para encaixar a primeira aplicação em um serviço do Windows. No entanto, acredito que, quando a VM começar, não haverá desktop por padrão, então minhas perguntas são:

1. Como os programas baseados em gui reagir?

2. Será que eles provavelmente falharão e queimarão quando o programa principal tentar invocá-los, mas não encontrar a área de trabalho?

3. As janelas suportarão automaticamente os programas secundários?

4. Ou eu estou totalmente errado e executando a VM que cria uma área de trabalho padrão?

O sistema operacional convidado provavelmente será o servidor W2k3, hospedado no ESX 3.5

Por que o motivo da execução sem cabeça são as diretivas de segurança que impedem a execução de sistemas autônomos.

Editar

Obrigado pelas respostas - eu não tinha certeza da mecânica do sistema de gráficos virtuais das VMs.

Quanto à política de segurança, em retrospectiva, não a expliquei da melhor maneira possível. O que eu realmente quis dizer foi que uma solução alternativa foi proposta para mim como sendo:

1. Inicie a VM

2. RDP para a VM para obter uma área de trabalho

3. Inicie o software

4. Desconecte-se da VM (não fazendo logoff) para que o software continue sendo executado nessa sessão

A saída de uma sessão RDP desconectada, mas em execução, é vista como uma função de VM não-não, não normal.

No entanto

Isso levanta a questão: é possível conectar-se a qualquer área de trabalho virtual em que o software será executado? (para que eu possa interagir com ele) (Isso está começando a soar como um pedido "Tenha meu bolo e coma também")

    

Answer 1

Embora eu esteja ciente de que este programa que você está executando está chegando - e o que essa "política de segurança equivocada que proíbe que sistemas autônomos permaneçam em execução" é ou qual problema ela resolve, há muitas VMs que rodam hospedar sistemas operacionais que são sem GUI.

Como você afirmou, o host ESX é sem gui. Também uma boa alternativa é VirtualBox que tem o conjunto de comandos VBoxHeadless e VBoxManage que executa e configura máquinas virtuais em headless Sistemas operacionais (sem GUI).

O sistema operacional Guest, W2K3 ou qualquer outro, funciona da mesma forma que em um host GUI. O sistema operacional está lá, rodando em um adaptador gráfico "virtual". Você pode RDP na VM e tem o sistema operacional baseado em GUI, assim como seria um servidor separado no datacenter.

Para resumir, seus programas baseados em gui rodarão perfeitamente bem em seu sistema operacional convidado normal com o Gui, independentemente de o SO do Host ser sem interface ou não.

    

Answer 2

Apenas para reiterar que a VM em si não é "sem cabeça", acredita que ela tem um desktop GUI em execução em um adaptador de vídeo virtualizado se você tiver um SO instalado que execute uma interface GUI. Você pode não ter nada realmente conectado à instância da VM para "ver" a área de trabalho, mas ela existe e, no que diz respeito ao software, não deve ser diferente de uma área de trabalho física real.

Se o host que está sendo executado é Headless ou não terá nenhum efeito. Na verdade, o mesmo se aplica a um sistema independente. Eu também seriamente questionar a política de segurança do sistema autônoma - como você lida com servidores padrão certamente eles executam autônoma?