Grupo de volumes LVM compartilhado entre host e convidados KVM / libvirt: isso é uma má idéia?

Acabei de criar um novo e brilhante host de máquina virtual baseado em KVM / libvirt, contendo 4 discos rígidos SATA II e executando o CentOS 5.5 x86_64.

Decidi criar discos de máquinas virtuais como volumes lógicos em um grupo de volumes LVM gerenciado como um pool de armazenamento libvirt, em vez da prática usual de criar os discos como imagens qcow.

O que não consigo decidir é se devo criar os volumes lógicos da máquina virtual no grupo de volumes do host da VM ou em um grupo de volumes dedicado.

Qual método devo escolher e por quê?

Método 1: usar o grupo de volumes do host da VM

Implementação:

• RAID1 pequeno md0contendo o /bootsistema de arquivos
• RAID10 grande md1ocupando o espaço restante, que contém um grupo de volumes LVM vghost. vghostcontém o sistema de arquivos raiz e a partição swap do host da VM
• crie discos de máquina virtual como volumes lógicos vghostconforme necessário

Prós:

• se o sistema de arquivos raiz do host da VM ficar sem espaço, eu posso alocar mais espaço vghostcom relativa facilidade
• O sistema já está em funcionamento (mas não é grande coisa começar de novo)

Contras:

Apesar do fato de esse método parecer funcionar, não posso deixar de pensar que essa é uma má ideia. Eu sinto isso:

• isso pode de alguma forma ser um risco à segurança
• em algum momento no futuro, posso encontrar algumas limitações na configuração e desejar usar um grupo dedicado
• o sistema (CentOS, libvirt etc.) pode não ser realmente projetado para ser usado dessa maneira e, portanto, em algum momento, eu posso acidentalmente corromper / perder os arquivos e / ou o sistema de arquivos do host da VM

Método 2: usar um grupo de volumes dedicado

Implementação:

• igual md0e md1no método 1, exceto que seja md1grande o suficiente para conter o host da VM (por exemplo, 5 a 10 GB)
• RAID10 grande ocupando md2o espaço restante. md2contém um grupo de volumes LVM vgvms, cujos volumes lógicos devem ser usados ​​exclusivamente por máquinas virtuais

Prós:

• Posso mexer vgvmssem medo de quebrar o sistema operacional host
• esta parece ser uma solução mais elegante e segura

Contras:

• se o sistema de arquivos do host da VM ficar sem espaço, eu precisaria mover partes do sistema de arquivos (por exemplo, / usr ou / var) para o vgvmsque não parece muito bom.
• Tenho que reinstalar o sistema operacional host (o que, como mencionado anteriormente, não me importo de fazer)

ATUALIZAÇÃO # 1:

Uma razão pela qual estou preocupado com a falta de espaço em disco do host da VM no método 2 é porque não sei se o host da VM é poderoso o suficiente para executar todos os serviços em máquinas virtuais, por exemplo. Talvez eu precise migrar alguns / todos os serviços de máquinas virtuais para o SO host.

Especificação de hardware do host da VM:

• Processador Phenom II 955 X4 Black Edition (3,2 GHz, CPU de 4 núcleos)
• 2x4GB Kingston PC3-10600 DDR3 RAM
• Placa-mãe Gigabyte GA-880GM-USB3
• HDDs 4x WD Caviar RE3 de 500 GB SATA II (7200rpm)
• Fonte de alimentação Antec BP500U Basiq 500W ATX
• Gabinete CoolerMaster CM 690

ATUALIZAÇÃO # 2:

Uma razão pela qual sinto que o sistema pode não ser projetado para usar o host VG como um pool de armazenamento libvirt no Método 1 é um comportamento que notei no virt-manager:

• ao adicionar, ele reclamou que não podia ativar o VG (obviamente, porque o sistema operacional host já o ativou)
• ao remover, recusou-se a fazê-lo porque não pôde desativar o VG (obviamente, porque o sistema operacional host ainda está usando os LVs raiz e de troca)

Pergunta bem pensada!

Eu iria com o método 2, mas isso é mais uma preferência pessoal. Para mim, os contras do método 2 não são um problema. Não vejo o sistema operacional host superando sua partição de 5 a 10 GB, a menos que você comece a instalar coisas extras nele, o que realmente não deveria. Por uma questão de simplicidade e segurança, o sistema operacional host realmente deve ser uma instalação mínima, sem executar nada, exceto o mínimo necessário para a administração (por exemplo, sshd).

Os contras do método 1 também não são realmente um problema, IMO. Eu não acho que haveria um risco extra à segurança, pois se uma VM raiz for capaz de interromper sua partição e infectar / danificar outras partições, ter o SO host em um VG separado pode não fazer nenhuma diferença. Os outros dois Contras não são algo com que eu possa falar por experiência direta, mas eu acho que o CentOS, LVM e libvirt são flexíveis e robustos o suficiente para não se preocupar com eles.

