On 5/13/20 9:06 AM, Kevin Wolf wrote:
One more thing to consider is, what if a single object has multiple
connections? In the case of node-names, we have a limited set of allowed
characters, so we can use one of the remaining characters as a separator
and then suffix a counter. In other places, the identifier isn't
restricted, so suffixing doesn't work. Maybe prefixing does, but it
would have to be there from the beginning then.
Yeh I worry about whether on nbd if you can have multiple nbd
connections to one block device.
The kernel NBD driver now supports multiple parallel connections.
QEMU hasn't implemented this in its NBD code yet, but I certainly
see that being in scope for future.
It's not parallel for performance that worries me, it's more about
separateq connections for separate uses - e.g. if we're serving the same
read-only disk to multiple separate things.
That would be a concern for the NBD server. I'm not sure if anything in
QEMU ever waits for NBD servers (except for the client on the other side
of the connection, of course), so there might be no use case for yanking
their connections.
Anyway, here we were talking about the NBD client, which always accesses
one disk. If you access a second disk, you have a second NBD block node.
Ah, right, that's the other direction. No, we do not currently support
a single qemu block node backed by multiple NBD clients to one (or more,
if they are serving identical content in a failover scenario) NBD
servers. Performance could indeed be potentially improved by doing
that, but for now, every time qemu behaves as a new NBD client, it is
via an additional block node.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
