[MASOCH-L] Virtualização - Regeneração de espaço não usado

[Fernando Frediani]

UNMAP foi uma feature que quando entrou no VMware causou muito problema com
alguns Storage Vendors que não implementaram corretamente nos seus
firmwares. Por isso na versao seguinte passou a vir desativada (ou era
recomendado desartivar no caso de instalaçao antiga).

Mesmo que o seus Storages digam que possue suporte consulte no São Google
se pessoas nao tiveram problemas com aquela versao de firmware que voce
roda. Muito provavel que hoje em dia ja esteja tudo corrigido, porem
estamos falando de Storage, entao todo cuidado é pouco.

Para recuperar espaço no tamanho do .vmdk caso voce tenha apagado conteudo
de dentro da VM nao tem segredo. O VMware nao vai dar Shrink
automaticamente. Você precisa fazer uma semi-gambiarra que é fazer um Live
Storage vMotion pra outro Datastore.
Existe um comando que dá pra executar dentro do ESXi mas eu nao lembro de
cabeça que ele varre o storage pra você e manda os comandos UNMAP pro
storage (pra quando voce ativou o UNMAP com o Datastore ja em produçao),
porem deve ser usado com cautela.

Fernando Frediani

On 20 Jul 2016 11:05, "Eduardo Rigler" <erigler at gmail.com> wrote:

> Sou peixe pequeno, tenho apenas algumas LUNs em um Storage administrado por
> terceiro, salvo engano é um DS8000.
>
> Meus Hospedeiros dizem o seguinte:
>
>    VAAI Plugin Name:
>    ATS Status: supported
>    Clone Status: supported
>    Zero Status: supported
>    Delete Status: unsupported
>
> Devices backing volume xxxxxxxx do not support UNMAP
>
>
> Configuração no Vmware:
>
> HardwareAcceleratedMove 1
> HardwareAcceleratedInit 1
> HardwareAcceleratedLocking 1
>
> Vou trocar uma ideia com o fornecedor pra ver isso.
>
> []´s
>
>
>
>
>
> Em 20 de julho de 2016 10:47, Douglas Fischer <fischerdouglas at gmail.com>
> escreveu:
>
> > ​O que está usando de Storage?
> > V7000? Ele está com o Block-Level-Dedup Ativado?​
> >
> > Essa seria a minha primeira sugestão.
> >
> >
> > Porém DEDUP é uma ferramenta PORRETA que deve ser usada com cautela!
> > CPU e Memory Intensive no Storage.
> >
> > Eu sempre uso a abordagem de 3 Virtual-Disks em cada VM, e para cada uma
> > dessas um Storage-Volume específico:
> > 1 - Instalação do Sistema Operacional
> >      - Dedup com certeza!
> >        - E quanto mais parecidos os S.O.s melhor será.
> >          Windows, todos do mesmo. Linux, todos do mesmo.
> > 2 - Produção
> >      - Dedup depende da aplicação,
> >        - BD não, MS exchange não, etc...
> >        - WebServer Sim, FileServer Sim, APP-Server Sim, etc...
> > 3 - Swap/PageFile
> >      - Sem Dedup
> >
> >
> >
> >
> > Em 19 de julho de 2016 18:28, Eduardo Rigler <erigler at gmail.com>
> escreveu:
> >
> > > Olá pessoal,
> > >
> > > Em tempos de VM´s grandes e pouco espaço em Storage, qual a melhor
> forma
> > de
> > > recuperar o espaço que foi alocado mas não está mais em uso por alguma
> > VM?
> > >
> > > Já li muita documentação e grande parte indica baixar a VM, rodar algum
> > > comando mágico e subir novamente causando downtime e isso não é lá
> muito
> > > interessante. Alguns indicam sdelete (windows) ou dd (linux) e alguns
> > > outros indicam o VMware Converter, mas a mão de obra é grande e também
> > > existe algum downtime durante o processo.
> > >
> > > Uso Vmware em Cluster e um storage IBM via fibre channel e as VM´s são
> > > basicamente Debian, CentOS e Windows 2008R2 (todas em thin provision).
> > >
> > > Algum dos colegas tem alguma receitinha de bolo, dica ou mais algum
> link
> > > para leitura? :-)
> > >
> > >
> > > []´s
> > > __
> > > masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> > >
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>