Description of problem

As Arm64 is using the block device as the rootfs in guest. If we run two or more kata-container instances
on one host, we will get following error:

root@entos-thunderx2-desktop:~# docker run -dt --runtime kata-runtime ubuntu
7baf2c0f26100b0e642ad4122ce9ea1cb556fb3ed6cfcb454cb0586cbbe6194d
root@entos-thunderx2-desktop:~# docker run -dt --runtime kata-runtime ubuntu
2065fcf560c136091b5e69b6a12c95de94308309bb7fd5309df852503752203a
docker: Error response from daemon: OCI runtime create failed: qemu-system-aarch64: -device virtio-blk,drive=image-9f100592ac95eec6,scsi=off,config-wce=off: Failed to get "write" lock
Is another process using the image?: unknown.

This is because all kata-container instances are sharing the same rootfs image. And all instances
want to open this file with RW permission. But this file has been locked by the first instance already.
Because we're using the RAW format for rootfs image.

We have tried to change the RAW format to QCOW or QCOW2 format. Yes, with 'COPY-ON-WRITE'
feature, we can run two or three instances at the same time. But, as the number of instances is inceasing,
the speed of creating instance becomes more and more slow. I think this may be caused by QCOW/QCOW2 itself. Because QCOW/QCOW2 haven't been used massively on cloud. Most cloud platforms are using network block device for virtual machines.

My question is that:
can we use NBD for kata-container instances to bypass this issue?

I know x86_64 is using persist memory, so it doesn't have similar issue @jodh-intel @gnawux @Pennyzct

(replace this text with the output of the kata-collect-data.sh script, after
you have reviewed its content to ensure it does not contain any private
information).