April 2019 - Libguestfs - libguestfs List Archives

[PATCH] v2v: Implement SSH password authentication for Xen and VMX over SSH.
by Richard W.M. Jones 17 Apr '19

17 Apr '19

This isn't quite the full thing. I think that Pino is also working on replacing the ssh and scp commands in the v2v/input_vmx.ml file with libssh. Without those changes, -i vmx will still issue raw ssh and scp commands, which will use ssh-agent (or keyboard-interactive). The Xen input method doesn't use raw ssh and scp commands, so that one is OK. Rich.

1 1

nbdkit, VDDK, extents, readahead, etc
by Richard W.M. Jones 16 Apr '19

16 Apr '19

As I've spent really too long today investigating this, I want to document this in a public email, even though there's nothing really that interesting here. One thing you find from search for VDD 6.7 / VixDiskLib_QueryAllocatedBlocks issues with Google is that we must be one of the very few users out there. And the other thing is that it's quite broken. All testing was done using two baremetal servers connected back to back through a gigabit ethernet switch. I used upstream qemu and nbdkit from git as of today. I used a single test Fedora guest with a 16G thin provisioned disk with about 1.6G allocated. Observations: (1) VDDK hangs for a really long time when using the nbdkit --run option. It specifically hangs for exactly 120 seconds doing: nbdkit: debug: VixDiskLib: Resolve host. This seems to be a bug in VDDK, possibly connected with the fact that we fork after initializing VDDK but before doing the VixDiskLib_ConnectEx. I suspect it's something to do with the PID changing. It would be fair to deduct 2 minutes from all timings below. (2) VDDK cannot use VixDiskLib_QueryAllocatedBlocks if the disk is opened for writes. It fails with this uninformative error: nbdkit: vddk[1]: error: [NFC ERROR] NfcFssrvrProcessErrorMsg: received NFC error 13 from server: NfcFssrvrOpen: Failed to open '[datastore1] Fedora 28/Fedora 28.vmdk' nbdkit: vddk[1]: error: [NFC ERROR] NfcFssrvrClientOpen: received unexpected message 4 from server nbdkit: vddk[1]: debug: VixDiskLib: Detected DiskLib error 290 (NBD_ERR_GENERIC). nbdkit: vddk[1]: debug: VixDiskLib: VixDiskLibQueryBlockList: Fail to start query process. Error 1 (Unknown error) (DiskLib error 290: NBD_ERR_GENERIC) at 543. nbdkit: vddk[1]: debug: can_extents: VixDiskLib_QueryAllocatedBlocks test failed, extents support will be disabled: original error: Unknown error The last debug statement is from nbdkit itself indicating that because VixDiskLib_QueryAllocatedBlocks didn't work, extents support is disabled. To work around this you can use nbdkit --readonly. However I don't understand why that would be necessary, except perhaps it's just an undocumented limitation of VDDK. For all the cases _we_ care about we're using --readonly, so that's lucky. (3) Using nbdkit-noextents-filter and nbdkit-stats-filter we can nicely measure the benefits of extents: With noextents (ie. force full copy): elapsed time: 323.815 s read: 8194 ops, 17179869696 bytes, 4.24437e+08 bits/s Without noextents (ie. rely on qemu-img skipping sparse bits): elapsed time: 237.41 s read: 833 ops, 1734345216 bytes, 5.84423e+07 bits/s extents: 70 ops, 135654246400 bytes, 4.57114e+09 bits/s Note if you deduct 120 seconds (see point (1) above) from these times then it goes from 203s -> 117s, about a 40% saving. We can likely do better by having > 32 bit requests and qemu not using NBD_CMD_FLAG_REQ_ONE. (4) We can also add nbdkit-readahead-filter in both cases to see if that helps or not: With noextents and readahead: elapsed time: 325.358 s read: 265 ops, 17179869184 bytes, 4.22423e+08 bits/s As expected the readahead filter reduces the numbers of iops greatly. But in this back-to-back configuration VDDK requests are relatively cheap so no time is saved. Without noextents, with readahead: elapsed time: 252.608 s read: 96 ops, 1927282688 bytes, 6.10363e+07 bits/s extents: 70 ops, 135654246400 bytes, 4.29612e+09 bits/s Readahead is detrimental in this case, as expected because this filter works best when reads are purely sequential, and if not it will tend to prefetch extra data. Notice that the number of bytes read is larger here than in the earlier test. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/

