[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and opt
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling |
Date: |
Tue, 15 Mar 2011 08:27:18 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 |
On 03/15/2011 05:09 AM, Kevin Wolf wrote:
5) Very complex data types can be implemented. We had some discussion
of supporting nested structures with -blockdev. This wouldn't work with
QemuOpts but I've already implemented it with QCFG (blockdev syntax is
my test case right now). The syntax I'm currently using is -blockdev
cache=none,id=foo,format.qcow.protocol.nbd.hostname=localhost where '.'
is used to reference sub structures.
Do you have an example from your implementation for this?
It's not exhaustive as I'm only using this for testing but here's what
I've been working with:
{ 'type': 'ProbeProtocol', 'data': { 'unsafe': 'bool', 'filename': 'str' } }
{ 'type': 'FileProtocol', 'data': { 'filename': 'str' } }
{ 'type': 'HostDeviceProtocol', 'data': { 'device': 'str' } }
{ 'type': 'NbdProtocol', 'data': { 'hostname': 'str', 'port': 'int' } }
{ 'union': 'BlockdevProtocol',
'data': { 'probe': 'ProbeProtocol', 'file': 'FileProtocol',
'host-dev': 'HostDeviceProtocol', 'nbd': 'NbdProtocol' } }
{ 'type': 'ProbeFormat', 'data': { '*unsafe': 'bool', 'protocol':
'BlockdevProtocol' } }
{ 'type': 'RawFormat', 'data': { 'protocol': 'BlockdevProtocol' } }
{ 'type': 'Qcow2Format',
'data': { 'protocol': 'BlockdevProtocol',
'*backing-file': 'BlockdevFormat' } }
{ 'type': 'QedFormat',
'data': { 'protocol': 'BlockdevProtocol',
'*backing-file': 'BlockdevFormat',
'*copy-on-read': 'bool' } }
{ 'union': 'BlockdevFormat',
'data': { 'probe': 'ProbeFormat', 'raw': 'RawFormat',
'qcow2': 'Qcow2Format', 'qed': 'QedFormat' } }
{ 'enum': 'BlockdevCacheSetting',
'data': [ 'none', 'writethrough', 'writeback' ] }
{ 'type': 'BlockdevConfig',
'data': { 'id': 'str',
'format': 'BlockdevFormat',
'*cache': 'BlockdevCacheSetting',
'*device': 'str' } }
{ 'option': 'blockdev', 'data': 'BlockdevConfig', 'implicit': 'id' }
Choosing a union is implicit in selecting the union value. This was
done to simplify the command line. Here are some examples:
# create a blockdev using probing
-blockdev my-image.qcow2,id=ide0-hd0
# create a blockdev using probing without relying on implicit keys and
allowing unsafe probing
-blockdev
format.probe.unsafe=on,format.probe.protocol.file.filename=my-image.qcow2,id=ide0-hd0
# create a blockdev using qcow2 over NBD with a qed backing file
-blockdev format.qcow2.protocol.nbd={hostname=localhost,port=1025},\
format.qcow2.backing-file.format.qed.protocol.nbd={hostname=localhost,port=1026},\
id=ide0-hd0
It looks less awkward in config file format:
[blockdev]
id = "ide0-hd0"
format.qcow2.protocol.nbd.hostname = localhost
format.qcow2.protocol.nbd.port = 1025
format.qcow2.backing-file.format.qed.protocol.nbd.hostname = localhost
format.qcow2.backing-file.format.qed.protocol.nbd.port = 1026
And with a syntax this complex, errors are important. Here are some
examples of Error messages:
#./test-qcfg format.qcow2.file.filename="image.img",id=ide0-hd0
-blockdev: Parameter 'format.qcow2.protocol' is missing
# ./test-qcfg
format.qcow2.protocol.file.filename="image.img",format.qcow3.backing-file.format.qcow2.protocol.file.filename="foo.img",id=ide0-hd0
-blockdev: Invalid parameter
'format.qcow3.backing-file.format.qcow2.protocol.file.filename'
#./test-qcfg
format.qcow2.protocol.file.filename="image.img",id=ide0-hd0,cache=no-thank-you
-blockdev: Enum 'cache' with value 'no-thank-you' is invalid for type
'BlockdevCacheSetting'
I think the tricky part is that the valid fields depend on the block
driver. qcow2 wants another BlockDriverState as its image file; file
wants a file name; vvfat wants a directory name, FAT type and disk type;
and NBD wants a host name and a port, except if it uses a UNIX socket.
Yes, it's all handled with a new union type.
This is probably the most complex thing you can get, so I think it would
make a better example than a VNC configuration.
Yup, that's been what I've been using to prototype all of this. I
didn't it in the mail because it's rather complex :-)
Regards,
Anthony Liguori
Kevin
Re: [Qemu-devel] [RFC] QCFG: a new mechanism to replace QemuOpts and option handling, Markus Armbruster, 2011/03/17