我的文件系统上有一个qcow2 文件，我正在尝试查找该文件的大小。
为此，当我ls -l在存储文件的位置执行 a 时，我得到 13041664，这意味着文件大小约为 13 MB，当我执行 a 时file <filename>，我得到：
disk: QEMU QCOW Image (v2), has backing file (path
/var/lib/nova/instances/_base/035db99541e92b5cca93bf18a997d626f), 21474836480 bytes
我认为，文件大小约为 21 GB。
这是我对命令输出的误解还是文件系统内部发生的其他事情（精简配置之类的事情）？
更新：当我执行 a 时ls -l on var/lib/nova/instances/_base/035db99541e92b5cca93bf18a997d626f，我得到 als: cannot access /var/lib/nova/instances/_base/035db99541e92b5cca93bf18a997d626f: No such file or directory并且正确的是我在那里没有文件
更新2：输出qemu-img info <filename>如下：
image: disk
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 12M
cluster_size: 65536
backing file: /var/lib/nova/instances/_base/035db99541e92b5cca93bf18a997d626f512b73d …在https://cloud-images.ubuntu.com/groovy/current/上（除其他外）有 groovy-server-cloudimg-amd64-disk-kvm.img 和 groovy-server-cloudimg-amd64.img 。有什么不同？
cloud virtualization qcow2 system-installation kvm-virtualization
Tl/Dr：在 OS SSD 崩溃后重建 VM。寻找最佳实践技巧以查看我是否遗漏了任何内容，并确认 RAW 与 QCOW2 是否存在性能差异，以及是否可以使用相同的命令设置它们，或者需要不同的命令来设置它们。我对 Linux 不太熟悉，所以我需要大量阅读才能解读建议，但在此先感谢您！
大家好，我是一个非常环保的 Ubuntu 服务器用户，即使在使用它几年之后，它仍然是一种忘记它的时尚。我因用于 OS 的 OS SSD 出现故障而导致服务器崩溃，并且从未费心进行备份。我让系统重新启动并运行，但我正处于准备备份虚拟机的步骤中。以前我使用 14.04 LTS，但现在使用 18.04 LTS。下面的代码基本上是我用来启动虚拟机的代码，而且效果很好。我想看看就最佳实践而言，我是否遗漏了什么。
?
我确实需要添加控制台访问权限，因为 SSD 失败是由重新启动后未启动的 VM 启动的，那是它失控的时候。VM 将“启动”并可以 ping，但拒绝 SSH 连接，因此不能完全启动。我仍然需要学习如何设置控制台，并将在本周使用它，但我想知道这里是否还有什么我忽略的地方。
sudo ubuntu-vm-builder kvm xenial \
--dest /mnt/Chaos.raw \
--hostname Chaos \
--arch amd64 \
--mem 4096 \
--cpus 4 \
--user admin \
--pass password \
--bridge br0 \
--ip 172.16.5.21 \
--mask 255.255.255.0 \
--net 172.16.5.0 \
--bcast 172.16.5.255 \
--gw 172.16.5.1 \
--dns 172.16.5.2 \ …