XenServer - Arquivos de log

     Provavelmente não seja nenhuma novidade falar que os logs do XenServer são armazenados no diretório /var/logs, pois é onde realmente se espera encontra lós.
     No entanto, o que diferencia são os aquivos presentes neste diretório e a sua finalidade. Em um sistema operacional linux os logs seriam encontrados em /var/logs alguns arquivos como:

• auth.log:armazena logs de autenticação;
  
• boot.log: informações relacionadas à inicialização;
• cron: armazena todas as mensagens relacionadas a Crond (tarefas cron) ;
• daemon: registros pertinentes aos daemons em execução no servidor; 
• dmesg: mensagens relacionadas aos drivers de dispositivo;
• faillog: contém informações sobre todas as tentativas de login falhas;
• mail.log: armazena todos os logs relacionados aos servidores de e-mail
• kern.log: armazena logs do Kernel e dados de aviso.
• syslog: mensagens gerais;

    Já no XenServer, alguns desdes diretórios não estão presentes, ao mesmo passo que outros arquivos não encontrados em servidores linux, são exibidos no XenServer. Dentre eles os principais são:

• audit.log:  informações detalhadas sobre as RBCA-roles (role-based access control) ou controle de acesso baseado em funções;
• installer: diretório com registros do processo de instalação;
• secure: registro das conexões realizadas ao XenServer, variando entre XenCenter e acessos via ssh;
• SMLog: arquivo com registros das ações relacionadas ao armazenamento, tais como montagem, conexões e verificações do status das conexões; 
• xensource.log: arquivo  com o registros dos eventos realizados pelo conjunto de ferramentas utilizado para gerenciamento do XenServer, denominado XAPI. Devido ao seu nível de detalhamento é um pouco mais complicado de ser analisado.

      Outros destinos dos logs também poder ser observados na imagens abaixo, que lista o conteúdo do diretório /var/log.

Referências 

• https://xenserver.org/partners/developing-products-for-xenserver/20-dev-hints/90-xs-log-debug-understand.html
• https://cleriston.com.br/post/110423117208/o-que-e-o-xapi
• Virtualization Security: Protecting Virtualized Environments

Switch virtual interface (SVI)

     Geralmente, switches gerenciáveis permitem a criação de interfaces virtuais criadas no software para fornecer um meio de acesso via rede usando IPv4/6, denominadas de SVI, as quais se comportam como interfaces físicas, possindo inclusive um endereço MAC.

     Em geral, cada switch é fornecido com um SVI padrão definida como interface vlan 1, sendo necessário realizar a configuração de rede para permitir acesso remoto.

Configuração SVI

     A sequência de comandos a seguir foi executa da em um switch Catalyst da Cisco e habilita administrativamente e atribui um endereço IP a interface Vlan 1, tornando possível assim o acesso via rede

switch(config)#interface vlan 1
switch(config-if)#ip address 192.168.1.10 255.255.254.0
switch(config-if)#no shutdown
%LINK-5-CHANGED: Interface Vlan1, changed state to up
switch(config-if)#

     Assim como aplicada a Vlan 1, interfaces virtuais podem ser criadas para outras Vlans que estejam presentes no equipamento, sendo necessário também a criação da Vlan, pois a criação da interface para uma Vlan não existente não realiza a criação da Vlan de forma automática.
     Essas configurações permitem que o equipamento seja encontrado na rede através de um endereço IP, sendo necessário configurações adicionais para que seja realizado um acesso remoto, tal como a definição do gateway, configurações de uplink entre switches, configurações de Vlan entre outros. 
   

Teste de configuração

     Dentre os vários testes que podem ser realizados para verificar o funcionamento da configuração aplicada, um deles que não necessita de gateway, por estar na mesma rede, consiste em:

1. configurar um computador na mesma rede
2. conectar em uma porta do switch que esteja em modo access e na vlan 1
• OBS: caso tenha configurado a interface virtual em outra Vlan, a porta access deve estar na Vlan na qual foi configurado o IP.
3. utilizar o comando ping para testar.

Referências

• https://www.grandmetric.com/knowledge-base/design_and_configure/how-to-create-svi-interface-cisco/ 
• https://www.ppgia.pucpr.br/~jamhour/Download/pub/RSS/old/VLANs.pdf

