qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Design of the blobstore


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Design of the blobstore
Date: Wed, 14 Sep 2011 20:40:20 +0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Sep 14, 2011 at 01:05:44PM -0400, Stefan Berger wrote:
> 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.

So you envision tools parsing this freetext then?
Seems like a step back, we are trying to move to QMP ...

> 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.

This formatifbad option is a bad mistake (pun intended).
It mixes the formatting of image (one time operation)
and running of VM (repeated operation). We also saw how this does
not play well e.g. with migration.

It loses information! Would you like your OS
to format hard disk if it can not boot? Right ...

Instead, just failing if image is not well formatted
will be much easier to debug.

> 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

So with above, the raw case which we don't expect to be used often
is easy to use, but qcow which we expect to be the main case
is close to imposible, involving manual cut and paste
of image size.

Formatting images seems a rare enough occasion,
that I think only using monitor command for that
would be a better idea than a ton of new command
line options. On top of that, let's write a
script that run qemu, queries image size,
creates a qcow2 file, run qemu again to format,
all this using QMP.

WRT 'format and run in one go' I strongly disagree with it.
It's just too easy to shoot oneself in the foot.


-- 
MST



reply via email to

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