Qual é a diferença entre essas duas declarações de blockdev?

De acordo com o QEMU changelog , a descontinuação do filedriver ao acessar os dispositivos de bloco do host e a introdução do host_devicedriver ocorreram com o QEMU versão 3.0.

A apresentação em PDF da resposta de Stephen Kitt a que você se referiu (consulte as páginas 20...24) indica que a maneira mais exaustiva de definir o armazenamento para QEMU significaria primeiro configurar o local dos dados ( fileou host_device) com um node_name=, então usar outra --blockdevopção com um file=<previously_defined_node_name>para adicionar outra camada em cima da primeira para especificar o formato de dados (por exemplo, rawou qcow2por exemplo). Isso dá excelente controle ao usuário, mas é um exagero para a maioria dos casos básicos.

No repositório de código-fonte do QEMU, o qemu-options.hxarquivo parece ter a melhor descrição das -blockdevopções que vi até agora.

Há um parágrafo que pode fornecer algum esclarecimento sobre o file.<something>=<something>mistério:

As opções que esperam uma referência a outro nó (por exemplo file, ) podem ser dadas de duas maneiras. Você especifica o nome do nó de um nó já existente ( file=node-name) ou define um novo nó embutido, incluindo opções para o nó referenciado após um ponto ( file.filename=path,file.aio=native).

Portanto, a file.<something>=sintaxe é essencialmente uma forma abreviada de especificar outra -blockdevdeclaração, evitando, ao mesmo tempo, sobrecarregar o node_namenamespace com nomes de "nós intermediários".

Então, a declaração de Stephen Kitt blockdev:

-blockdev node-name=q1,driver=raw,file.driver=host_device,file.filename=/dev/loop0

parece ser equivalente a uma forma expandida:

-blockdev node_name=<hidden_node>,driver=host_device,filename=/dev/loop0 \
-blockdev node_name=q1,driver=raw,file=<hidden_node>

A diferença entre isso e sua declaração

-blockdev driver=host_device,node-name=q1,filename=/dev/loop0 

é um assunto mais complicado e precisa de um pouco de mergulho no código-fonte do QEMU para esclarecer.

-blockdevDrivers do QEMU filee têm várias versões para diferentes arquiteturas de host host_device. host_cdromPara Linux, o aplicável está localizado em block/file-posix.c. Pesquise instâncias de string BlockDriver bdrv_e você encontrará cada uma delas. (Você também descobrirá que existe uma definição totalmente separada host_cdrompara FreeBSD por algum motivo.)

Cada um BlockDriverparece ser definido por uma estrutura de (principalmente) ponteiros de função. Esses ponteiros podem apontar para uma função específica do driver ou referir-se a uma implementação comum compartilhada com outro driver.

O filedriver é definido assim:

BlockDriver bdrv_file = {
    .format_name = "file",
    .protocol_name = "file",
    .instance_size = sizeof(BDRVRawState),
    .bdrv_needs_filename = true,
    .bdrv_probe = NULL, /* no probe for protocols */
    .bdrv_parse_filename = raw_parse_filename,
    .bdrv_file_open = raw_open,
    .bdrv_reopen_prepare = raw_reopen_prepare,
    .bdrv_reopen_commit = raw_reopen_commit,
    .bdrv_reopen_abort = raw_reopen_abort,
    .bdrv_close = raw_close,
    .bdrv_co_create = raw_co_create,
    .bdrv_co_create_opts = raw_co_create_opts,
    .bdrv_has_zero_init = bdrv_has_zero_init_1,
    .bdrv_co_block_status = raw_co_block_status,
    .bdrv_co_invalidate_cache = raw_co_invalidate_cache,
    .bdrv_co_pwrite_zeroes = raw_co_pwrite_zeroes,
    .bdrv_co_delete_file = raw_co_delete_file,

    .bdrv_co_preadv         = raw_co_preadv,
    .bdrv_co_pwritev        = raw_co_pwritev,
    .bdrv_co_flush_to_disk  = raw_co_flush_to_disk,
    .bdrv_co_pdiscard       = raw_co_pdiscard,
    .bdrv_co_copy_range_from = raw_co_copy_range_from,
    .bdrv_co_copy_range_to  = raw_co_copy_range_to,
    .bdrv_refresh_limits = raw_refresh_limits,
    .bdrv_attach_aio_context = raw_aio_attach_aio_context,

    .bdrv_co_truncate                   = raw_co_truncate,
    .bdrv_co_getlength                  = raw_co_getlength,
    .bdrv_co_get_info                   = raw_co_get_info,
    .bdrv_get_specific_info             = raw_get_specific_info,
    .bdrv_co_get_allocated_file_size    = raw_co_get_allocated_file_size,
    .bdrv_get_specific_stats = raw_get_specific_stats,
    .bdrv_check_perm = raw_check_perm,
    .bdrv_set_perm   = raw_set_perm,
    .bdrv_abort_perm_update = raw_abort_perm_update,
    .create_opts = &raw_create_opts,
    .mutable_opts = mutable_opts,
};

Portanto, é essencialmente um clone do rawdriver, referindo-se a ele em quase todas as funções.

A host_devicedefinição é um pouco mais complexa:

