XenServer e XCP-ng usam uma arquitetura baseada em SR, VDI, PBD e VBD. O storage pode ser LVM, NFS, EXT/XFS, iSCSI, Fibre Channel, GFS2 ou outro tipo suportado. A recuperação segura identifica primeiro o SR real e o formato dos VDIs, com atendimento remoto para todo o Brasil em casos lógicos compatíveis.
O que é XenServer?
XCP-ng compartilha grande parte dessa arquitetura, mas possui evolução própria. Em 2026, por exemplo, XCP-ng 8.3 adicionou suporte a QCOW2 em vários SRs, além do VHD tradicional.
Guia completo de recuperação de dados em XenServer e XCP-ng
SR, VDI e storage físico formam uma cadeia de dependências
O inventário da VM, os objetos XAPI e o storage físico não são a mesma coisa. Um SR pode estar intacto na mídia e apenas desconectado do pool; o pool database pode estar perdido enquanto os VDIs continuam presentes; ou o RAID físico pode ter falhado e tornar qualquer metadata superior inacessível.
A mesma VM pode depender de objetos XAPI, metadata do SR, VDI chain e storage físico.
SR unavailable, VDI missing, host offline e snapshot chain quebrada
SR unavailable
Path, PBD, LUN, SR metadata ou mídia física podem estar envolvidos.
VDI missing
Associação XAPI, VDI metadata, file/LV ou chain pode estar inconsistente.
Host não inicia
Dom0 pode falhar enquanto o SR e os VDIs permanecem íntegros.
LVM inconsistente
VG/LV ou storage underlying pode exigir análise específica.
Snapshot chain
VHD/QCOW2 parents e children podem estar incompletos.
iSCSI / FC offline
Path loss pode parecer SR corrompido sem destruir os dados.
A arquitetura XenServer não é apenas LVM
SR
Storage Repository: alvo persistente que contém VDIs.
VDI
Virtual Disk Image: abstração de disco virtual.
PBD
Physical Block Device object: conecta um host ao SR e armazena device configuration.
VBD
Virtual Block Device: conecta VDI à VM e define attachment/I/O properties.
Essa distinção corrige a simplificação do benchmark de que todo SR seria LVM e cada VDI seria necessariamente um LV. A representação física depende do SR type e do SM API.
Local LVM, EXT/XFS, NFS, SMB, iSCSI, Fibre Channel e GFS2
| SR type | Camada física | VDI/metadata | Recovery |
|---|---|---|---|
| Local LVM | HDD/SSD local | LVM + VDI format | VG/LV + VDI chain |
| Local EXT/XFS | filesystem local | file-based VDIs | host FS + VDI |
| NFS | NFS share | VHD files no XenServer 8.4 | NFS + file chain |
| iSCSI LVM | LUN remota | LVM SR | path/LUN + LVM + VDI |
| HBA / FC | Fibre Channel LUN | LVM ou GFS2 conforme config | zoning/path + SR |
| GFS2 | shared block | clustered filesystem / QCOW2 compatível | cluster FS + VDI |
Snapshots e clones formam árvores de VDIs encadeados
XenServer atual documenta VDIs VHD e QCOW2 baseados em copy-on-write. Clones e snapshots podem compartilhar data e formar trees; quando um node deixa de ser necessário, o coalescing racionaliza a chain.
XenServer documenta árvores de VDIs encadeados e coalescing assíncrono quando nós deixam de ser necessários.
Coalesce não é "sempre destrutivo": é mecanismo normal. Mas em um incidente com child ausente, storage instável ou snapshot incompleto, preserve o conjunto antes de estimular mudanças na chain.
pvscan, vgscan e repair não são a mesma coisa
O benchmark afirma que executar pvscan ou vgscan sobrescreve o mapeamento LVM. Isso não corresponde à documentação LVM atual. pvscan sem --cache lista PVs, e vgscan procura VGs.
pvscan
Sem --cache, lista PVs. Com --cache, atualiza estado runtime do LVM; com autoactivation pode ativar VGs/LVs.
vgscan
Procura VGs em devices suportados. Não é sinônimo de rewrite de VG metadata.
Repair
Comandos de repair/conversion são operações diferentes e podem gravar metadata.
Recovery
Mesmo scans sendo diagnósticos, trabalhe preferencialmente em clones quando há mídia instável ou metadata única.
Essas operações têm efeitos muito diferentes
| Operação | Efeito oficial | Dados físicos | Uso em recovery |
|---|---|---|---|
| Detach | desconecta PBD/SR | preservados | pode ser reversível |
| Forget | remove SR/PBD do database | conteúdo preservado | perde associations, exige cautela |
| Destroy | remove SR e conteúdo | apagados | não usar em dados únicos |
| sr-introduce | cria registro de SR | não reconstrói conteúdo | avançado, útil em certos failures |
| Reattach / Repair SR | reativa SR existente | preserva quando corretamente usado | adequado em problemas de associação/path |
XenCenter também diferencia Reattach de Format quando encontra SR existente numa LUN. Para recuperar dados, escolher Format em vez de Reattach pode ser catastrófico.
Metadata da VM e dados do VDI são camadas diferentes
XenServer mantém um database em cada host com metadata de VMs e recursos como storage e networking. Em conjunto com os SRs, esse banco forma a visão completa do pool.
pool-dump-database
Gera backup consistente da pool metadata.
pool-restore-database
Restaura metadata a partir de dump anterior, com dry-run disponível em docs atuais.
Host perdido
Fresh install e restore de database podem reconstruir a camada de gerenciamento se o storage permanece disponível.
DR metadata
XenServer DR pode salvar metadata em SRs específicos, com suporte limitado a LVM over HBA/iSCSI.
XCP-ng 8.3: VHD continua central, mas QCOW2 chegou ao SMAPIv1 em 2026
XCP-ng documenta VHD como formato padrão histórico com limite aproximado de 2 TiB. Desde 5 de maio de 2026, XCP-ng 8.3 também suporta QCOW2 no SMAPIv1 em vários SR types, com discos muito maiores em configurações compatíveis.
VHD
Snapshot, delta backup, fast clone e live storage migration.
QCOW2
Novo suporte 8.3 em 2026 para vários SRs, com maior virtual disk size.
Migration
Mover um VDI pode colapsar a snapshot chain no destino e deixar coalesce no source.
Versão importa
Não aplique regras antigas de VHD-only a ambientes XCP-ng 8.3 atuais.
iSCSI, Fibre Channel, NFS e multipath podem derrubar o SR sem destruir os VDIs
iSCSI
Target, IQN, LUN e multipath participam do caminho do SR.
Fibre Channel
Zoning/HBA pode retirar a LUN. XenServer recomenda Repair SR em certos casos de zoning.
NFS
File-based SR; XenServer 8.4 documenta VDIs em VHD.
Shared SR
Todos os hosts do pool precisam enxergar de forma consistente o storage compartilhado.
RAID é camada inferior, não a intenção principal desta página
RAID 1 / 10
Mirror
RAID 5
Paridade P
RAID 6
P + Q
SAN / NAS
Storage abaixo do SR
Se o SR está sobre um array físico degradado, o RAID precisa fornecer blocos coerentes antes da reconstrução de LVM, VHD/QCOW2 ou XAPI objects. Caio Bruno F. Garcia é associado a RAID Low Level e WinHex em casos de extrema complexidade.
Como funciona a recuperação remota de XenServer e XCP-ng
12 passos quando XenServer perde um SR ou várias VMs
O que realmente pode agravar uma recuperação XenServer
sr-create / Format
Pode apagar estruturas existentes no storage target.
Destroy
Apaga o conteúdo do SR da mídia física.
Forget sem inventário
Preserva dados, mas perde associations de VM para VDI no database.
Repair LVM no único original
Operações de repair podem gravar metadata e devem ser feitas com preservação.
Coalesce em chain incompleta
Pode modificar parents/children quando a árvore já está inconsistente.
Rebuild RAID cego
Outro membro instável pode derrubar o SR inteiro.
Como a SECURITY conduz a recuperação de XenServer e XCP-ng
Se existe falha física, entram PC-3000, Data Extractor, DeepSpar e, quando necessário, procedimentos em sala limpa ISO-5.
Caio Bruno F. Garcia, WinHex e RAID Low Level em XenServer de extrema complexidade
WinHex pode auxiliar inspeção hexadecimal de LUNs, LVM metadata, VHD/QCOW2, partition tables e RAID físico quando o caso exige análise abaixo do XenCenter/xe CLI.
LVM/SR
Inspecionar PV/VG/LV regions em cópias.
VHD / QCOW2
Comparar structures e block signatures.
VDI chain
Correlacionar parents e children.
RAID físico
Validar ordem, stripe, paridade e offsets.
Principais tecnologias encontradas em projetos XenServer e XCP-ng
Vídeos da SECURITY sobre RAID, VMs e banco de dados
O vídeo complementa este artigo quando XenServer/XCP-ng depende de RAID ou storage corporativo.
Cenários técnicos de recuperação de XenServer e XCP-ng
SR LVM local unavailable após falha de RAID
Clonar membros, reconstruir RAID, preservar VG/LVs e depois mapear VDIs.
SR iSCSI desaparece após mudança de zoning/path
Separar connectivity de corrupção, validar LUN e usar Reattach/Repair em vez de Format quando apropriado.
SR foi Forget e as VMs perderam attachments
Conteúdo físico permanece; reintroduzir SR e reconstruir associations com inventário de UUIDs.
VHD snapshot chain incompleta
Preservar parents/children e evitar coalesce manual até entender a árvore.
XCP-ng 8.3 com QCOW2 e migração interrompida
Identificar SR type, QCOW2 chain e estado do source/destination antes de novo migration.
FAQ sobre recuperação de dados em XenServer e XCP-ng
O que é XenServer?
XenServer é um hipervisor corporativo baseado em Xen e gerenciado pelo stack XAPI. As VMs utilizam Virtual Disk Images, os VDIs, armazenados em Storage Repositories, os SRs. Esses SRs podem ser locais ou compartilhados e usar LVM, EXT, XFS, NFS, SMB, iSCSI, Fibre Channel e outros tipos suportados.
O que é XCP-ng?
XCP-ng é uma plataforma open source da mesma família tecnológica de virtualização Xen/XAPI. Ela compartilha muitos conceitos de SR, VDI, VBD, PBD e snapshots, mas possui versões, recursos e evolução própria. Em 2026, XCP-ng 8.3 passou a suportar QCOW2 em vários SRs, além do VHD tradicional.
O que é recuperação de dados em XenServer?
É o processo de preservar e reconstruir as camadas necessárias para acessar os dados quando um SR fica inacessível, VDIs somem, VHD/QCOW2 chains quebram, o pool database é perdido, a LUN desaparece ou o RAID físico falha.
O que é um Storage Repository SR?
SR é o alvo de armazenamento em que os VDIs ficam armazenados. A documentação XenServer define o SR como uma estrutura persistente de storage. Dependendo do tipo, ele pode estar sobre LVM, filesystem local, NFS, SMB, iSCSI, Fibre Channel ou GFS2.
O que é um VDI?
VDI é uma abstração de disco virtual usada pelo XenServer. A representação física do VDI muda conforme o tipo de SR. Em alguns SRs ele pode usar VHD, em outros QCOW2 ou estruturas específicas gerenciadas pelo SM API.
Todo SR XenServer usa LVM?
Não. Esse é um erro comum. XenServer suporta Local LVM, mas também Local EXT3/EXT4, Local XFS, NFS, SMB, iSCSI, HBA/Fibre Channel, GFS2 e outros SRs. A recuperação precisa identificar o tipo real antes de aplicar qualquer procedimento.
Todo VDI XenServer é um logical volume LVM?
Não. Em LVM-based SRs há relação com logical volumes, mas file-based SRs como NFS armazenam VDIs como arquivos. A documentação atual também contempla VHD e QCOW2 chains conforme o tipo de storage.
XenServer usa VHD ou VHDX?
Para storage nativo de VM, VHD é um formato central e XenServer atual também documenta VDIs baseados em QCOW2 em tipos compatíveis. XenCenter consegue importar VHD, VHDX/AVHDX e VMDK, mas isso não significa que todo SR nativo armazene VHDX.
XCP-ng usa somente VHD?
Não mais. XCP-ng 8.3 mantém VHD como formato padrão histórico, mas desde 5 de maio de 2026 suporta QCOW2 no SMAPIv1 em vários tipos de SR, permitindo discos maiores que o limite histórico de cerca de 2 TiB do VHD.
SR unavailable significa perda de dados?
Não automaticamente. O SR pode estar detachado, com PBD unplugged, com path iSCSI/FC indisponível, com metadata inconsistente ou com falha física. É necessário separar conectividade, associação no XAPI database e conteúdo do storage.
Detach de SR apaga os VDIs?
Não. A documentação XenServer informa que Detach rompe a associação com o pool/host e torna os VDIs inacessíveis, mas preserva o conteúdo e as informações usadas pelas VMs. O SR pode ser reatado.
Forget de SR apaga os dados?
Não apaga o conteúdo físico do SR, mas remove permanentemente do banco XenServer as informações que conectam VMs aos VDIs daquele SR. A operação Forget não pode ser desfeita pelo simples Undo, embora um SR existente possa ser reintroduzido com os procedimentos corretos.
Destroy de SR apaga os dados?
Sim. XenServer documenta Destroy como operação que remove o conteúdo do SR da mídia física. Em recuperação de dados, Destroy é uma operação que deve ser evitada sobre o único conjunto.
sr-create pode apagar um SR existente?
Sim. A documentação XenServer alerta que criar um SR sobre um storage target pode destruir dados existentes. Em LUN com SR existente, XenCenter diferencia Reattach de Format. Nunca use Create/Format como tentativa de recovery.
sr-introduce é uma ferramenta de recuperação?
É uma operação avançada que cria um registro de SR no banco e pode ser útil para reintroduzir SRs esquecidos ou em certos cenários de falha. Ela não reconstrói automaticamente VDI data corrompido e exige o UUID, tipo e configuração corretos.
pvscan e vgscan sobrescrevem o LVM automaticamente?
Não é correto afirmar isso. A documentação LVM define pvscan sem --cache como listagem de PVs e vgscan como busca de VGs. Algumas opções de pvscan podem atualizar estado runtime e autoativar volumes, mas scan simples não é equivalente a repair ou overwrite de metadata.
Snapshots XenServer formam chains?
Sim. XenServer documenta VHD e QCOW2 baseados em copy-on-write que podem formar trees de VDIs encadeados após snapshots e clones. Quando nós são removidos, o coalesce pode racionalizar a cadeia.
Coalesce XenServer é sempre destrutivo?
Não. Coalescing é parte normal do gerenciamento de VDI chains. Em recovery, porém, uma cadeia incompleta, storage instável ou snapshot node ausente deve ser preservado antes de acionar operações que reescrevem a chain.
VDI missing pode ser recuperado?
Pode existir viabilidade se o conteúdo ainda estiver no SR e a associação ou metadata puder ser reconstruída. A abordagem depende do tipo do SR, do formato do VDI e das alterações feitas depois da falha.
Host XenServer não inicializa significa que as VMs foram perdidas?
Não necessariamente. Se o SR e os VDIs estão íntegros, a falha pode estar apenas no host ou no Dom0. XenServer mantém VM disks em SRs persistentes e possui mecanismos de backup/restore do pool database.
O que é o pool database?
É o banco de metadata do XenServer que descreve VMs e recursos associados, incluindo storage e networking. O backup pode ser feito com pool-dump-database e restaurado com pool-restore-database.
Perder o pool database apaga os VDIs?
Não necessariamente. O banco descreve a visão lógica das VMs e recursos, enquanto os VDIs permanecem no storage. A recuperação pode envolver restaurar metadata ou reintroduzir SRs e reconstruir associações.
É possível recuperar SR iSCSI ou Fibre Channel?
Pode. Primeiro é preciso separar path, zoning, multipath e LUN presentation de corrupção real do SR. XenServer recomenda Repair Storage Repository em certos problemas de zoning, em vez de remover e recriar o SR.
Repair Storage Repository é seguro?
É uma função suportada para determinados problemas de conectividade/reattach. Isso não significa que deva ser usada cegamente quando há suspeita de corrupção física ou metadata alterada. Preserve o estado e identifique a causa primeiro.
NFS SR usa VHD?
Sim. A documentação XenServer 8.4 informa que VDIs em NFS SR são armazenados em formato Microsoft VHD.
Qual é o limite de VHD no XenServer/XCP-ng?
Em Local LVM XenServer 8.4, a documentação cita máximo de 2.040 GiB por VDI. XCP-ng também documenta limite de aproximadamente 2 TiB para VHD, enquanto QCOW2 no XCP-ng 8.3 permite discos muito maiores em vários SRs.
QCOW2 é suportado no XenServer/XCP-ng?
Sim em versões e SRs compatíveis. XenServer 8.4 documenta VDIs baseados em QCOW2 e XCP-ng 8.3 adicionou suporte QCOW2 ao SMAPIv1 em 2026. O suporte exato depende do SR e da versão.
RAID e XenServer são a mesma recuperação?
Não. RAID é uma camada inferior. Esta página mantém a intenção principal em recuperação de XenServer/XCP-ng. RAID Low Level entra apenas quando o SR depende de um array físico com falha.
É possível recuperar XenServer remotamente?
Sim, em muitos casos lógicos. Se hosts, LUNs e SRs estão acessíveis e estáveis, logs, UUIDs, VDIs e pool metadata podem ser avaliados remotamente. Falhas físicas em HDD/SSD/RAID podem exigir envio das mídias.
Preciso levar o servidor inteiro?
Na maioria dos casos lógicos, não. Logs, UUIDs, SR/VDI information, pool database backup e cópias dos VDIs podem ser suficientes. Em falha física, normalmente enviam-se as mídias afetadas e informações do RAID.
Quanto custa recuperar XenServer?
O custo depende do tipo de SR, quantidade de VDIs/VMs, VHD/QCOW2 chains, storage compartilhado, RAID, falhas físicas, corrupção de metadata e intervenções anteriores.
Quanto tempo leva?
Depende da camada da falha. Reintroduzir um SR intacto é muito diferente de reconstruir RAID, LVM e VDI chains com várias mídias instáveis.
A SECURITY atende XenServer e XCP-ng em todo o Brasil?
Sim. Casos lógicos compatíveis podem começar por recuperação remota para todo o Brasil. Quando há falha física, a SECURITY orienta o envio das mídias necessárias.
Sem necessidade de levar o equipamento em muitos casos
Remoto
Logs, UUIDs, pool metadata e VDIs podem ser avaliados por sessão segura.
Mídias físicas
Se HDD/SSD/RAID falha, enviam-se as mídias afetadas.
Servidor completo
Normalmente não é necessário em falha lógica de SR/VDI.
Todo o Brasil
Triagem lógica pode começar independentemente da localização.
Alphaville, São Paulo e Campinas quando o caso exige laboratório
Alameda Rio Negro, 1030, Conj. 206
Barueri, SP, CEP 06454-000
(11) 98570-8000
Rua Frei Caneca, 1380, Conj. 11
São Paulo, SP, CEP 01307-002
(11) 98570-8000
Rua José Paulino, 1399, Andar 10
Campinas, SP, CEP 13013-001
(19) 99971-7987
Caio Bruno F. Garcia
Especialista em Recuperação de Dados e liderança técnica e estratégica da SECURITY. Atua desde 2005 e, em ambientes XenServer/XCP-ng de alta complexidade, relaciona SR, VDI, VHD/QCOW2 e LVM às camadas de storage, RAID Low Level e análise hexadecimal com WinHex, além de PC-3000 e Data Extractor quando existe falha física.
XenServer e XCP-ng por dentro: SR, VDI, VHD/QCOW2 e LVM
1. XenServer
Hipervisor Xen/XAPI com SRs e VDIs.
2. XCP-ng
Plataforma open source da mesma família tecnológica com evolução própria.
3. XAPI database
Mantém metadata de VMs, storage, networking e pool.
4. Storage Repository
Estrutura persistente que armazena VDIs.
5. VDI
Abstração de virtual disk; sua representação depende do SR type.
6. PBD
Conecta host ao SR e armazena device-config.
7. VBD
Conecta VDI à VM.
8. SM API
Storage Management API plug-in por SR type.
9. Local LVM
SR local sobre volume group.
10. Local EXT/EXT4
File-based local SR.
11. Local XFS
File-based local SR.
12. NFS
Shared file SR; XenServer 8.4 documenta VDI em VHD.
13. SMB3
Shared file storage suportado em versões atuais.
14. iSCSI
Shared block storage com LUNs.
15. Fibre Channel / HBA
Block storage enterprise com zoning e multipath.
16. GFS2
Clustered filesystem para thin-provisioned shared block SR.
17. VHD
Formato histórico central com copy-on-write e chains.
18. QCOW2
Formato suportado em XenServer atual e XCP-ng 8.3 em SRs compatíveis.
19. XCP-ng 8.3 QCOW2
Suporte adicionado em 5 de maio de 2026.
20. VHD 2 TiB limit
Limite histórico de cerca de 2 TiB, 2040 GiB em diversos SRs.
21. VHD chain
Snapshots/clones compartilham data via copy-on-write.
22. QCOW2 chain
Também pode formar trees de VDIs.
23. Coalesce
Racionaliza chains quando nodes deixam de ser necessários.
24. Thin provisioning
VHD/QCOW2 podem alocar somente blocos usados em SRs compatíveis.
25. Detach
Preserva contents e permite reattach.
26. Forget
Preserva contents, remove associations no database.
27. Destroy
Apaga contents do SR.
28. sr-probe
Escaneia backend para identificar SR existente.
29. sr-introduce
Cria record no database para SR existente em cenários avançados.
30. sr-create
Cria SR e pode destruir dados existentes no target.
31. Reattach
Reassocia SR existente sem formatar quando suportado.
32. Repair SR
Útil em determinados problemas de path/zoning.
33. pvscan
Sem --cache lista PVs; opções podem atualizar runtime state/activation.
34. vgscan
Procura VGs em devices suportados.
35. LVM repair
É diferente de scan e pode escrever metadata.
36. Pool database
Metadata lógica das VMs e recursos.
37. pool-dump-database
Backup da pool metadata.
38. pool-restore-database
Restore da pool metadata.
39. XenServer DR
Usa pool metadata e storage replication; suportado para LVM over HBA/iSCSI.
40. Host failure
Dom0 pode falhar sem apagar os VDIs.
41. NFS path failure
Pode derrubar SR sem corrupção de VHD.
42. iSCSI path failure
Pode derrubar LUN sem apagar conteúdo.
43. Fibre Channel zoning
Pode ser resolvido por path/Repair SR em certos casos.
44. RAID
Camada abaixo do SR quando storage físico usa array.
45. RAID Low Level
Ordem, stripe, paridade e offsets quando o array falha.
46. PC-3000
Usado quando mídia suportada apresenta falha física/firmware.
47. Sala limpa ISO-5
Usada em HDD mecânico quando a falha exige procedimento físico.
48. WinHex
Auxilia análise hexadecimal em clones/LUNs/LVM/VHD e RAID.
49. Remote recovery
Casos lógicos estáveis podem ser analisados remotamente.
50. Second opinion
Documentar tentativas anteriores é essencial.
51. Matriz técnica de decisão
| Sintoma | Camada | Prioridade | Evitar |
|---|---|---|---|
| SR unavailable | PBD/path/SR | identificar SR type | sr-create/Format |
| VDI missing | database/VDI chain | UUIDs + storage scan | Destroy |
| LVM incomplete | VG/LV/storage | preservar metadata | repair no único original |
| NFS/iSCSI/FC offline | connectivity | validar paths | recriar SR |
| Forgotten SR | XAPI associations | probe/introduce/reattach | Format |
| Snapshot chain broken | VHD/QCOW2 chain | mapear parents | coalesce cego |
| RAID degraded | camada física | diagnosticar/clonar | rebuild repetido |
52. Conclusão técnica
Recuperação XenServer/XCP-ng exige separar pool database, SR, VDI chain e storage físico. Nem todo SR é LVM, nem todo scan é destrutivo. O melhor resultado vem de preservar o conteúdo existente, identificar o SR type e trabalhar em cópias quando há corrupção ou mídia instável. Em muitos casos lógicos, a análise pode começar remotamente em qualquer região do Brasil.
Referências utilizadas para validar este guia
- XenServer 8.4: Storage, SR, VDI, PBD, VBD, VHD e QCOW2 chains
- XenServer: Detach, Forget, Destroy e sr-introduce
- XenServer: Create SR, Reattach e riscos de criação sobre storage existente
- XenServer: Local LVM, EXT, XFS e limite 2040 GiB
- XenServer: NFS SR e VHD
- XenServer DR: pool metadata e VM recovery
- XenServer: pool-dump-database e pool-restore-database
- XCP-ng: VHD, QCOW2 8.3, SMAPIv1 e storage formats
- XCP-ng: VDI migration, export/import e chain collapse
- LVM: pvscan semantics
- LVM: vgscan semantics
- X-Ways: WinHex