3 6

[PATCH] daemon: drop error message check in do_part_expand_gpt
by Denis Plotnikov 16 Apr '19

16 Apr '19

part-expand-gpt takes extreme cautions and doesn't proceed to writing to the disk if the preliminary dry run of sgdisk has generated any warnings on stdout. This blocks the use of part-expand-gpt on disk shrink (with disk resize being the main usecase for part-expand-gpt), because sgdisk dry run produces a warning in that case. So remove the excessive safety check, and leave it up to the caller. Signed-off-by: Denis Plotnikov <dplotnikov(a)virtuozzo.com> Reviewed-by: Roman Kagan <rkagan(a)virtuozzo.com> --- daemon/parted.c | 20 +------------------- tests/gdisk/test-expand-gpt.pl | 24 +++++++++++++++++++++--- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/daemon/parted.c b/daemon/parted.c index 070ed4790..2cc714d64 100644 --- a/daemon/parted.c +++ b/daemon/parted.c @@ -699,26 +699,8 @@ do_part_expand_gpt(const char *device) { CLEANUP_FREE char *err = NULL; - /* If something is broken, sgdisk may try to correct it. - * (e.g. recreate partition table and so on). - * We do not want such behavior, so dry-run at first.*/ int r = commandf (NULL, &err, COMMAND_FLAG_FOLD_STDOUT_ON_STDERR, - "sgdisk", "--pretend", "-e", device, NULL); - - if (r == -1) { - reply_with_error ("%s --pretend -e %s: %s", "sgdisk", device, err); - return -1; - } - if (err && strlen(err) != 0) { - /* Unexpected actions. */ - reply_with_error ("%s --pretend -e %s: %s", "sgdisk", device, err); - return -1; - } - free(err); - - /* Now we can do a real run. */ - r = commandf (NULL, &err, COMMAND_FLAG_FOLD_STDOUT_ON_STDERR, - "sgdisk", "-e", device, NULL); + "sgdisk", "-e", device, NULL); if (r == -1) { reply_with_error ("%s -e %s: %s", "sgdisk", device, err); diff --git a/tests/gdisk/test-expand-gpt.pl b/tests/gdisk/test-expand-gpt.pl index 4d647f1af..f17d034ee 100755 --- a/tests/gdisk/test-expand-gpt.pl +++ b/tests/gdisk/test-expand-gpt.pl @@ -54,11 +54,29 @@ sub tests { my $end_sectors = 100 * 1024 * 2 - $output; die unless $end_sectors <= 34; - # Negative tests. + # Negative test. eval { $g->part_expand_gpt ("/dev/sdb") }; die unless $@; - eval { $g->part_expand_gpt ("/dev/sda1") }; - die unless $@; + + $g->close (); + + # Disk shrink test + die if system ("qemu-img resize --shrink disk_gpt.img 50M &>/dev/null"); + + $g = Sys::Guestfs->new (); + + $g->add_drive ("disk_gpt.img", format => "qcow2"); + $g->launch (); + + die if $g->part_expand_gpt ("/dev/sda"); + + my $output = $g->debug ("sh", ["sgdisk", "-p", "/dev/sda"]); + die if $output eq ""; + $output =~ s/\n/ /g; + $output =~ s/.*last usable sector is (\d+).*/$1/g; + + my $end_sectors = 50 * 1024 * 2 - $output; + die unless $end_sectors <= 34; } eval { tests() }; -- 2.17.2

2 1

[PATCH] v2v: -o rhv-upload: check whether the cluster exists
by Pino Toscano 16 Apr '19

16 Apr '19

