qemu has many commands attached to the monitor interface that are currently inaccessible over QMP (QEMU Machine Protocol). I intend to give continuity to this effort, converting the remaining functions to the QObject API. While doing this conversion, the QObject API can be updated to improve its functionality when required.
More details about the protocol: http://www.linux-kvm.org/page/MonitorProtocol
The query-netdev command is used to show information about the current backend network devices assigned to a VM.
The query-available-devices describes the capabilities of all devices registered with qdev.
based on previous code sent to the list, it is an update to the query-version command.
Bugs found:
Cleanup tries:
| Handler | Status | Who I should CC |
|---|---|---|
| do_info_netdev | Done. | Markus Armbruster <armbru@redhat.com> |
| do_savevm/do_loadvm | Sending small patches, not related to QMP yet. | Kevin Wolf <kwolf@redhat.com>, Juan Quintela <quintela@redhat.com>, Christoph Hellwig <hch@infradead.org> |
| query-available-devices | Done. | Daniel P. Berrange <barrange@redhat.com> |
| query-version | Pending review. | Daniel P. Berrange <barrange@redhat.com> |
TODO:
TODO:
TODO:
TODO:
<miguelzinho> luiz, could you take a look at your reply? http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02398.html <miguelzinho> luiz, is there anything blocking/must further discuss about that patch? <luiz___> miguelzinho: my concern is that we're degrading the usability of the this command, as it can confuse users. But I don't how to solve that <miguelzinho> luiz___, OTOH, the user is getting more information about the VM. I'm not sure that the new output is confusing. <kwolf> miguelzinho: But the common case is that all images have the same snapshots anyway, right? <kwolf> So maybe printing lots of information when it's really the same for each image, could be considered confusing indeed <miguelzinho> kwolf, how about an image that was added latter on and don't have snapshots in it? <kwolf> miguelzinho: I don't say that it can't happen, but is it really the common case? <miguelzinho> kwolf, yeah, not that common <kwolf> However, with the current implementation I think it can happen that info snapshots shows snapshots that you can't really load. That's not optimal either. <miguelzinho> kwolf, that is exactly what I'm trying do improve <kwolf> I know <kwolf> Maybe we can merge everything into one list? <kwolf> And add a column that says if a snapshot can be loaded (i.e. it's present on all images)? <miguelzinho> collect the available and valid snapshots and summarize the output? <kwolf> Something like this, yes <miguelzinho> Sounds better, indeed <kwolf> We should include the snapshots that exist only on some of the images, too, because they would be overwritten by savevm <kwolf> And mark them clearly <miguelzinho> you mean snapshots that exist on all the images? <miguelzinho> the ones that are not available on all the images must be marked somehow, so savevm don't try do load those. <kwolf> s/load/overwrite/ or s/savevm/loadvm/? <kwolf> But I think we're talking about the same anyway <miguelzinho> both, hehehe, my bad <miguelzinho> kwolf, I will send a new version more towards we have agreed here. <kwolf> Sounds good. luiz___, do you agree so far? <luiz___> yeah, looks good <luiz___> miguelzinho: what happens if the user tries to load a broken snapshot today? <miguelzinho> luiz___, first device has snapshots 1 2 and 3, second device has snapshots 1 and 2 <miguelzinho> luiz___, loadvm 3 <miguelzinho> luiz___, first device "goes" to snapshot 3, second device fails, there is no 3 there <miguelzinho> luiz___, I'm not sure, but the VM stays running anyway <kwolf> miguelzinho: Don't we fail immediately since your first patch? <miguelzinho> kwolf, only if the device does not support snapshots at all <kwolf> I see <kwolf> So that's something else to improve <miguelzinho> luiz___, yep, VM keeps running. savevm.c:load_vmstate():1793 <luiz___> miguelzinho: as kwolf says, would be nice to improve that too
Result:
-> { "execute": "query-netdev" }
<- {
"return": [
{
"device": "tap.0",
"vlan": 0,
"type": "tap",
"info": {
"script": "/etc/qemu-ifup",
"downscript": "/etc/qemu-ifdown",
"ifname": "tap0",
},
{
"device": "user.0",
"type": "user",
"peer": "e1000.0",
"info": {
"net": "10.0.2.0",
"netmask": "255.255.255.0"
},
},
qemu -hda ../a.qcow2 -hdb ../b.qcow2
QEMU 0.12.50 monitor - type 'help' for more information (qemu) info snapshots Snapshot list from ide0-hd0: ID TAG VM SIZE DATE VM CLOCK UUID PARENT UUID 1 1.5M 2010-05-27 12:24:45 00:00:05.640 f89787ea-c39e-4531-90cc-19d73abbc50e 00000000-0000-0000-0000-000000000000 2 1.5M 2010-05-27 12:24:52 00:00:12.258 4fb1f028-febb-464a-8e61-8abdfde9adc8 f89787ea-c39e-4531-90cc-19d73abbc50e 3 1.5M 2010-05-27 12:25:05 00:00:24.921 faeb873c-f3fd-40ab-97de-67c6f12fd5ff 4fb1f028-febb-464a-8e61-8abdfde9adc8 Snapshot list from ide0-hd1: ID TAG VM SIZE DATE VM CLOCK UUID PARENT UUID 1 0 2010-05-27 11:33:11 00:00:02.781 8f5d24a0-9a92-4650-8b56-babaa7790700 00000000-0000-0000-0000-000000000000 2 0 2010-05-27 11:53:39 00:00:12.073 9e471508-f9d9-46d6-815b-2c25b15152f3 00000000-0000-0000-0000-000000000000 3 0 2010-05-27 11:53:40 00:00:12.867 c5a75fd0-2cea-433b-bd21-37025dff3cbd 9e471508-f9d9-46d6-815b-2c25b15152f3
QEMU 0.12.50 monitor - type 'help' for more information (qemu) info snapshots Snapshot devices: ide0-hd0 Snapshot list (from ide0-hd0): ID TAG VM SIZE DATE VM CLOCK UUID PARENT UUID 1 1.5M 2010-05-26 21:51:02 00:00:03.263 ce7cb390-f5d8-4633-9c83-e2c651d5aecf 00000000-0000-0000-0000-000000000000 2 1.5M 2010-05-26 21:51:09 00:00:08.844 1f80df59-470e-4de6-a0a1-cf6a2a721e0e ce7cb390-f5d8-4633-9c83-e2c651d5aecf 3 1.5M 2010-05-26 21:51:24 00:00:23.274 63ce278d-26fe-4790-ab13-6643bf9ddf90 1f80df59-470e-4de6-a0a1-cf6a2a721e0e 4 1.5M 2010-05-26 21:53:17 00:00:03.595 0199cdd9-1c8f-4c53-b711-684110078960 00000000-0000-0000-0000-000000000000 5 1.5M 2010-05-26 21:53:25 00:00:10.750 6b753c35-8939-477b-a7f5-10ff45e34e93 0199cdd9-1c8f-4c53-b711-684110078960 6 1.5M 2010-05-26 21:53:27 00:00:12.071 7a127832-7259-4b41-9400-64804b755b0c 6b753c35-8939-477b-a7f5-10ff45e34e93
I was actually not saving anything. After closing the VM the UUID information was not written to disk. After hours pulling some hair I figured it as a typo and a wrong offset calculation when saving the QCowSnapshotHeader to disk.
Helpful references:
After talking with Chris Lalancette from libvirt, we need snapshot inheritance in qemu, before converting do_savevm/do_loadvm to QMP. I've analyzed the code and I there is some hairy things to do. There are more people working on this code, so I will try to get a go before starting coding.
Sent patch v4 to qemu-devel.
We were struggling to get the output of 'info network' exactly the same and juggling to work around the lack of a pattern when formatting VLANClientState.info_str. So we decided to add a new and clean command, and leave 'info network' as it is.
This is the v4 patch:
http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg01567.html
The work on this area has begun late March, as a test if I could do something in GSoC. And here I am :-D There were a lot of interactions before the v4 patch.
Previous attempts: