Na última Quarta-feira(25/10) rolou o primeiro Ceph Day SP e o primeiro na América Latina organizado e realizado pelo nosso Manager Comunity Leonado Vaz e nosso amigo da Savant Marcos Sungaila, além de grandes patrocinadores como RedHat, Canonical, Suse entre outros…

Para quem não teve a oportunidade de estar presente perdeu um grande dia. Discutimos sobre a nova versão do Ceph, custos x performance, implementações, cases e principalmente o futuro do SDS

A chegada da nova versão Luminous LTS que já é uma realidade, virou um divisor de águas no mundo do Software Define Storage(SDS) com várias melhorias como o novo backend BlueStorage que leva o Ceph a um nível de performance 2x mais rápido eliminando a camada do filesystem, além de grandes melhorias em toda sua estrutura.

Precisando de baixa latência e alta performance? O Ceph te entrega, tivemos uma palestra da Intel, uma das grandes colaboradoras do código, falando sobre Ceph com All-Flash.

SSDs to Build High-Performance Cloud Storage Solutions

Para os amantes do Zabbix como eu, o novo serviço de gerenciamento do Ceph(ceph-mgr) foi ampliado com vários módulos python, um deles exporta o status geral do cluster para o Zabbix habilitando o modulo no Ceph e configurando o template no zabbix.

1
2
$ ceph zabbix config-set zabbix_host zabbix-server.local
$ ceph zabbix config-set identifier ceph.local

Para os amantes da interface GUI. Agora será possível ter um dashboard no Ceph de forma simples.

1
$ ceph mgr module enable dashboard

Acesse http://you_active_mgr_host:7000/

Outra grande novidade, agora já é possível fazer Erasure Coding tanto em RBD quanto em CephFS, que antes só era possível com object. Na mudança para o BlueStorage será possível suporta compressão de dados, trazendo mais economia no armazenamento.

E tem muito mais vindo por ai! Eu particularmente estou ansioso para o tão esperado QoS que está por vir na próxima versão ou dedup que será excelente para galera de backup. Aguardem que isso será só o começo da evolução que o Ceph vem trazendo para o mundo do Software Define Storage.

Referências:

http://ceph.com/releases/v12-2-0-luminous-released/

http://ceph.com/community/new-luminous-dashboard/

http://ceph.com/community/new-luminous-zabbix/

Que tal gerenciar seus Bare Metal com automação e eficiência? Te apresento o Metal as a Service (MaaS) uma ferramenta fantástica desenvolvida em Python pela Canonical que trás vários benefícios para gerenciar seus racks de Bare Metal e neste artigo irei falar um pouco das suas funções, instalação e configuração.

Segue abaixo algumas features do MaaS stable(2.2):

  • Suporte para Bare Metal (ARM,Intel), KVM, VMWARE
  • Provisiona com Ubuntu, RHEL, CENTOS, SLES, OpenSUSE, Windows
  • Divide recursos por zonas Bare Metal/VM
  • IPAM coleção de Subnets IPV4/IPV6, VLAN tagging, DNS, proxy, NTP
  • REST API intregraçao com ferramentas de Devops Juju, Chef, Ansible, Puppet
  • Descobre automaticamente ativos de redes, VLAN, Subnets etc..
  • Enlist automático por PXE
  • Interface GUI e CLI para Ligar/Desligar, comissionar, implantar, teste de hardware, modo de manutenção e recuperação de S.O
  • Composição Dinâmica de Hardware por meio de POD Suporta Intel Rack Scale Design (RSD) e Virsh(KVM)
  • Configuração de Rede IP,VLAN,BOND,BRIDGE layout de disco Bcache, RAID, LVM

O MaaS foi desenvolvido para ambientes em escala Bare Metal, mais também é possível gerenciar VM com Virsh(KVM). Suporta as principais BMCs e controladores de chassi do mercado como Dell, IBM, HP, Lenovo, Huawei e Open Compute Project, está sendo utilizado por grandes plays do mercado como Microsoft, Nec, Verizon, At&t, NTT atualmente sendo considerado uma das melhores ferramentas open source para gerenciamento de Bare Metal.

Como funciona

O MaaS possui uma arquitetura em camadas com um banco de dados postgresql usado na ‘Region Controller (regiond)’ que lida com as solicitações. Já o Distributed Rack Controllers (rackd) fornecem serviços para cada rack.

Region controller(regiond):

  • REST API server (TCP port 5240)
  • PostgreSQL database
  • DNS
  • caching HTTP proxy
  • Web GUI

Rack Controller (rackd) fornece DHCP, IPMI, PXE, TFTP e outros serviços locais. Os rackd armazenam itens como imagens de instalação do S.O no nível do rack para melhor desempenho, mas não mantenham nenhum estado além das credenciais para falar com o Region Controller.

Rack controller(rackd):

  • DHCP
  • TFTP
  • HTTP (para images)
  • iSCSI
  • Power Management

Tanto o regiond como o rackd podem ser escalados e configurados para alta disponibilidade.

Instalando o MaaS