EDIT - Resposta à Atualização 1

Hoje em dia, o impacto no desempenho da virtualização é muito baixo, especialmente usando processadores com suporte embutido para isso, então não acho que valha a pena mover um serviço de uma VM convidada para o SO host. Você pode obter um aumento de 10% na velocidade executando o "bare metal", mas perderia os benefícios de ter um sistema operacional host pequeno, rígido e seguro e potencialmente impactaria a estabilidade de todo o servidor. Não vale a pena, IMO.

À luz disso, eu ainda seria a favor do método 2.

Resposta à atualização 2

Parece que a maneira particular pela qual libvirt assume que o armazenamento é organizado é outro ponto a favor do método 2. Minha recomendação é: vá com o método 2.

Desde que apenas um sistema tente usar qualquer LV fornecido no modo de leitura / gravação a qualquer momento, é possível usar o mesmo VG para host e convidados. Se vários sistemas tentarem gravar no mesmo LV, ocorrerá a corrupção do sistema de arquivos.

Você pode dar uma olhada nisso, talvez mexer e ver como esse projeto faz o que você está falando.

O ProxmoxVE é um host KVM bare-metal que usa uma implementação perl da libvirt em vez da versão mais pesada do RHEL. Implementa os dois cenários.

Os discos virtuais são .raw e esparsos, semelhantes ao .qcow, mas mais rápidos.

Os formatos de imagem de disco qcow e vmdk também são suportados, mas acho que pode haver limitações de LVM envolvidas. Eu não os uso, então não posso falar muito sobre isso.

O armazenamento LVM é compartilhado entre VMs no nó e pode ser dispositivos DRBD.

Quanto ao compartilhamento do espaço VG do sistema operacional, a única limitação a se preocupar é o tamanho da captura instantânea durante os backups. Aqui, esse valor pode ser alterado em um arquivo de configuração, e às vezes vejo nos fóruns em que as pessoas tiveram que alterá-lo, mas os padrões me servem bem há alguns anos - mesmo com enormes discos virtuais.

Detalhes de armazenamento LVM da PVE:

http://pve.proxmox.com/wiki/Storage_Model#LVM_Groups_with_Network_Backing

É assim que os VGs são organizados:

Grupo de volumes encontrado "LDatastore1" usando o tipo de metadados lvm2

Grupo de volumes encontrado "LDatastore0" usando o tipo de metadados lvm2

Grupo de volumes encontrado "pve" usando o tipo de metadados lvm2

Estes são meus LVs:

ATIVO '/ dev / LDatastore1 / vm-9098-disk-1' [4.00 GB] herdar

ATIVO '/ dev / LDatastore1 / vm-7060-disk-1' [2.00 GB] herdar

ATIVO '/ dev / LDatastore1 / vm-5555-disk-1' [8.00 GB] herdar

ATIVO '/ dev / LDatastore0 / vm-4017-disk-1' [8.00 GB] herdar

ATIVO '/ dev / LDatastore0 / vm-4017-disk-2' [512.00 GB] herdar

ATIVO '/ dev / LDatastore0 / vm-7057-disk-1' [32.00 GB] herdar

ATIVO '/ dev / LDatastore0 / vm-7055-disk-1' [32.00 GB] herdar

ATIVO '/ dev / LDatastore0 / vm-6030-disk-1' [80.01 GB] herdar

ATIVO '/ dev / pve / swap' [3,62 GB] herdar

ATIVO '/ dev / pve / root' [7.25 GB] herda

ATIVO '/ dev / pve / data' [14.80 GB] herda

Este é o LVM no RAID10, composto por 6 unidades Seagate Barracuda SATA de 7200 rpm:

CPU BOGOMIPS: 53199.93

REGEX / SECOND: 824835

TAMANHO HD: 19,69 GB (/ dev / mapper / LDatastore0-testlv)

LEITURAS BUFFERED: 315.17 MB / s

TEMPO MÉDIO DE BUSCA: 7.18 ms

FSYNCS / SECOND: 2439.31

E esse é o LVM em um único SSD Intel X25-E SATA, o mesmo VG dos dados / dev / pve / mencionados acima onde as VMs vivem:

CPU BOGOMIPS: 53203.97

REGEX / SECOND: 825323

TAMANHO HD: 7,14 GB (/ dev / mapper / pve-root)

LEITURAS BUFFERED: 198.52 MB / seg

TEMPO MÉDIO DE BUSCA: 0,26 ms

FSYNCS / SECOND: 1867.56