static BlockDriver bdrv_host_device = {
    .format_name        = "host_device",
    .protocol_name        = "host_device",
    .instance_size      = sizeof(BDRVRawState),
    .bdrv_needs_filename = true,
    .bdrv_probe_device  = hdev_probe_device,
    .bdrv_parse_filename = hdev_parse_filename,
    .bdrv_file_open     = hdev_open,
    .bdrv_close         = raw_close,
    .bdrv_reopen_prepare = raw_reopen_prepare,
    .bdrv_reopen_commit  = raw_reopen_commit,
    .bdrv_reopen_abort   = raw_reopen_abort,
    .bdrv_co_create_opts = bdrv_co_create_opts_simple,
    .create_opts         = &bdrv_create_opts_simple,
    .mutable_opts        = mutable_opts,
    .bdrv_co_invalidate_cache = raw_co_invalidate_cache,
    .bdrv_co_pwrite_zeroes = hdev_co_pwrite_zeroes,

    .bdrv_co_preadv         = raw_co_preadv,
    .bdrv_co_pwritev        = raw_co_pwritev,
    .bdrv_co_flush_to_disk  = raw_co_flush_to_disk,
    .bdrv_co_pdiscard       = hdev_co_pdiscard,
    .bdrv_co_copy_range_from = raw_co_copy_range_from,
    .bdrv_co_copy_range_to  = raw_co_copy_range_to,
    .bdrv_refresh_limits = raw_refresh_limits,
    .bdrv_attach_aio_context = raw_aio_attach_aio_context,

    .bdrv_co_truncate                   = raw_co_truncate,
    .bdrv_co_getlength                  = raw_co_getlength,
    .bdrv_co_get_info                   = raw_co_get_info,
    .bdrv_get_specific_info             = raw_get_specific_info,
    .bdrv_co_get_allocated_file_size    = raw_co_get_allocated_file_size,
    .bdrv_get_specific_stats = hdev_get_specific_stats,
    .bdrv_check_perm = raw_check_perm,
    .bdrv_set_perm   = raw_set_perm,
    .bdrv_abort_perm_update = raw_abort_perm_update,
    .bdrv_probe_blocksizes = hdev_probe_blocksizes,
    .bdrv_probe_geometry = hdev_probe_geometry,

    /* generic scsi device */
#ifdef __linux__
    .bdrv_co_ioctl          = hdev_co_ioctl,
#endif

    /* zoned device */
#if defined(CONFIG_BLKZONED)
    /* zone management operations */
    .bdrv_co_zone_report = raw_co_zone_report,
    .bdrv_co_zone_mgmt = raw_co_zone_mgmt,
    .bdrv_co_zone_append = raw_co_zone_append,
#endif
};

Ele também se refere ao rawdriver para grande parte de sua funcionalidade, mas tem suas próprias funções dedicadas para coisas como:

• sondagem de dispositivos
• analisando o nome do arquivo (presumivelmente para verificar se há um dispositivo host válido)
• abrindo o dispositivo (se você se aprofundar um pouco mais, descobrirá que acessar dispositivos de bloco como um usuário no MacOS requer um pouco de código extra, então isso provavelmente é necessário para coisas específicas do sistema operacional como essa)
• escrevendo rapidamente grandes blocos de zeros
• descartando dados
• verificando e definindo permissões do dispositivo
• obter estatísticas do dispositivo
• detectando o tamanho do bloco do dispositivo e a geometria da unidade
• passando por comandos SCSI genéricos

Algumas dessas host_devicefunções específicas apenas executam uma verificação de erro extra e, em seguida, chamam a função equivalente do rawdriver. Mas são provavelmente os últimos que fornecem a maior parte do valor do host_devicedriver: permite que a VM veja explicitamente o tamanho real do bloco e a geometria (se aplicável) do dispositivo host. Passar por comandos SCSI genéricos permite que a VM tenha acesso a coisas como robôs de biblioteca de fitas, unidades de fita de alta capacidade e gravadores de DVD... e muitas outras coisas.

Sua declaração mais curta funciona porque a host_devicedeclaração recai inerentemente nas funções do rawdriver na maioria das coisas.

Observe que o descrito acima se aplica apenas a sistemas operacionais no estilo POSIX: se você executar o QEMU no Windows, o acesso ao dispositivo pode ser completamente diferente do acesso regular a arquivos e sua declaração mais curta pode não funcionar. Pode ser que a distinção entre filee host_devicetenha sido criada principalmente para permitir a portabilidade do QEMU para outras arquiteturas de sistema, onde o acesso ao dispositivo é muito diferente dos arquivos regulares.

Você estava preocupado com o desempenho, mas eu esperaria que fosse essencialmente idêntico, já que todos os três drivers acabam chamando exatamente o mesmo trecho de código para implementar a funcionalidade principal , as funções bdrv_co_preadve .bdrv_co_pwritev

Ao sobrepor drivers uns sobre os outros, seria muito simples detectar se um determinado driver usa exatamente a mesma função que o driver que será sobreposto e otimizar a duplicação. Meu primeiro palpite seria que tal otimização seria realmente muito necessária, para evitar vários tipos de comportamentos tolos. Portanto, se a configuração acabar fazendo exatamente a mesma coisa, espero que ela faça o mesmo, não importa como seja declarada.