Como podemos ver na arquitetura acima, em cada rack de servidor Bare Metal poderiamos ter um daemon chamado rackd que falaria via API com o regiond, isso e uma boa pratica para arquitetura de rede Layer 3 spine e leaf, mas neste exemplo vamos instalar tanto o regiond como o rackd em um unico servidor.

Adicionando repositorio e instalando o MaaS

1
2
# apt-add-repository -yu ppa:maas/stable
# apt install maas

Após instalação precisamos criar um usurário administrativo.

1
# maas createadmin 

Depois da criação vamos acessar o painel via browser

Acesse a URL:http://$API_HOST:5240/MAAS

Entre com login e senha criado no passo anterior

No primeiro login será apresentado uma tela de configuração, altere o nome da sua região se achar necessário e neste primeiro momento deixe como padrão os outros valores

Agora vamos verificar quais serviços estão ativos, no painel click em “Nodes” selecione a aba “Controller” selecione o servidor da sua controller depois click na aba “Services”.

Veja se sua img está sincronizada Click na Aba “Images”

  • Ativando DHCP

Vá para a aba “Subnets” e selecione a untagged VLAN/subnet para a qual você deseja habilitar o DHCP, e no botão “Take action” selecione “Provide DHCP”.

  • Defina o controlador de rack que gerenciará o DHCP.
  • Selecione a subrede para criar o intervalo dinâmico DHCP.
  • Preencha os detalhes para o intervalo dinâmico.

Após ativar o DHCP, podemos inciar os bare mental na rede configurada que automaticamente ela realizará o boot via PXE e iniciará o processo de enlist, assim aparecendo no menu “Node” do painel MaaS, abaixo veja como funciona o ciclo de vida do seu Bare Metal/VM dentro do MaaS.

Obs: para o MaaS conseguir Ligar e Desligar os servidores via IPMI será necessário um interface que chegue na rede da IDRAC e/ou ILO

Entenda o Lifecycle do MaaS

Cada máquina (“nó”) gerenciada pelo MAAS passa por um ciclo de vida desde o alistamento até o comissionamento quando o nó será inventariado e iremos poder configurar elementos específicos do hardware. No ciclo também é possível alocamos um servidor para um usuário, realizar o deployer, e finalmente liberar de volta para um pool ou deletar por completo.

Qualquer dúvida comentem aííí, até a proxima!!!!

Referências:

https://maas.io/

https://docs.ubuntu.com/maas/

O que é o Juju?

Juju é uma ferramenta open source de modelagem de aplicações desenvolvida em Go pela Canonical a mesma empresa que desenvolve o Linux Ubuntu.

Com Juju é possível implementar, configurar, gerenciar, manter e dimensionar aplicações em nuvens públicas e privadas de uma forma rápida e eficiente bem como servidores físicos, OpenStack e contêineres. O Juju pode ser usado tanto em linha de comando ou através de uma interface GUI

Como é feito a “Mágica”:

A partir dos charmes é possível realizar a criação de toda uma infraestrutura no nivel de configuração da maquina virtual, instalação e configuração das aplicações, interligações de dependências, tanto na AWS, Google, Azure, OpenStack entre outras nuvem suportadas ou diretamente no Bare-Metal.

Mas que desgraça é esse Charme?

O charme define tudo o que você conhece de forma colaborativa sobre a implantação da aplicação. Tudo o que você precisa fazer é usar qualquer charme disponível (ou escrever o seu próprio), e a aplicação correspondente será implantada em segundos, em qualquer nuvem, servidor físico ou máquina virtual.

O Charme nada mais é do que um receita de instalação e configuração com gerenciamento de dependencias e interligações nescessárias para sua aplicação funcionar em uma nuvem ou em um bare-metal.

Juju então é igual ao Chef, Puppet, Ansible e cia?

Não! O Juju orquestra e escala aplicações em nuvens, ele está uma camada acima dos gereciadores de configurações, mas podemos usar todos juntos perfeitamente.

O puppet, Chef e Ansible são ótimas ferramentas para escrever arquivos de configuração. Por trabalhar uma camada acima, o Juju concentra-se nas operações de longo prazo necessárias para manter esse software em execução ao longo do tempo, independentemente da máquina na qual ele está sendo executado. O charme do Juju para um aplicativo inclui (entre outras coisas) toda a lógica para escrever arquivos de configuração para as aplicações, essa lógica em si pode ser escrita em qualquer linguagem ou ferramenta que o desenvolvedor do charme preferi.

É comum que as pessoas comecem a criar um charme juntando Puppet ou Chef ou outros scripts que eles atualmente usam para automatizar a configuração do ambiente. Se o charme vai estar escrevendo e atualizando a configuração para o aplicativo, e já existem ferramentas para abstrair esse arquivo de configuração na sua linguagem preferida (Puppet,Ansible, etc…), então use isso no charme!

Como podemos ver o Juju consegue reunir várias ferramentas de automação, deixando você livre para criar seus charme com suas receitas e ferramentas favoritas, ainda melhor, dois charmes diferentes de diferentes equipes que usam ferramentas diferentes trabalharão felizes juntos para implantar uma solução.