In the precheck script, check that the target cluster actually exists. This will avoid errors when creating the VM after the data copying. --- v2v/rhv-upload-precheck.py | 10 ++++++++++ v2v/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py | 7 +++++++ 2 files changed, 17 insertions(+) diff --git a/v2v/rhv-upload-precheck.py b/v2v/rhv-upload-precheck.py index 2798a29dd..b79f91b4a 100644 --- a/v2v/rhv-upload-precheck.py +++ b/v2v/rhv-upload-precheck.py @@ -70,4 +70,14 @@ if len(vms) > 0: raise RuntimeError("VM already exists with name ‘%s’, id ‘%s’" % (params['output_name'], vm.id)) +# Check whether the specified cluster exists. +clusters_service = system_service.clusters_service() +clusters = clusters_service.list( + search='name=%s' % params['rhv_cluster'], + case_sensitive=True, +) +if len(clusters) == 0: + raise RuntimeError("The cluster ‘%s’ does not exist" % + (params['rhv_cluster'])) + # Otherwise everything is OK, exit with no error. diff --git a/v2v/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py b/v2v/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py index 8d1058d67..cc4224ccd 100644 --- a/v2v/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py +++ b/v2v/test-v2v-o-rhv-upload-module/ovirtsdk4/__init__.py @@ -39,6 +39,9 @@ class Connection(object): return SystemService() class SystemService(object): + def clusters_service(self): + return ClustersService() + def data_centers_service(self): return DataCentersService() @@ -54,6 +57,10 @@ class SystemService(object): def vms_service(self): return VmsService() +class ClustersService(object): + def list(self, search=None, case_sensitive=False): + return ["Default"] + class DataCentersService(object): def list(self, search=None, case_sensitive=False): return [] -- 2.20.1

2 1

[PATCH v2v 1/2] v2v: windows: Add a helper function for installing Powershell firstboot scripts.
by Richard W.M. Jones 15 Apr '19

15 Apr '19