XenServer - Adicionando template do Ubuntu 18.04 LTS

     Um template é um modelo partir do qual se pode provisionar rapidamente uma nova VM. Mais detalhadamente, consiste em um arquivo com todas as informações de uma VM, tais como CPU, memória, tamanho do disco e recursos de rede. Em outras palavras, um template consiste em uma VM encapsulada com todas as suas informações.

      O Xen já disponibiliza templantes a serem escolhidos no momento da criação de uma nova VMs, os quais, além de conterem as definições básicas, auxiliam na definição de como ocorrerá a virtualização, se totalmente virtualizado o se paravirtualizada, dentre outros. Ademais, eles também não contam com sistema operacional instalado. 

     Já os templates criados a partir de VMs configuradas, possuem a vantagem de serem totalmente configurados, de acordo com quem realizou a preparação da sua VM de origem.

     Este post aborda o primeiro tipo de template, que é necessário ser criado geralmente quando ocorrem lançamento de novas versões de SOs que somente serão incluídas nas próximas versões do XenServer, tal como o Ubuntu Server 18.04 LTS, no XenServer 7.2.

Passo a passo:

1. Obter o UUID do template da versão anterior.

UUID=`xe template-list name-label="Ubuntu Xenial Xerus 16.04" params=uuid --minimal`

2. Clonar o template da versão anterior para um novo template, já com o nome da nova versão

NEW_UUID=`xe vm-clone uuid=$UUID new-name-label="Ubuntu Bionic Beaver 18.04"`

3. Setar como um template default

xe template-param-set uuid=$NEW_UUID other-config:default_template=true

Referências

• https://tecadmin.net/add-ubuntu-16-04-lts-template-on-xenserver/ 
• https://www.techhapa.com/2016/08/adding-ubuntu-1604-lts-template-in.html
• http://ports.marllus.com/2016/02/17/entendendo-templates-xenserver-6-5/

XenServer - Níveis de usuáros

     O XS (XenServer) apresenta por padrão cinco (5) Roles (níveis de usuários), denominados Pool Admin, Pool Operator, VM Power Admin, VM Admin, VM Operator ou Read-Only.  Estas roles são, com um conjunto de permissões que possibilitam garantir acesso total ou restringir  acessos mais específicos a cada usuário, conforme descrito a seguir.

• Pool Admin: maior nível de acesso, permitindo controle total a todas as funções e configurações do XS, incluindo o acesso a console do host, tendo permissão para executar comandos como root.
• Pool Operators: permite a execução de ações no nível do pool, como configurações de storage, gerenciamento de patches e a criação de resource pool. Também permite a configuração de Hight Availability, Workload Balancing, não tendo acesso a ações como inclusão de usuários e acesso console.
• VM Power Admin: os usuários pertencentes a esta role tem permissão para gerenciar máquinas virtuais, templates, snapshots, recurso de Dynamic Memory Control e definição de Home Server.
• VM Admin: permite o gerenciamento de VMs e templates sem acesso ao Dynamic Memory, snapshots e definição do Home Server.
• VM Operators: possuem permissão para gerenciar uma VM em questão, realizando algumas atividades básicas, não sendo possível alterar as propriedades daPolls máquinas virtuais, como memória e CPU.
• Read-Only: grupos associados a essa role terão acesso total somente leitura, não sendo permitido nenhuma modificação em todo o ambiente.

     É importante ressaltar que a inclusão de um usuário em uma role, permite que ele execute as funcionalidades a partir do XenCenter, sendo necessário a existência de um usuário na VM para que seja realizado o acesso ao SO.

Referências

• https://docs.citrix.com/en-us/xencenter/6-5/xs-xc-users/xs-xc-rbac-roles.html
• https://www.safaribooksonline.com/library/view/citrix-xenserver-60/9781849686167/ch02s04.html
• https://www.packtpub.com/mapt/book/virtualization_and_cloud/9781849686167/2/ch02lvl1sec20/roles-and-permissions
• https://cleristononline.wordpress.com/2015/02/19/testando-os-niveis-de-acesso/