On 11/23/18 3:56 AM, Han Han wrote:
> Then, as Rich pointed out, when you expose qcow2 over NBD (the
former
> setup), the current NBD protocol does NOT allow resizes - so while
> reading the image works okay, writing to the image is likely to hit
> ENOSPC unless you pre-allocated the .qcow2 file being served. That is
> likely to change upstream in the next six months (it's on my todo list
> to get NBD resize implemented), but there's still a percolation delay
> from upstream to using it in default OS installs. On the other hand,
> when you expose raw over NBD by using qemu-nbd to convert qcow2 to raw
> on the server end, then the server can resize things as needed and the
> client need not be aware that qcow2 is even involved.
>
> After nbd resize implemented, we can get actual disk size instread of
'unavailable', right?
qemu-img will probably always report 'disk size: unavailable' for NBD
exports. For regular raw files, it obtains that information by calling
stat(), but the NBD protocol does not have an equivalent to stat() for
showing how much disk space an image occupies. But you can safely
ignore that line being listed as 'unavailable', because by the time you
are talking to a remote server, it is the remote server's problem about
how much space the image occupies, and not yours, because the image
doesn't occupy any space locally.
Will it support disk extend, or just support disk shrinking?
Whether the extension will support extension and/or shrinking will
depend on the server. Most likely, there will be servers that support
extension but not shrinking (as it is much easier to extend than it is
to worry about whether a shrink will truncate important data). And, the
point of being an extension means that a client should be prepared for a
server that does not support resizes, or that some resize requests will
fail even if others can succeed.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org