这是一个奇怪的问题，所以请忍耐一下。
我有一个可以执行以下操作的工具：
通过 HTTP API（Flask）上传磁盘映像（VMDK）。
在 API 方面，它创建一个临时块设备（为了完整性，它创建一个 RBD 卷并映射它）。
它将上传的 VMDK 写入临时块设备。
它（尝试）运行
qemu-img convert以将临时块设备上的 VMDK 映像转换为真实设备上的 VMDK 映像。
这样做的目的是允许人们上传 VMDK 图像，然后将其转换为 RAW 图像以供 KVM VM 使用。
但是，你可以忽略上述内容；这只是我的 Y 的 X，所以你不会认为我陷入了一些荒谬的 XY 难题；这就是它有否则我需要 API 系统上有任意数量的 RAM，这显然是不可行的。我可以通过创建卷（任意大小）、dd将 VMDK 添加到卷中，然后qemu-img convert在其上运行来复制该问题，因此不是我的 API 导致了该问题。
为了实现上述目的，我使用 Pythonos.path.getsize()函数读取了 VMDK 文件的大小，该大小与显示的大小相匹配ls -l。临时块设备的大小根据此值确定。
问题在于：一旦 VMDK 位于临时块设备上，qemu-img convert对其进行操作的尝试就会失败，并出现“无效页脚”。
qemu-img: Could not open '/dev/rbd/vms/test_import': Invalid footer
我发现，每当目标文件与 VMDK 文件大小不同时，它都会对 VMDK 文件执行此操作，例如，如果它太小，或者令人讨厌的是，太大了。所以很明显，我对临时块设备的大小存在某种问题。
但是，我尝试根据各种值正确调整此临时卷的大小：ls -l、Python os.stat()、du -B 1（给出不同的值），但每次都失败。图像也很稀疏，因此从中获取大小qemu-img info没有帮助。我尝试在两侧缓慢增加这些大小，但也没有成功（因此这不是明显的 1 倍误差）。
所以，我的问题是：我怎样才能找到实际的，真实的，不会抛出这个错误qemu-img 需要的 VMDK 大小预计这样它才不会变得如此“腐败”？
答案1
当然，只要发布并阅读它，我就能找出问题所在。它就是我所说的：RBD 图像尺寸错误。为什么它的大小错误，是我在创建它时在将人类可读的值转换为字节时没有考虑 1024 与 1000。