Veja como é fácil instalar o Juju no Ubuntu Xenial

Para fins de teste vamos instalar o juju com o LXD, que no caso poderia ser uma nuvem ou um bare-metal

$ sudo apt install lxd zfsutils-linux

Para usar o LXD, seu usuário deve ser um membro do grupo lxd, verifique com o comando abaixo provavelmente já vai estar.

$ groups

Ao executar o comando abaixo, aceite todas respostas padrão nas configurações iniciais do LXD, ou mude caso achar melhor.

$ sudo lxd init 

LXD agora está basicamente configurado para funcionar com Juju.

Instalando JUJU:

$ sudo add-apt-repository --update ppa:juju/stable
$ sudo apt install juju

Tanto para LXD, Bare-Metal ou nuvem será necessário a criação de um controle para gerenciar.

# juju bootstrap localhost lxd-test 

Isso pode demorar alguns minutos, pois o LXD deve baixar uma imagem do linux.

Uma vez concluído o processo, veja se o controlador lxd-test foi criado com o comando abaixo:

# juju controllers 

O comando a seguir mostra o controlador, modelo e o usuário atualmente ativo:

#  juju whoami 

Implantando um aplicativo com Juju.

O comando abaixo vai até o Juju store pega um charme pronto chamado mediawiki-single e manda instalar no ambiente LXD que configuramos no inicio.

# juju deploy cs:bundle/mediawiki-single 

Após este comando, podemos verificando sua implementação:

# juju status

Comando de acesso ao ambiente criado

# juju ssh id_machine

Acesso GUI, o comando abaixo exibirá a URL de acesso a interface web do Juju.

# juju gui

Pegando a senha da controladora criada para logar no Juju Gui.

# juju show-controller --show-password

Mais comandos do Juju.

# juju help commands

Caso não queira realizar a instalação, a canonical disponibilizou um demo da sua interface GUI: https://demo.jujucharms.com/

Nos próximos posts irei apresentar:

- Juju com Cloud OpenStack

- MaaS para integração do Juju com Bare-Metal

-Deployando Ceph com Juju.

Referências

https://jujucharms.com/docs/stable/

Comments

Depois de 4 anos utilizando XenServer, chegou a hora de dá um até breve. Atualmente estou migrando alguns ambientes XenServer para Ovirt/KVM pela sua constante evolução e integração com o projeto Openstack que vem crescendo muito no cenário opensource.

Primeiro passo será exporta sua VM pelo XenCenter ou pelo seu node console conforme o comando abaixo.

# xe vm-export vm=<Name of VM> filename=<Name of file ending in ".xva">

Será gerado uma imagem com extensão .xva, jogue sua imagem exportada para seu node ovirt.

Desempacotando VM.

# tar -xvf vm.xva

No meu ambiente foi criado um diretório chamado Ref:10/

