Comment 17 for bug 1858201

Thanks for your steps to create your pool in your case.
With that I recreated the issue:

$ sudo zpool create zpool -m /data/zpool mirror /dev/nvme0n1p3 /dev/nvme0n1p4
$ virsh pool-define-as --name zpool --source-name zpool --type zfs
$ virsh pool-start zpool
$ virsh pool-autostart zpool

Yours is much bigger than mine it seems, let see if that plays a role
yours:
  <capacity unit='bytes'>49928994816</capacity>
    <allocation unit='bytes'>139776</allocation>
  <available unit='bytes'>49928855040</available>

The data you sent was already good, the one thing I'm missing is the XML that Maas sends to libvirt to actually create the volume from the pool.
The guest definition that was added also has no disks, so I have to make assumptions.
For now I'll make up my own, but adding that can help if I can't reproduce.

With the above I let libvirt create a volume of 8GB (as reported 8-15G failing); 16 is working.

In Libvirt you can pass #bytes (the default) or scaled integers with e.g. G,GiB meaning powers of 2 and GB being a power of 10. For the test I tried different ones here.

Also you can tell it to allocate a specific amount of it. I have played with that as well.

I'll always report the XML that was used as it can be reported as well, that you can match to your requests sent by Maas.

basic
$ virsh vol-create-as zpool testvol1 8G
(worked)
matches:
<volume>
  <name>testvol1</name>
  <capacity>8589934592</capacity>
</volume>

with allocation:
$ virsh vol-create-as zpool testvol2 8G --allocation 8G --print-xml
matches:
<volume>
  <name>testvol2</name>
  <capacity>8589934592</capacity>
  <allocation>8589934592</allocation>
</volume>

Of course if you are passing it a wrong size not matching ZFS needs of 8k it will fail:
Here using the power-of-10 based GB
$ virsh vol-create-as zpool testvol3 8GB
error: Failed to create vol testvol3
error: internal error: Child process (/sbin/zfs create -V 7812500K zpool/testvol3) unexpected exit status 1: cannot create 'zpool/testvol3': volume size must be a multiple of volume block size

Your bug report shows 8789063K, which is in bytes a suspicious "9000000512".
Aren't you sure there might be some rounding from maas going on already?
We'd really need to see what you passed to libvirt to allocate the disk.
Newel can you get that XML content?

Right now I'm assuming you pass it in bytes and do not round to 8k on your side, or you pass it with "GB" instead of "G" as suffix.

P.S. I'll try to catch your people here on the sprint, maybe one can help me with that.