[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Design of the blobstore

From: Stefan Berger
Subject: [Qemu-devel] Design of the blobstore
Date: Wed, 14 Sep 2011 13:05:44 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]