Rss

  • youtube
  • linkedin
  • google

Archives for : VDI

Como diminuir o tamanho de discos virtuais VMDK – parte 3

Se desejar ler a parte 1 deste tutorial, clique aqui.
Se desejar ler a parte 2 deste tutorial, clique aqui.

No item anterior fizemos uma clonagem de um disco com uma única partição. Nas próximas linhas vou mostrar como clonei um disco com uma única partição primária e uma lógica para duas partições primárias e uma lógica com um ponto de montagem para o swap que originalmente estava em um arquivo.

NOTA: Utilizei como fonte esse site, para resolver problemas com a inicialização do novo disco. Faça como eu, sempre cite suas fontes.

Usando como base as informações da parte 1 deste tutorial, adicionaremos um novo disco à máquina virtual.

Continue lendo >>

Como diminuir o tamanho de discos virtuais VMDK –; parte 2

Se ainda não leu a parte 1, pode acessar ela por aqui.

Continuando o tutorial, iremos agora iniciar a clonagem dos discos. A primeira parte da clonagem é de um disco que não contem o sistema operacional. Se quiser ir direto para a clonagem com o sistema inicializável, pode pular esta parte e ir direto para a parte 3.

Hora de iniciar a clonagem. Iniciamos a máquina virtual no modo terminal (para caso tenha ambiente gráfico) e logamos como root ou nos tornamos root com o comando su –; para que seja possível executar as instruções de particionamento, formatação e clonagem, respectivamente sem necessidade de sudo a todo comando.

No terminal digite fdisk -l para que sejam listados os discos e as partições:

[root@Address21 ~]# fdisk -l

Disk /dev/sda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders Units = cilindros of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0004f229

...(detalhes das partições do dispositivo /dev/sda)...

Disk /dev/sdb: 221.8 GB, 221807247360 bytes
255 heads, 63 sectors/track, 26966 cylinders Units = cilindros of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000

Disk /dev/sdc: 214.7 GB, 214748364800 bytes
255 heads, 63 sectors/track, 26108 cylinders Units = cilindros of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000

Repare que nossos discos aparecem como sendo /dev/sda, /dev/sdb, /dev/sdc (marquei em vermelho para ficar mais visível) e ao lado o seu tamanho. Essa ordem a, b, c é a ordem de conexão na porta IDE. Como nosso disco foi incluído em Secundário Slave e o Primário Slave está o CDROM (vide imagem na parte 1) ele é o terceiro disco do sistema, ou seja, o /dev/sdc.
Iremos a partir de agora particionar e formatar a unidade. Digite o comando fdisk /dev/sdc.

Continue lendo >>

Como diminuir o tamanho de discos virtuais VMDK –; parte 1

Onde trabalho temos alguns servidores de bancos de dados PostgreSQL em diversas máquinas virtuais rodando em um servidor VMWare. Até aí tudo bem, não fosse um detalhe que estava me incomodando. Todos eles usando versões antigas como 8.1 e 8.2, enquanto a versão atual é a 9.3.
Procurei saber e descobri que há versão 9.3 para o Centos 6.5 que é o que estamos usando para os novos servidores e resolvi então unificar os três servidores em um só.

Se você que leu até aqui e pensou “;Unificar servidores?? Que buro! dá zero pra ele!; saiba que isso foi pensado e para nossa realidade é uma solução adequada.

Dito isso e com o dilema resolvido, parti para criar uma VM usando o Vagrant.

O Vagrant é uma excelente ferramenta de auxilio a nós DevOps. Com o uso dele podemos criar máquinas que podem ser facilmente compartilhadas entre os membros de uma equipe. Não vou entrar em detalhes de seu uso, apenas informar que utilizei uma Box de Centos 6.5 básica.

Até aqui estava tudo indo muito bem. Configurei a VM toda e instalei os softwares que iria utilizar, incluindo o PostgreSQL 9.3.

Quando fui migrar a base de produção é que começaram alguns problemas. O diretório do PGDATA, que é onde o PostgreSQL armazena os dados das tabelas, estava com mais de 40 GB. Fazer um dumpall e um restore on-the-fly não era uma opção e resolvi extrair o banco inteiro para posteriormente restaurar na VM.

Continue lendo >>