Parece que consigo fazer um pvcreate em cima de um dispositivo de bloco simples, sem ter que criar uma tabela de partição. Eu sou então capaz de criar um grupo de volume, volume lógico e finalmente um sistema de arquivos, montá-lo e testar via dd.
Parece funcionar, mas eu preciso de uma verificação de sanidade. Isto é uma má ideia?
Como faço para criar uma tabela de partições GPT ou MBR sobre um dispositivo de bloco não processado?
Como uso o parted para mostrar que tipo de tabela de partições 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 gravar nela. Essa é a saída esperada ao fazer o LVM sobre um dispositivo de bloco bruto sem uma tabela de partição? Alguma idéia?
Obrigado!
Mesmo se o próprio LVM não se importar em ter uma partição real, uma razão para criá-la é informar aos programas de particionamento que há "algo lá". Um cenário de pesadelo é um novo sysadmin diagnosticando um problema de inicialização em um servidor, ativando um programa de particionamento, vendo discos não particionados e concluindo que a unidade está corrompida.
Não vejo desvantagem em criar uma partição LVM. Você?
Enquanto você pode simplesmente criar um dispositivo de bloco raw de pv eu normalmente tento evitá-lo, pois isso pode causar confusão quanto ao que o dispositivo de bloco está sendo usado. Também pode quebrar algumas das rotinas de descoberta automática que o LVM pode usar se estiver faltando seus arquivos de configuração.
Aqui está um exemplo do uso do parted para criar uma GPT com 1 partição que é a unidade inteira e definir o sinalizador de partição como lvm. O mkpart requer que você especifique um sistema de arquivos, mas ele não cria o sistema de arquivos. Parece ser um bug de longa data em parted. Além disso, o deslocamento inicial de 1M é para 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 estã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 não pode encontrar um dispositivo.
Por exemplo, recordei 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 dois grupos de volume com o mesmo nome, ambos de convidados, que realmente não devem aparecer no hipervisor.
Por esse motivo, aconselho que você use parted ou fdisk para criar uma partição KVM 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 um PV dentro de uma tabela de partições. Isso não é um problema se você usar o dispositivo de bloco inteiro para o PV.
Mesmo se no passado eu estivesse usando o disklabel do MS-DOS ou o disklabel do GPT para PV, prefiro usar agora o LVM diretamente no dispositivo de bloco principal. Não há razão para usar 2 disklabels, 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 o LVM diretamente é:
De acordo com o guia LVM da RedHat, seção 4.2.1 link
Eles disseram que não há necessidade de ter a tabela de partições, eles até sugerem que nós a destruamos se usarmos o disco inteiro para o VG (Volume Group), a menos que pretendamos incluir apenas partes dele (partição).