Skip to content
  • Kevin Wolf's avatar
    d3c8c674
    block: Skip implicit nodes in query-block/blockstats · d3c8c674
    Kevin Wolf authored
    Commits 0db832f4 and 6cdbceb1 introduced the automatic insertion of filter
    nodes above the top layer of mirror and commit block jobs. The
    assumption made there was that since libvirt doesn't do node-level
    management of the block layer yet, it shouldn't be affected by added
    nodes.
    
    This is true as far as commands issued by libvirt are concerned. It only
    uses BlockBackend names to address nodes, so any operations it performs
    still operate on the root of the tree as intended.
    
    However, the assumption breaks down when you consider query commands,
    which return data for the wrong node now. These commands also return
    information on some child nodes (bs->file and/or bs->backing), which
    libvirt does make use of, and which refer to the wrong nodes, too.
    
    One of the consequences is that oVirt gets wrong information about the
    image size and stops the VM in response as long as a mirror or commit
    job is running:
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1470634
    
    
    
    This patch fixes the problem by hiding the implicit nodes created
    automatically by the mirror and commit block jobs in the output of
    query-block and BlockBackend-based query-blockstats as long as the user
    doesn't indicate that they are aware of those nodes by providing a node
    name for them in the QMP command to start the block job.
    
    The node-based commands query-named-block-nodes and query-blockstats
    with query-nodes=true still show all nodes, including implicit ones.
    This ensures that users that are capable of node-level management can
    still access the full information; users that only know BlockBackends
    won't use these commands.
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    Reviewed-by: default avatarPeter Krempa <pkrempa@redhat.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    Tested-by: default avatarEric Blake <eblake@redhat.com>
    d3c8c674
    block: Skip implicit nodes in query-block/blockstats
    Kevin Wolf authored
    Commits 0db832f4 and 6cdbceb1 introduced the automatic insertion of filter
    nodes above the top layer of mirror and commit block jobs. The
    assumption made there was that since libvirt doesn't do node-level
    management of the block layer yet, it shouldn't be affected by added
    nodes.
    
    This is true as far as commands issued by libvirt are concerned. It only
    uses BlockBackend names to address nodes, so any operations it performs
    still operate on the root of the tree as intended.
    
    However, the assumption breaks down when you consider query commands,
    which return data for the wrong node now. These commands also return
    information on some child nodes (bs->file and/or bs->backing), which
    libvirt does make use of, and which refer to the wrong nodes, too.
    
    One of the consequences is that oVirt gets wrong information about the
    image size and stops the VM in response as long as a mirror or commit
    job is running:
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1470634
    
    
    
    This patch fixes the problem by hiding the implicit nodes created
    automatically by the mirror and commit block jobs in the output of
    query-block and BlockBackend-based query-blockstats as long as the user
    doesn't indicate that they are aware of those nodes by providing a node
    name for them in the QMP command to start the block job.
    
    The node-based commands query-named-block-nodes and query-blockstats
    with query-nodes=true still show all nodes, including implicit ones.
    This ensures that users that are capable of node-level management can
    still access the full information; users that only know BlockBackends
    won't use these commands.
    
    Cc: qemu-stable@nongnu.org
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    Reviewed-by: default avatarPeter Krempa <pkrempa@redhat.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    Tested-by: default avatarEric Blake <eblake@redhat.com>
Loading