--- v2v/windows.ml | 24 ++++++++++++++++++++++++ v2v/windows.mli | 6 ++++++ 2 files changed, 30 insertions(+) diff --git a/v2v/windows.ml b/v2v/windows.ml index 23d589b00..dde64e677 100644 --- a/v2v/windows.ml +++ b/v2v/windows.ml @@ -19,6 +19,7 @@ open Printf open Common_gettext.Gettext +open Std_utils open Tools_utils open Utils @@ -45,3 +46,26 @@ and check_app { Guestfs.app2_name = name; publisher =~ rex_avg_tech and (=~) str rex = PCRE.matches rex str + +(* Unfortunately Powershell scripts cannot be directly executed + * (unless some system config changes are made which for other + * reasons we don't want to do) and so we have to run this via + * a regular batch file. + *) +let install_firstboot_powershell g { Types.i_windows_systemroot; i_root } + filename code = + let tempdir = sprintf "%s/Temp" i_windows_systemroot in + g#mkdir_p tempdir; + let code = String.concat "\r\n" code ^ "\r\n" in + g#write (sprintf "%s/%s" tempdir filename) code; + + (* Powershell interpreter. Should we check this exists? XXX *) + let ps_exe = + i_windows_systemroot ^ + "\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" in + + (* Windows path to the Powershell script. *) + let ps_path = i_windows_systemroot ^ "\\Temp\\" ^ filename in + + let fb = sprintf "%s -ExecutionPolicy ByPass -file %s" ps_exe ps_path in + Firstboot.add_firstboot_script g i_root filename fb diff --git a/v2v/windows.mli b/v2v/windows.mli index 016ef2a78..6db7874b0 100644 --- a/v2v/windows.mli +++ b/v2v/windows.mli @@ -21,3 +21,9 @@ val detect_antivirus : Types.inspect -> bool (** Return [true] if anti-virus (AV) software was detected in this Windows guest. *) + +val install_firstboot_powershell : Guestfs.guestfs -> Types.inspect -> + string -> string list -> unit +(** [install_powershell_firstboot g inspect filename code] installs a + Powershell script (the lines of code) as a firstboot script in + the Windows VM. *) -- 2.20.1

2 2

virt-v2v slow when running inside the VM
by Sureshkumar Kaliannan 13 Apr '19

13 Apr '19

Hi, I'm trying to create a clone of a physical Window VM using p2v. My goal is to create a cloning tools VM that has libguestfs tools installed and acts as the convertor. VM conversion works just fine but the conversion rate is significantly slow(1/3) when running inside the VM compared to when the v2v is run on the same bare-metal host. On the host: ./virt-p2v-20190405-w1f4efxy/virt-v2v-conversion-log.txt:virtual copying rate: 615.9 M bits/sec ./virt-p2v-20190405-w1f4efxy/virt-v2v-conversion-log.txt:real copying rate: 181.8 M bits/sec >From the Guest VM (On the same bare-metal host) virt-p2v-20190405-95azj89j/virt-v2v-conversion-log.txt:virtual copying rate: 185.1 M bits/sec virt-p2v-20190405-95azj89j/virt-v2v-conversion-log.txt:real copying rate: 62.7 M bits/sec I understand there are several factors come into play but i tried to make the VM comparable by making sure enough CPU / memory is given to the VM. Also the I played by adjusting the disk cache modes for the VM(cache=none, cache=unsafe). When the conversion happens there is not much load and there are no other VMs on this machine. I ruled out the disk being the bootleneck because when i do "virt-v2v -i disk" conversion the VM is only slightly off. For the same disk image, virt-v2v when running in the host took '75 sec' whereas in the VM it took '100 sec' How to go about debugging this performance issue? Any pointers would be helpful thanks Suresh

2 5

[PATCH] v2v: warn when the guest has direct network interfaces (RHBZ#1518539)
by Pino Toscano 12 Apr '19

12 Apr '19

virt-v2v obviously cannot convert this kind of devices, since they are specific to the host of the hypervisor. Thus, emit a warning about the presence of direct network interfaces, so at least this can be noticed when converting a guest. --- v2v/parse_libvirt_xml.ml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/v2v/parse_libvirt_xml.ml b/v2v/parse_libvirt_xml.ml index 9cf4c496b..14cd82afd 100644 --- a/v2v/parse_libvirt_xml.ml +++ b/v2v/parse_libvirt_xml.ml @@ -499,6 +499,24 @@ let parse_libvirt_xml ?conn xml = ) in + (* Check for direct attachments to physical network interfaces. + * (RHBZ#1518539) + *) + let () = + let obj = Xml.xpath_eval_expression xpathctx "/domain/devices/interface[@type='direct']" in + let nr_nodes = Xml.xpathobj_nr_nodes obj in + if nr_nodes > 0 then ( + (* Sadly fn_ in ocaml-gettext seems broken, and always returns the + * singular string no matter what. Work around this by using a simple + * string with sn_ (which works), and outputting it as a whole. + *) + let msg = sn_ "this guest has a direct network interface which will be ignored" + "this guest has direct network interfaces which will be ignored" + nr_nodes in + warning "%s" msg + ) + in + ({ s_hypervisor = hypervisor; s_name = name; s_orig_name = name; -- 2.20.1

2 1

[PATCH] v2v: update documentation on nbdkit (RHBZ#1605242)
by Pino Toscano 12 Apr '19

12 Apr '19

nbdkit >= 1.6 ships a VDDK plugin always built, so recommend that version instead of recommending to build nbdkit from sources. --- v2v/virt-v2v-input-vmware.pod | 28 ++-------------------------- 1 file changed, 2 insertions(+), 26 deletions(-) diff --git a/v2v/virt-v2v-input-vmware.pod b/v2v/virt-v2v-input-vmware.pod index 2b6dbaeec..b3ebda182 100644 --- a/v2v/virt-v2v-input-vmware.pod +++ b/v2v/virt-v2v-input-vmware.pod @@ -197,32 +197,8 @@ library is permitted by the license. =item 2. -You must also compile nbdkit, enabling the VDDK plugin. nbdkit E<ge> -1.1.25 is recommended, but it is usually best to compile from the git -tree. - -=over 4 - -=item * - -L<https://github.com/libguestfs/nbdkit> - -=item * - -L<https://github.com/libguestfs/nbdkit/tree/master/plugins/vddk> - -=back - -Compile nbdkit as described in the sources (see link above). - -You do B<not> need to run C<make install> because you can run nbdkit -from its source directory. The source directory has a shell script -called F<nbdkit> which runs the locally built copy of nbdkit and its -plugins. So set C<$PATH> to point to the nbdkit top build directory -(that is, the directory containing the shell script called F<nbdkit>), -eg: - - export PATH=/path/to/nbdkit-1.1.x:$PATH +nbdkit E<ge> 1.6 is recommended, as it ships with the VDDK plugin +enabled unconditionally. =item 3. -- 2.20.1

2 1

[supermin PATCH 0/5] rpm: fix package selection w/ multilib
by Pino Toscano 12 Apr '19

12 Apr '19

This patch series fixes the way supermin sorts the list of installed packages when resolving a name, picking the right package for the host architecture. Pino Toscano (5): rpm: do not unpack parameters rpm: fix version comparison rpm: query the RPM architecture rpm: fix package sorting (RHBZ#1696822) utils: remove unused 'compare_architecture' function src/librpm-c.c | 10 ++++++++++ src/librpm.ml | 1 + src/librpm.mli | 3 +++ src/ph_rpm.ml | 44 ++++++++++++++++++++++++++++++++++++++------ src/utils.ml | 27 --------------------------- src/utils.mli | 3 --- 6 files changed, 52 insertions(+), 36 deletions(-) -- 2.20.1

2 6

[RFC PATCH] protocol: Add NBD_CMD_FLAG_FAST_ZERO
by Eric Blake 12 Apr '19

12 Apr '19

While it may be counterintuitive at first, the introduction of NBD_CMD_WRITE_ZEROES and NBD_CMD_BLOCK_STATUS has caused a performance regression in qemu [1], when copying a sparse file. When the destination file must contain the same contents as the source, but it is not known in advance whether the destination started life with all zero content, then there are cases where it is faster to request a bulk zero of the entire device followed by writing only the portions of the device that are to contain data, as that results in fewer I/O transactions overall. In fact, there are even situations where trimming the entire device prior to writing zeroes may be faster than bare write zero request [2]. However, if a bulk zero request ever falls back to the same speed as a normal write, a bulk pre-zeroing algorithm is actually a pessimization, as it ends up writing portions of the disk twice. [1] https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06389.html [2] https://github.com/libguestfs/nbdkit/commit/407f8dde Hence, it is desirable to have a way for clients to specify that a particular write zero request is being attempted for a fast wipe, and get an immediate failure if the zero request would otherwise take the same time as a write. Conversely, if the client is not performing a pre-initialization pass, it is still more efficient in terms of networking traffic to send NBD_CMD_WRITE_ZERO requests where the server implements the fallback to the slower write, than it is for the client to have to perform the fallback to send NBD_CMD_WRITE with a zeroed buffer. Add a protocol flag and corresponding transmission advertisement flag to make it easier for clients to inform the server of their intent. If the server advertises NBD_FLAG_SEND_FAST_ZERO, then it promises two things: to perform a fallback to write when the client does not request NBD_CMD_FLAG_FAST_ZERO (so that the client benefits from the lower network overhead); and to fail quickly with ENOTSUP if the client requested the flag but the server cannot write zeroes more efficiently than a normal write (so that the client is not penalized with the time of writing data areas of the disk twice). Note that the semantics are chosen so that servers should advertise the new flag whether or not they have fast zeroing (that is, this is NOT the server advertising that it has fast zeroes, but rather advertising that the client can get feedback as needed on whether zeroing is fast). It is also intentional that the new advertisement includes a new errno value, ENOTSUP, with rules that this error should not be returned for any pre-existing behaviors, must not happen when the client does not request a fast zero, and must be returned quickly if the client requested fast zero but anything other than the error would not be fast; while leaving it possible for clients to distinguish other errors like EINVAL if alignment constraints are not met. Clients should not send the flag unless the server advertised support, but well-behaved servers should already be reporting EINVAL to unrecognized flags. If the server does not advertise the new feature, clients can safely fall back to assuming that writing zeroes is no faster than normal writes. Note that the Linux fallocate(2) interface may or may not be powerful enough to easily determine if zeroing will be efficient - in particular, FALLOC_FL_ZERO_RANGE in isolation does NOT give that insight; for block devices, it is known that ioctl(BLKZEROOUT) does NOT have a way for userspace to probe if it is efficient or slow. But with enough demand, the kernel may add another FALLOC_FL_ flag to use with FALLOC_FL_ZERO_RANGE, and/or appropriate ioctls with guaranteed ENOTSUP failures if a fast path cannot be taken. If a server cannot easily determine if write zeroes will be efficient, it is better off not advertising NBD_FLAG_SEND_FAST_ZERO. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- I will not push this without both: - a positive review (for example, we may decide that burning another NBD_FLAG_* is undesirable, and that we should instead have some sort of NBD_OPT_ handshake for determining when the server supports NBD_CMF_FLAG_FAST_ZERO) - a reference client and server implementation (probably both via qemu, since it was qemu that raised the problem in the first place) doc/proto.md | 44 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 43 insertions(+), 1 deletion(-) diff --git a/doc/proto.md b/doc/proto.md index 8aaad96..1107766 100644 --- a/doc/proto.md +++ b/doc/proto.md @@ -1059,6 +1059,17 @@ The field has the following format: which support the command without advertising this bit, and conversely that this bit does not guarantee that the command will succeed or have an impact. +- bit 11, `NBD_FLAG_SEND_FAST_ZERO`: allow clients to detect whether + `NBD_CMD_WRITE_ZEROES` is efficient. The server MUST set this + transmission flag to 1 if the `NBD_CMD_WRITE_ZEROES` request + supports the `NBD_CMD_FLAG_FAST_ZERO` flag, and MUST set this + transmission flag to 0 if `NBD_FLAG_SEND_WRITE_ZEROES` is not + set. Servers SHOULD NOT set this transmission flag if there is no + quick way to determine whether a particular write zeroes request + will be efficient, but the lack of an efficient write zero + implementation SHOULD NOT prevent a server from setting this + flag. Clients MUST NOT set the `NBD_CMD_FLAG_FAST_ZERO` request flag + unless this transmission flag is set. Clients SHOULD ignore unknown flags. @@ -1636,6 +1647,12 @@ valid may depend on negotiation during the handshake phase. MUST NOT send metadata on more than one extent in the reply. Client implementors should note that using this flag on multiple contiguous requests is likely to be inefficient. +- bit 4, `NBD_CMD_FLAG_FAST_ZERO`; valid during + `NBD_CMD_WRITE_ZEROES`. If set, but the server cannot perform the + write zeroes any faster than it would for an equivalent + `NBD_CMD_WRITE`, then the server MUST fail quickly with an error of + `ENOTSUP`. The client MUST NOT set this unless the server advertised + `NBD_FLAG_SEND_FAST_ZERO`. ##### Structured reply flags @@ -2004,7 +2021,10 @@ The following request types exist: reached permanent storage, unless `NBD_CMD_FLAG_FUA` is in use. A client MUST NOT send a write zeroes request unless - `NBD_FLAG_SEND_WRITE_ZEROES` was set in the transmission flags field. + `NBD_FLAG_SEND_WRITE_ZEROES` was set in the transmission flags + field. Additionally, a client MUST NOT send the + `NBD_CMD_FLAG_FAST_ZERO` flag unless `NBD_FLAG_SEND_FAST_ZERO` was + set in the transimssion flags field. By default, the server MAY use trimming to zero out the area, even if it did not advertise `NBD_FLAG_SEND_TRIM`; but it MUST ensure @@ -2014,6 +2034,23 @@ The following request types exist: same area will not cause fragmentation or cause failure due to insufficient space. + If the server advertised `NBD_FLAG_SEND_FAST_ZERO` but + `NBD_CMD_FLAG_FAST_ZERO` is not set, then the server MUST NOT fail + with `ENOTSUP`, even if the operation is no faster than a + corresponding `NBD_CMD_WRITE`. Conversely, if + `NBD_CMD_FLAG_FAST_ZERO` is set, the server MUST fail quickly with + `ENOTSUP` unless the request can be serviced more efficiently than + a corresponding `NBD_CMD_WRITE`. The server's determination of + efficiency MAY depend on whether the request was suitably aligned, + on whether the `NBD_CMD_FLAG_NO_HOLE` flag was present, or even on + whether a previous `NBD_CMD_TRIM` had been performed on the + region. If the server did not advertise + `NBD_FLAG_SEND_FAST_ZERO`, then it SHOULD NOT fail with `ENOTSUP`, + regardless of the speed of servicing a request, and SHOULD fail + with `EINVAL` if the `NBD_CMD_FLAG_FAST_ZERO` flag was set. A + server MAY advertise `NBD_FLAG_SEND_FAST_ZERO` whether or not it + can perform efficient zeroing. + If an error occurs, the server MUST set the appropriate error code in the error field. @@ -2114,6 +2151,7 @@ The following error values are defined: * `EINVAL` (22), Invalid argument. * `ENOSPC` (28), No space left on device. * `EOVERFLOW` (75), Value too large. +* `ENOTSUP` (95), Operation not supported. * `ESHUTDOWN` (108), Server is in the process of being shut down. The server SHOULD return `ENOSPC` if it receives a write request @@ -2125,6 +2163,10 @@ request is not aligned to advertised minimum block sizes. Finally, it SHOULD return `EPERM` if it receives a write or trim request on a read-only export. +The server SHOULD NOT return `ENOTSUP` except as documented in +response to `NBD_CMD_WRITE_ZEROES` when `NBD_CMD_FLAG_FAST_ZERO` is +supported. + The server SHOULD return `EINVAL` if it receives an unknown command. The server SHOULD return `EINVAL` if it receives an unknown command flag. It -- 2.20.1

5 7