O LVM precisa de uma tabela de partição?

Parece que sou capaz de executar com êxito um pvcreate em cima de um dispositivo de bloco bruto, sem nunca precisar criar uma tabela de partição. Sou capaz de criar um grupo de volumes, volume lógico e, finalmente, um sistema de arquivos, montá-lo e testar via dd.

Parece funcionar, mas preciso de uma verificação de sanidade. Isso é uma má ideia?

Como crio uma tabela de partição GPT ou MBR em cima de um dispositivo de bloco bruto?

Como uso o parted para mostrar que tipo de tabela de partição está em uso? Eu tentei fazer:

parted, selecione / dev / sdb, imprima e recebo:

Erro: / dev / sdb: rótulo de disco não reconhecido

No entanto, a unidade está atualmente em uso e eu posso ler e escrever nela. Essa é a saída esperada ao executar o LVM em cima de um dispositivo de bloco bruto sem uma tabela de partição? Alguma ideia?

Obrigado!

Mesmo que o próprio LVM não se importe em ter uma partição real, uma razão para criá-la de qualquer maneira é informar aos programas de particionamento que há "algo lá". Um cenário de pesadelo é um novo administrador de sistemas diagnosticando um problema de inicialização em um servidor, iniciando um programa de particionamento, vendo discos não particionados e concluindo que a unidade está corrompida.

Não vejo nenhuma desvantagem em criar uma partição LVM. Você?

Embora você possa apenas criar um PV a partir do dispositivo de bloco bruto, normalmente tento evitá-lo, pois isso pode causar confusão quanto ao uso do dispositivo de bloco. Também pode quebrar algumas das rotinas de descoberta automática que o LVM pode usar se estiver faltando os arquivos de configuração.

Aqui está um exemplo do uso de parted para criar uma GPT com 1 partição que é a unidade inteira e defina o sinalizador de partição como lvm. O mkpart requer que você especifique um sistema de arquivos, mas não cria o sistema de arquivos. Parece ser um bug de longa data em parted. Além disso, o deslocamento inicial de 1M é garantir que você obtenha o alinhamento adequado.

parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on

Se você criar um PV diretamente em um dispositivo de armazenamento virtual dentro de um convidado KVM, notará que os volumes lógicos do convidado estarão visíveis no hypervisor. Isso pode tornar as coisas bastante confusas se você usar o mesmo volume lógico e nomes de grupos de volumes em vários convidados. Você também pode receber alguns avisos no hypervisor dizendo que ele não consegue encontrar um dispositivo.

Por exemplo, recriei esse problema no meu hipervisor de teste:

[root@testhost ~]# vgs
  Couldn't find device with uuid dCaylp-1kvL-syiF-A2bW-NTPP-Ehlb-gtfxZz.
  VG          #PV #LV #SN Attr   VSize   VFree  
  vg_main       2   2   0 wz-pn-  19.25g 768.00m
  vg_main       2   2   0 wz-pn-  19.25g 768.00m
  vg_testhost   1   8   0 wz--n- 237.98g 120.15g

Aqui você pode ver 2 grupos de volumes com o mesmo nome, ambos de convidados que realmente não deveriam aparecer no hypervisor.

Por esse motivo, aconselho que você use parted ou fdisk para criar uma partição KVM nela primeiro (como mostrado na resposta anterior por 3dinfluence), antes de criar um PV e adicioná-lo a um grupo de volumes. Dessa forma, os volumes lógicos convidados permanecem ocultos do hypervisor.

Uma desvantagem é que não é possível adicionar espaço a quente a um PV dentro de uma tabela de partição. Isso não é um problema se você usar o dispositivo de bloco inteiro para o PV.

De acordo com o guia LVM do RedHat, seção 4.2.1 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/physvol_admin

Eles disseram que não há necessidade de ter a tabela de partição, eles até sugerem que a destruamos se usarmos todo o disco para o VG (Volume Group), a menos que apenas pretendamos incluir apenas partes dela (partição).

Mesmo que no passado eu estivesse usando o rótulo de disco do MS-DOS ou o rótulo de disco GPT para PV, agora prefiro usar diretamente o LVM no dispositivo de bloco principal. Não há razão para usar 2 rótulos de disco, a menos que você tenha um caso de uso muito específico (como disco com setor de inicialização e partição de inicialização).

A vantagem de ter LVM diretamente é:

• simplicidade - você não precisa usar 2 conjuntos de ferramentas
• flexibilidade - você pode usar o pvmove para mover os dados de um volume de disco para outro sem tempo de inatividade, pode usar snapshot e thin provisioning
• você não precisa executar o partprobe ou o kpartx para informar ao kernel que você criou / redimensionou / excluiu um volume. E o partprobe / kpartx pode falhar se as partições estiverem em uso e você precisar reiniciar
• talvez um desempenho melhor, comparado ao uso do LVM em cima das tabelas de disco do MS-DOS ou GPT