Baixe o script de migração (https://github.com/hswayne77/xenserverz_to_xen)

# wget wget https://raw.githubusercontent.com/hswayne77/xenserver_to_xen/master/xenmigrate_new.py

Execute os comandos para iniciar a migração da imagem.

# python xenmigrate.py -c Ref\:10/ vm.img

enmigrate 0.7.4 — 2011.09.13
(c)2011 Jolokia Networks and Mark Pace — jolokianetworks.com

convert ref dir : ./Ref:10/
to raw file : vm.img
last file : 20484
disk image size : 20 GB

RW notification every: 1.0GB
Converting: 1.0GBrw 2.0GBrw 3.0GBrw 4.0GBrw 5.0GBrw 6.0GBrw 7.0GBrw 8.0GBrw 9.0GBrw 10.0GBrw 11.0GBrw 12.0GBrw 13.0GBrw 14.0GBrw 15.0GBrw 16.0GBrw 17.0GBrw 18.0GBrw 19.0GBrw 20.0GBrw
Successful convert

Criando Domain Storage Export no Ovirt

Acesse no browse seu Ovirt Engine vá para:

Sistema -> Data Centers -> Default -> Storage -> Novo Domain

Crie um novo Dominio “Export” conforme a imagem abaixo.

Baixe a última versão do projeto “import-to-ovirt.pl” no seguinte link http://git.annexia.org/?p=import-to-ovirt.git

Instale as dependências

# yum install perl-XML-Writer perl-Sys-Guestfs

Agora vamos importa a vm.img para o Domain Export que criamos utilizando o import-to-ovirt.pl

# export LIBGUESTFS_BACKEND=direct
# ./import-to-ovirt.pl vm.img node1.supcom:/storage/export

Pode ser utilizado com imagem .qcow2

Verifique se tudo ocorreu bem com a criação do OVF

[root@node1 storage]# ls /storage/export/ad5e39a2-24d4-4a51-ac74-cfdf843c5f94/master/vms/88397ea1-196e-4aeb-8a57-29cff914caab/88397ea1-196e-4aeb-8a57-29cff914caab.ovf

Disponbilizando a VM no Ovirt Engine

Sistema -> Data Centers -> Default -> Cluster -> Default - > MVS -> Importar”:

Selecione o Export Domain criado, click em Carregar, Seleciona a VM, click na seta central, depois Próximo.

Click OK e aguarde a VM ser importada.

Após a importação será necessário realizar algumas alterações no momento da inicialização da VM:

  • Pressione “e” na inicialização do grub remova o “console=hvc0” e digite CTRL + X

Após a inicialização

  • Remova o “console=hvc0” /etc/default/grub e execute:

      # update-grub
    
  • Verifique se seu fstab está correto e não tenha entradas xvda

  • Verifique sua network os uuid e MAC serão diferentes.

  • Edite o /etc/inittab comente a linha “co:2345:respawn:/sbin/getty … ”:

A vm migrada estava com Debian 7 e a migração foi executada com sucesso seguindo os procedimentos acima

Referências:

https://gfnork.de/blog/how-to-import-qcow2-images-to-ovirt/

https://rwmj.wordpress.com/2015/09/18/importing-kvm-guests-to-ovirt-or-rhev/

http://blog.zwiegnet.com/linux-server/export-vm-command-line-xenserver-6/

https://wiki.debian.org/HowToMigrateBackAndForthBetweenXenAndKvm

Objetivo

Instalar Ovirt 4.0 Hosted Engine utilizando NFS

No meu ambiente instalei tudo em um único node, o ovirt engine como VM no meu primeiro node, juntamente com NFS, mas para ambiente maiores recomendo a separação dos componentes para obter uma melhor performance e HA.

Ambiente Utilizado

  • NODE1 FÍSICO: Intel Xeon 24 Core(Hyper-Threading) - 32G - CentoOS 7-x86_64-minimal
  • NFS STORAGE - 500GB
  • VM OVIRT MANAGER - Quad core, 16 GB RAM e 50 GB
  • SELINUX Desabilitado
  • NTP configurado

Necessário servidor DNS, mas utilizei local para esta instalação

# cat /etc/hosts

192.168.10.200  ovirtengine.supcom
192.168.10.201  node1.supcom

Instando e configurando NFS

# yum -y install nfs-utils

# mkdir -p /storage/{engine,data,iso} 

# chown 36:36 /storage/{engine,data,iso}

# cat /etc/exports

/storage/engine 192.168.10.0/24(rw,anonuid=36,anongid=36,all_squash)
/storage/data   192.168.10.0/24(rw,anonuid=36,anongid=36,all_squash)
/storage/iso    192.168.10.0/24(rw,anonuid=36,anongid=36,all_squash)

# exportfs -a

# systemctl enable nfs-server.service
# systemctl restart nfs-server.service

# showmount -e
Export list for node1.supcom:
/storage/engine *
/storage/data   *
/storage/iso*

Instalando pacotes necessários

# yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm
# yum install ovirt-hosted-engine-setup ovirt-engine-appliance -y

Iniciando deploy hosted engine

# hosted-engine --deploy
[ INFO  ] Stage: Initializing
[ INFO  ] Generating a temporary VNC password.
[ INFO  ] Stage: Environment setup
  During customization use CTRL-D to abort.
  Continuing will configure this host for serving as hypervisor and create a VM where you have to install the engine afterwards.

Are you sure you want to continue? (Yes, No)[Yes]: Yes

  It has been detected that this program is executed through an SSH connection without using screen.
  Continuing with the installation may lead to broken installation if the network connection fails.
  It is highly recommended to abort the installation and run it inside a screen session using command "screen".

Do you want to continue anyway? (Yes, No)[No]: Yes

[ INFO  ] Hardware supports virtualization
  Configuration files: []
  Log file: /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20161118133413-u1wg2v.log
  Version: otopi-1.5.2 (otopi-1.5.2-1.el7.centos)
[ INFO  ] Stage: Environment packages setup
[ INFO  ] Stage: Programs detection
[ INFO  ] Stage: Environment setup
[WARNING] Cannot locate gluster packages, Hyper Converged setup support will be disabled.
[ INFO  ] Please abort the setup and install vdsm-gluster, gluster-server >= 3.7.2 and restart vdsmd service in order to gain Hyper Converged setup support.
[ INFO  ] Stage: Environment customization

  --== STORAGE CONFIGURATION ==--

Please specify the storage you would like to use (glusterfs, iscsi, fc, nfs3, nfs4)[nfs3]: nfs3

Please specify the full shared storage connection path to use (example: host:/path): 192.168.10.201:/storage/engine

[ INFO  ] Installing on first host

  --== SYSTEM CONFIGURATION ==--


  --== NETWORK CONFIGURATION ==--

[ INFO  ] Bridge ovirtmgmt already created

iptables was detected on your computer, do you wish setup to configure it? (Yes, No)[Yes]: Yes

Please indicate a pingable gateway IP address [192.168.10.1]: 192.168.10.1

 --== VM CONFIGURATION ==--

      Booting from cdrom on RHEL7 is ISO image based only, as cdrom passthrough is disabled (BZ760885)

Please specify the device to boot the VM from (choose disk for the oVirt engine appliance) (cdrom, disk, pxe) [disk]: disk

Please specify the console type you would like to use to connect to the VM (vnc, spice) [vnc]: vnc

[ INFO  ] Detecting available oVirt engine appliances
  The following appliance have been found on your system:
[1] - The oVirt Engine Appliance image (OVA) - 4.0-20161115.1.el7.centos
[2] - Directly select an OVA file

Please select an appliance (1, 2) [1]: 1

[ INFO  ] Verifying its sha1sum
[ INFO  ] Checking OVF archive content (could take a few minutes depending on archive size)
[ INFO  ] Checking OVF XML content (could take a few minutes depending on archive size)
[WARNING] OVF does not contain a valid image description, using default.

Would you like to use cloud-init to customize the appliance on the first boot (Yes, No)[Yes]? Yes

Would you like to generate on-fly a cloud-init ISO image (of no-cloud type) or do you have an existing one (Generate, Existing)[Generate]? Generate

      Please provide the FQDN you would like to use for the engine appliance.
      Note: This will be the FQDN of the engine VM you are now going to launch,
      it should not point to the base host or to any other existing machine.

Engine VM FQDN: (leave it empty to skip): []: ovirtengine.supcom

Automatically execute engine-setup on the engine appliance on first boot (Yes, No)[Yes]? No

    Please provide the domain name you would like to use for the engine appliance.
    Engine VM domain: [supcom]

      Enter root password that will be used for the engine appliance (leave it empty to skip):
      Confirm appliance root password:
      The following CPU types are supported by this host:
             - model_SandyBridge: Intel SandyBridge Family
             - model_Westmere: Intel Westmere Family
             - model_Nehalem: Intel Nehalem Family
             - model_Penryn: Intel Penryn Family
             - model_Conroe: Intel Conroe Family
      Please specify the CPU type to be used by the VM [model_SandyBridge]:
      Please specify the number of virtual CPUs for the VM (Defaults to appliance OVF value): [4]:
      [WARNING] Minimum requirements for disk size not met
      You may specify a unicast MAC address for the VM or accept a randomly generated default [00:16:3e:77:82:77]:
      Please specify the memory size of the VM in MB (Defaults to appliance OVF value): [16384]:

How should the engine VM network be configured (DHCP, Static)[DHCP]? Static Please enter the IP address to be used for the engine VM [192.168.10.2]: 192.168.10.200

      [ INFO  ] The engine VM will be configured to use 192.168.10.200/24
      Please provide a comma-separated list (max 3) of IP addresses of domain name servers for the engine VM

Engine VM DNS (leave it empty to skip) [8.8.8.8]: 8.8.8.8

      Add lines for the appliance itself and for this host to /etc/hosts on the engine VM?

Note: ensuring that this host could resolve the engine VM hostname is still up to you (Yes, No)[No] Yes

      --== HOSTED ENGINE CONFIGURATION ==--

      Enter engine admin password:
      Confirm engine admin password:
      Enter the name which will be used to identify this host inside the Administrator Portal [hosted_engine_1]: node1-engine
      Please provide the name of the SMTP server through which we will send notifications [localhost]:
      Please provide the TCP port number of the SMTP server [25]:
      Please provide the email address from which notifications will be sent [root@localhost]:
      Please provide a comma-separated list of email addresses which will get notifications [root@localhost]:
        [ INFO  ] Stage: Setup validation

      --== CONFIGURATION PREVIEW ==--

      Bridge interface                   : em2
      Engine FQDN                        : ovirtengine.supcom
      Bridge name                        : ovirtmgmt
      Host address                       : node1.supcom
      SSH daemon port                    : 22
      Firewall manager                   : iptables
      Gateway address                    : 192.168.10.1
      Host name for web application      : node1-engine
      Storage Domain type                : nfs3
      Host ID                            : 1
      Image size GB                      : 10
      Storage connection                 : 192.168.10.201:/storage/engine
      Console type                       : vnc
      Memory size MB                     : 16384
      MAC address                        : 00:16:3e:17:ac:23
      Boot type                          : disk
      Number of CPUs                     : 4
      OVF archive (for disk boot)        : /usr/share/ovirt-engine-appliance/ovirt-engine-appliance-4.0-20161115.1.el7.centos.ova
      Appliance version                  : 4.0-20161115.1.el7.centos
      Restart engine VM after engine-setup: True
      CPU Type                           : model_SandyBridge

Acima o resumo da minha configuração, mude o que achar necessário conforme seu ambiente.

Please confirm installation settings (Yes, No)[Yes]: Yes

    [ INFO  ] Stage: Transaction setup
    [ INFO  ] Stage: Misc configuration
    [ INFO  ] Stage: Package installation
    [ INFO  ] Stage: Misc configuration
    [ INFO  ] Configuring libvirt
    [ INFO  ] Configuring VDSM
    [ INFO  ] Starting vdsmd
    [ INFO  ] Waiting for VDSM to reply
    [ INFO  ] Creating Storage Domain
    [ INFO  ] Creating Storage Pool
    [ INFO  ] Connecting Storage Pool
    [ INFO  ] Verifying sanlock lockspace initialization
    [ INFO  ] Creating Image for 'hosted-engine.lockspace' ...
    [ INFO  ] Image for 'hosted-engine.lockspace' created successfully
    [ INFO  ] Creating Image for 'hosted-engine.metadata' ...
    [ INFO  ] Image for 'hosted-engine.metadata' created successfully
    [ INFO  ] Creating VM Image
    [ INFO  ] Extracting disk image from OVF archive (could take a few minutes depending on archive size)
    [ INFO  ] Validating pre-allocated volume size
    [ INFO  ] Uploading volume to data domain (could take a few minutes depending on archive size)
    [ INFO  ] Image successfully imported from OVF
    [ INFO  ] Destroying Storage Pool
    [ INFO  ] Start monitoring domain
    [ INFO  ] Configuring VM
    [ INFO  ] Updating hosted-engine configuration
    [ INFO  ] Stage: Transaction commit
    [ INFO  ] Stage: Closing up
    [ INFO  ] Creating VM
      You can now connect to the VM with the following command:
            hosted-engine --console
      You can also graphically connect to the VM from your system with the following command:
            remote-viewer vnc://node1.supcom:5900
      Use temporary password "1485XCFX" to connect to vnc console.
      Please ensure that your Guest OS is properly configured to support serial console according to your distro documentation.
      Follow http://www.ovirt.org/Serial_Console_Setup#I_need_to_access_the_console_the_old_way for more info.
      If you need to reboot the VM you will need to start it manually using the command:
      hosted-engine --vm-start
      You can then set a temporary password using the command:
      hosted-engine --add-console-password
      Please install and setup the engine in the VM.
      You may also be interested in installing ovirt-guest-agent-common package in the VM.


      The VM has been rebooted.
      To continue please install oVirt-Engine in the VM
      (Follow http://www.ovirt.org/Quick_Start_Guide for more info).

      Make a selection from the options below:
      (1) Continue setup - oVirt-Engine installation is ready and ovirt-engine service is up
      (2) Abort setup
      (3) Power off and restart the VM
      (4) Destroy VM and abort setup

      (1, 2, 3, 4)[1]:

A partir desse ponto você precisar conectar na VM via VNC, para inciar o setup da engine.

Na minha instalação eu utilizei o Tightvnc (http://www.tightvnc.com/download.php)

Após acessar via vnc a maquina virtual, execute o seguinte comando

[root@ovirtengine ~]# engine-setup
[ INFO  ] Stage: Initializing
[ INFO  ] Stage: Environment setup
  Configuration files: ['/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf', '/etc/ovirt-engine-setup.conf.d/10-packaging.conf']
  Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-20161118191609-oxmvpo.log
  Version: otopi-1.5.2 (otopi-1.5.2-1.el7.centos)
[ INFO  ] Stage: Environment packages setup

......................
......................

--== END OF CONFIGURATION ==--

[ INFO  ] Stage: Setup validation
[WARNING] Cannot validate host name settings, reason: cannot resolve own name 'ovirtengine'

      --== CONFIGURATION PREVIEW ==--

      Application mode                        : both
      Default SAN wipe after delete           : False
      Firewall manager                        : firewalld
      Update Firewall                         : True
      Host FQDN                               : ovirtengine.supcom
      Engine database secured connection      : False
      Engine database host                    : localhost
      Engine database user name               : engine
      Engine database name                    : engine
      Engine database port                    : 5432
      Engine database host name validation    : False
      DWH database secured connection         : False
      DWH database host                       : localhost
      DWH database user name                  : ovirt_engine_history
      DWH database name                       : ovirt_engine_history
      DWH database port                       : 5432
      DWH database host name validation       : False
      Engine installation                     : True
      NFS setup                               : False
      PKI organization                        : supcom
      Configure local Engine database         : True
      Set application as default page         : True
      Configure Apache SSL                    : True
      DWH installation                        : True
      Configure local DWH database            : True
      Engine Host FQDN                        : ovirtengine.supcom
      Configure Image I/O Proxy               : True
      Configure VMConsole Proxy               : True
      Configure WebSocket Proxy               : True

      Please confirm installation settings (OK, Cancel) [OK]: OK

Retirei parte do log padrão para não ficar muito grande o post, acima segue o resumo da minha configuração. Visto que todo ambiente será instalado nessa vm, tanto banco de dados como o DWH, então basta confirmar e seguir a configuração padrão.

[ INFO  ] Stage: Transaction setup
[ INFO  ] Stopping engine service
[ INFO  ] Stopping ovirt-fence-kdump-listener service
[ INFO  ] Stopping dwh service
[ INFO  ] Stopping Image I/O Proxy service
[ INFO  ] Stopping websocket-proxy service
[ INFO  ] Stage: Misc configuration
[ INFO  ] Stage: Package installation
[ INFO  ] Stage: Misc configuration
[ INFO  ] Upgrading CA
[ INFO  ] Initializing PostgreSQL
[ INFO  ] Creating PostgreSQL 'engine' database
[ INFO  ] Configuring PostgreSQL
[ INFO  ] Creating PostgreSQL 'ovirt_engine_history' database
[ INFO  ] Configuring PostgreSQL
[ INFO  ] Creating CA
[ INFO  ] Creating/refreshing Engine database schema
[ INFO  ] Creating/refreshing DWH database schema
[ INFO  ] Configuring Image I/O Proxy
[ INFO  ] Setting up ovirt-vmconsole proxy helper PKI artifacts
[ INFO  ] Setting up ovirt-vmconsole SSH PKI artifacts
[ INFO  ] Configuring WebSocket Proxy
[ INFO  ] Creating/refreshing Engine 'internal' domain database schema
[ INFO  ] Generating post install configuration file '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'
[ INFO  ] Stage: Transaction commit
[ INFO  ] Stage: Closing up
[ INFO  ] Starting engine service
[ INFO  ] Restarting nfs services
[ INFO  ] Starting dwh service
[ INFO  ] Restarting ovirt-vmconsole proxy service

  --== SUMMARY ==--

[ INFO  ] Restarting httpd
  Please use the user 'admin@internal' and password specified in order to login
  Web access is enabled at:
  http://ovirtengine.supcom:80/ovirt-engine
  https://ovirtengine.supcom:443/ovirt-engine
  Internal CA 81:C1:01:AD:28:0E:46:8F:86:A8:BB:12:E9:BB:2B:5F:0E:8C:F0:8D
  SSH fingerprint: d7:7b:83:5b:54:6e:46:7b:c1:2c:c0:6e:ae:a1:4c:1e

  --== END OF SUMMARY ==--

[ INFO  ] Stage: Clean up
  Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20161118192015-muij8n.log
[ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20161118192638-setup.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Execution of setup completed successfully

Após a finalização, vamos voltar para o node1 e selecionar a primeira opção, para finalizar.

Make a selection from the options below:
  (1) Continue setup - oVirt-Engine installation is ready and ovirt-engine service is up
  (2) Abort setup
  (3) Power off and restart the VM
  (4) Destroy VM and abort setup

  (1, 2, 3, 4)[1]: 1

Checking for oVirt-Engine status at ovirtengine.supcom...
[ INFO  ] Engine replied: DB Up!Welcome to Health Status!
[ INFO  ] Acquiring internal CA cert from the engine
[ INFO  ] The following CA certificate is going to be used, please immediately interrupt if not correct:
[ INFO  ] Issuer: C=US, O=supcom, CN=ovirtengine.supcom.60122, Subject: C=US, O=supcom, CN=ovirtengine.supcom.60122, Fingerprint (SHA-1): 81C101AD280E468F86A8BB12E9BB2B5F0E8CF08D
[ INFO  ] Connecting to the Engine
[ INFO  ] Waiting for the host to become operational in the engine. This may take several minutes...
[ INFO  ] Still waiting for VDSM host to become operational...
[ INFO  ] The VDSM Host is now operational
[ INFO  ] Saving hosted-engine configuration on the shared storage domain

  Please shutdown the VM allowing the system to launch it as a monitored service.
  The system will wait until the VM is down.

Agora vamos voltar ao ovirtengine e reiniciar a vm.

[root@ovirtengine ~]# shutdown -r now

Voltando ao node1, percebemos que a instalação finalizou com sucesso.

[ INFO  ] Enabling and starting HA services
[ INFO  ] Stage: Clean up
[ INFO  ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20161118174208.conf'
[ INFO  ] Generating answer file '/etc/ovirt-hosted-engine/answers.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Hosted Engine successfully deployed
[root@node1 ~]#

Vamos agora iniciar o hosted-engine

[root@node1 ~]# hosted-engine --vm-start

Caso a vm ovirtengine não inicie, restart os serviços

[root@node1 ~]# systemctl restart ovirt-ha-agent && systemctl restart ovirt-ha-broker && systemctl restart vdsmd
[root@node1 ~]# hosted-engine --vm-start
[root@node1 ~]# hosted-engine --vm-status

--== Host 1 status ==--

Status up-to-date  : True
Hostname   : node1.supcom
Host ID: 1
Engine status  : {"health": "good", "vm": "up", "detail": "up"}
Score  : 3400
stopped: False
Local maintenance  : False
crc32  : f322c3c1
Host timestamp : 235828
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=235828 (Mon Nov 21 13:29:31 2016)
host-id=1
score=3400
maintenance=False
state=EngineUp
stopped=False

Agora vá para browser e acesse o portal de administração

https://ovirtengine.supcom/ovirt-engine/

login:admin

senha: que você configurou na instalação

Adicionando Storage Data

Sistema -> Data Centers -> Default -> Storage -> Novo Dominio”:

Adicionando Storage ISO

Agora basta aguarda o storage ficar ativo.

Adicionando imagem ISO no Dominio criado

Acesse o ovirtengine e digite os comandos abaixo

[root@ovirtengine ~]# wget http://mirror.globo.com/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1511.iso

[root@ovirtengine ~]# engine-iso-uploader upload -i node1-iso CentOS-7-x86_64-Minimal-1511.iso -r ovirtengine.supcom --insecure
Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to abort):
Uploading, please wait...
INFO: Start uploading CentOS-7-x86_64-Minimal-1511.iso
Uploading: [########################################] 100%
INFO: CentOS-7-x86_64-Minimal-1511.iso uploaded successfully

Caso receba nfs timeout verifique se o firewall do node1.supcom não está bloqueando.

Criando VM

Sistema -> Data Centers -> Default -> Cluster -> Default - > MVS -> Novo MV”:

Após digitar o nome da VM, vamos criar o disco da VM em “Imagens de Instâncias” click em Criar

Digite o Tamanho, verifique se o storage domain está correto e click em OK

Selecione a rede que foi configurada por padrão na instalação.(bridge ovirtmgmt)

Configure a memória e o CPU e click em OK.

Agora vamos iniciar a VM clicando em “Executar uma vez” para iniciar o sistema com boot da nossa ISO CentOS

Selecione nossa ISO e marque a opção “Colocar CD”

Agora vamos Abrir o Console da VM para iniciar a Instalação.

Para o Remote Viewer abrir será nescessario baixar O Virt Manager (https://virt-manager.org/download/)

Troubleshooting:

Resolvendo problema com “ Failed to acquire lock: No space left on device ” ao iniciar a vm hosted engine

[root@node1 ~]# vdsClient -s 0 list
.........
.........
exitMessage = Failed to acquire lock: No space left on device
..........
..........
[root@node1 ~]# hosted-engine --vm-poweroff
[root@node1 ~]# sanlock direct init -s hosted-engine:0:/rhev/data-center/mnt/<INTERNAL HE SD>/<SDUUID>/ha_agent/hosted-engine.lockspace:0
[root@node1 ~]# systemctl restart ovirt-ha-agent && systemctl restart ovirt-ha-broker && systemctl restart vdsmd && systemctl restart supervdsmd 
[root@node1 ~]# hosted-engine --vm-start

Referência:

http://www.ovirt.org/documentation/

Comments

rysnc

Olá turmadaaa, precisei realizar uma transferência de uma VM do XenServer com 300G que estava em um ponto de montagem NFS para um outro local remoto e para evitar problemas de interrupção, utilizei o comando abaixo que me permiti continuar a transferência em casos de problemas, como perda de conexão etc…

# rsync -vrlPtz --append /mnt/web.xva /storage/export/
    sending incremental file list
    web.xva     4641783808   1%   6.89MB/s    9:57:11

O Comando acima basicamente irá comprimir, continuar e salvar parcialmente apresentando a saída em detalhes. Pode ser utilizado com apenas um arquivo ou com diretórios.

Caso queira usar com ssh:

# rsync -vrlPtz --append -e 'ssh -p 2222' login@host:/tmp/web.xva /tmp/web.xva

Dica SSH Com Tunnel: ssh -L 2222:hostlocal:2222 root@hostremoto


Referência:

https://download.samba.org/pub/rsync/rsync.html

No Brasil funciona assim:

  • Itaú Digital = Desemprego

  • Uber = Desemprego

Passamos da era agrícola, industrial, o mundo já está entrando na era pós tecnológica. Porque será que apenas no Brasil não dá certo? Será que nosso País não evoluiu ao ponto de entender que o mundo mudou?

Em vários lugares a era digital foi melhor para o consumidor, está claro que proibir o progresso e o desenvolvimento para manter empregos antiquados será menos efetivo e pior para todos! Alguns dos empregos mais desejados hoje não existiam a 10 anos atrás, estamos entrando em uma era de novas oportunidades, entenda que empregos morrem e empregos nascem.

Atualmente tive problema com interface invalida ao atualizar provisionamento do host utulizando o dashboard no satellite 6.2.

Este problema ocorre por alguma mudança na interface que foi atualizado pelo factor do satellite e no momento a interface não existe mais e/ou está inconsistente com os dados fornecidos.

Abaixo executo comandos para contorna esse problema, removendo uma interface invalida no host.

# foreman-rake console
Loading production environment (Rails 4.1.5)

irb(main):001:0> host = Host.find_by_name('HOSTNAME')

irb(main):003:0> i = host.interfaces[1]

irb(main):004:0> i.destroy

Trocando o array “host.interfaces[0,1,2]” você pode navegar em todas interfaces, veja no dashboard ao editar e atualizar o host, quais estão apresentado problemas e remova pelo foreman-rake.

Caso queira editar algum atributo da interface pelo foreman-rake utilize da seguinte forma.

# foreman-rake console
Loading production environment (Rails 4.1.5)

irb(main):001:0> host = Host.find_by_name('HOSTNAME')

irb(main):002:0> i = host.interfaces[0]

irb(main):003:0> i.name = "hostname"

irb(main):004:0> i.save!

Adpatando os comandos acima pode ser alterar varios atributos do provisionamento pelo foreman-rake.