Grupo de volume LVM compartilhado entre o host KVM / libvirt e convidados: esta é uma má idéia?

Question

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

Eu decidi criar discos de máquinas virtuais como volumes lógicos em um grupo de volumes LVM gerenciado como um conjunto 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: Use o grupo de volumes do host da VM

Implementação:

• pequeno RAID1 md0 contendo o /boot filesystem
• grande RAID10 md1 ocupando o espaço restante, que contém um grupo de volumes LVM vghost . vghost contém o sistema de arquivos raiz do host da VM e a partição de troca
• crie discos de máquinas virtuais como volumes lógicos em vghost , conforme necessário

Prós:

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

Contras:

Depsite o fato de que este método parece funcionar, eu não posso abalar a sensação de que isso é de alguma forma uma má idéia. Eu sinto que:

• isso pode de alguma forma ser um risco de segurança
• em algum momento no futuro, eu posso encontrar alguma limitação com a configuração, e desejo que eu usei um grupo dedicado
• o sistema (CentOS, libvirt, etc.) pode não ser realmente projetado para ser usado assim e, portanto, em algum momento eu poderia acidentalmente corromper / perder os arquivos do host da VM e / ou sistema de arquivos

Método 2: usar um grupo de volumes dedicado

Implementação:

• mesmo md0 e md1 como no Método 1, exceto fazer md1 apenas grande o suficiente para conter para o host da VM (por exemplo, 5 a 10 GB)
• grande RAID10 md2 ocupando o espaço restante. md2 contém um grupo de volumes LVM vgvms , cujos volumes lógicos devem ser usados exclusivamente por máquinas virtuais

Prós:

• Eu posso mexer com vgvms sem medo de quebrar o sistema operacional host
• isso parece 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 de seu sistema de arquivos (por exemplo, / usr ou / var) para vgvms , o que não parece muito bom.
• Eu tenho que reinstalar o sistema operacional host (que, como dito anteriormente, não me importo de fazer)

UPDATE # 1:

Um dos motivos pelos quais 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 precise migrar alguns / todos os serviços de máquinas virtuais para o sistema operacional host.

Especificação de hardware do host da VM:

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

ATUALIZAÇÃO # 2:

Um motivo pelo qual eu sinto que o sistema não pode ser projetado para usar o host VG como um pool de armazenamento libvirt no Método 1 é algum comportamento que notei no virt-manager:

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

Answer 1

Pergunta bem pensada!

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

O Método 1 Contras também não é um problema, IMO. Eu não acho que haveria qualquer risco de segurança extra, pois se uma VM enraizada é de alguma forma capaz de sair de sua partição e infectar / danificar outras partições, ter o sistema operacional 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 diretamente, mas meu instinto diz que o CentOS, o LVM e o 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 desempenho da virtualização é muito baixo, especialmente usando processadores com suporte embutido para ele, então não acho que valeria a pena mudar um serviço de uma VM guest para o sistema operacional host. Você pode obter um aumento de velocidade de 10% ao executar o "bare metal", mas perderia os benefícios de ter um sistema operacional host pequeno, restrito e seguro, além de potencialmente afetar a estabilidade de todo o servidor . Não vale a pena, IMO.

Em vista disso, eu ainda preferiria o Método 2.

Resposta à atualização 2

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

    

Answer 2

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

    

Answer 3

Você pode querer dar uma olhada nisso, talvez tinker & veja 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 contrapartida mais pesada do RHEL. Ele implementa os dois cenários.

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

O qcow & Os formatos de imagem de disco 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 do 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 do instantâneo durante os backups. Aqui este valor pode ser alterado em um arquivo de configuração, e eu vejo algumas vezes nos fóruns onde as pessoas tiveram que mudá-lo, mas os padrões me serviram bem por alguns anos agora - mesmo com enormes discos virtuais.

Detalhes do armazenamento LVM do PVE:

link

É assim que os VGs são dispostos:

Encontrado grupo de volume "LDatastore1" usando o tipo de metadados lvm2

Encontrado grupo de volume "LDatastore0" usando o tipo de metadados lvm2

Encontrado o grupo de volumes "pve" usando o tipo de metadados lvm2

Estes são meus LVs:

ACTIVE '/ dev / LDatastore1 / vm-9098-disk-1' [4,00 GB] herdam

ACTIVE '/ dev / LDatastore1 / vm-7060-disk-1' [2,00 GB] herdam

ACTIVE '/ dev / LDatastore1 / vm-5555-disk-1' [8.00 GB] herdam

ACTIVE '/ dev / LDatastore0 / vm-4017-disk-1' [8.00 GB] herdam

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

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

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

ACTIVE '/ dev / LDatastore0 / vm-6030-disk-1' [80,01 GB] herdam

ACTIVE '/ dev / pve / swap' [3,62 GB] herdam

ACTIVE '/ dev / pve / root' [7,25 GB] herdam

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

Este é o LVM no RAID10 feito de 6 unidades Seagate Barracuda SATA de 7200 rpm:

CPU BOGOMIPS: 53199,93

REGEX / SECOND: 824835

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

BUFFERED READS: 315,17 MB / s

TEMPO MÉDIO DE BUSCA: 7,18 ms

FSYNCS / SECOND: 2439.31

E este é o LVM em um único SSD Intel X25-E SATA, mesmo VG que os / dev / pve / data acima mencionados, em que as VMs vivem:

CPU BOGOMIPS: 53203.97

REGEX / SECOND: 825323

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

BUFFERED READS: 198,52 MB / s

TEMPO MÉDIO DE BUSCA: 0,26 ms

FSYNCS / SECOND: 1867,56