[Qemu-devel] Design of the blobstore

[Stefan Berger]

Hello!

  Over the last few days primarily Michael Tsirkin and I have discussed 
the design of the 'blobstore' via IRC (#virtualization). The intention 
of the blobstore is to provide storage to persist blobs that devices 
create. Along with these blobs possibly some metadata should be storable 
in this blobstore.

  An initial client for the blobstore would be the TPM emulation. The 
TPM's persistent state needs to be stored once it changes so it can be 
restored at any point in time later on, i.e., after a cold reboot of the 
VM. In effect the blobstore simulates the NVRAM of a device where it 
would typically store such persistent data onto.

  One design point of the blobstore is that it has to work with QEMU's 
block layer, i.e., it has to use images for storing the blobs onto and 
with that use the bdrv_* functions to write its data into these image. 
The reason for this is primarily QEMU's snapshot feature where snapshots 
of the VM can be taken assuming QCoW2 image format is being used. If one 
chooses to provide a QCoW2 image as the storage medium for the blobstore 
it would enable the snapshotting feature of QEMU automatically. I 
believe there is no other image format that would work and simply using 
plain files would in effect destroy the snapshot feature. Using a raw 
image file for example would prevent snapshotting.

  One property of the blobstore is that it has a certain required size 
for accommodating all blobs of device that want to store their blobs 
onto. The assumption is that the size of these blobs is know a-priori to 
the writer of the device code and all devices can register their space 
requirements with the blobstore during device initialization. Then 
gathering all the registered blobs' sizes plus knowing the overhead of 
the layout of the data on the disk lets QEMU calculate the total 
required (minimum) size that the image has to have to accommodate all 
blobs in a particular blobstore.

  So what I would like to discuss in this message for now is the design 
of the command line options for the blobstore in order to determine how 
to access a blobstore.

For experimenting I introduced a 'blobstore' command line option for 
QEMU with the following possible options:
- name=: the name of the blobstore
- drive=: the id of the drive used as image file, i.e., -drive 
id=my-blobs,format=raw,file=/tmp/blobstore.raw,if=none
- showsize: Show the size requirement for the image file
- create: the image file is created  (if found to be of size zero) and 
then formatted
- format: assuming the image file is there, format it before starting 
the VM; the device will always start with a clean state
- formatifbad: format the image file if an attempt to read its content 
fails upon first read

Monitor commands with similar functionality would follow later.

The intention behind the parameter 'create' is to make it as easy for 
the user as possible to start QEMU with a usable image file letting QEMU 
do the equivalent of 'qemu-img create -f <format> <image file> <size>'. 
This works fine and lets one start QEMU in one step as long as:
    - the user passed an empty image file via -drive 
...,file=/tmp/blobstore.raw
    - the format to use is raw

For the QCoW2 format, for example, this doesn't works since the QCoW2 
file passed via -drive ...,file=/tmp/blobstore.qcow2 cannot be of zero 
size. In this case the user would have to use the 'showsize' option and 
learn what size the drive has to be, then invoke 'qemu-img' with the 
size parameter and then subsequently start QEMU with the image. To find 
the size the user would have to use a command line like

qemu ... \
    -blobstore name=my-blobstore,drive=tpm-bs,showsize \
    -drive if=none,id=tpm-bs \
    -tpmdev libtpms,blobstore=my-blobstore,id=tpm0 \
    -device tpm-tis,tpmdev=tpm0

which would result in QEMU printing to stdout:

Blobstore tpm-store on drive with ID tpm-bs requires 83kb.

Once a QCoW2 image file has been created using

qemu-img create -f qcow2 /tmp/blobstore.qcow2 83k

QEMU can then subsequently be used with the following command line options:

qemu ... \
    -drive if=none,id=tpm-bs,file=/tmp/blobstore.qcow2 \
    -blobstore name=my-blobstore,drive=tpm-bs,formatifbad \
    -tpmdev libtpms,blobstore=my-blobstore,id=tpm0 \
    -device tpm-tis,tpmdev=tpm0

This would format the blank QCoW2 image only the very first time using 
the 'formatifbad' parameter.

Using a 'raw' image for the blobstore one could do the following to 
start QEMU in the first step:

touch /tmp/blobstore.raw

qemu ... \
    -blobstore name=my-blobstore,drive=tpm-bs,create \
    -drive if=none,id=tpm-bs,format=raw,file=/tmp/blobstore.raw \
    -tpmdev libtpms,blobstore=my-blobstore,id=tpm0 \
    -device tpm-tis,tpmdev=tpm0

This would make QEMU create the appropriately sized image and start the 
VM in one step.


Going a layer up into libvirt: To support SELinux labeling (svirt) 
libvirt could use the above steps as shown for QCoW2 with labeling of 
the file before starting QEMU.

A note at the end: If we were to drop the -drive option and support the 
file option for the image file in -blobstore, we could have more control 
over the creation of the image file in any wanted format, but that would 
mean replicating some of the -drive options in the -blobstore option. 
QCoW2 files could also be created if the passed file wasn't even 
existing, yet.

 Looking forward to your comments.

Regards,
    Stefan