Google Summer of Code 2010/QMP: Difference between revisions

From QEMU
No edit summary
No edit summary
Line 39: Line 39:
=== do_savevm/do_loadvm ===
=== do_savevm/do_loadvm ===
TODO:
TODO:
* Code a new patch based on Luiz and Kevin's chat.
* Get do_savevm() UUID stuff more in shape for sending an RFC.
* Get do_savevm() UUID stuff more in shape for sending an RFC.
* Update do_loadvm() do load an snapshot using an UUID.
* Update do_loadvm() do load an snapshot using an UUID.
Line 44: Line 45:


== Day by Day ==
== Day by Day ==
=== June 22 ===
* Chat with mentor and Kevin Wolf about the patch I've sent to update the monitor output. Need to code new version.
* Log from the chat so I don't forget what I have to do:
<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
* Coded the query-netdev specification. I'm facing some difficulties and ended the day stuck with tap/sndbuf. It is very OS dependent, no way to check if its OK, a lot of stub functions.
* Updated the examples in the query-netdev protocol spec.


=== June 21 ===
=== June 21 ===

Revision as of 13:40, 23 June 2010

Summary

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

Team

Student

Mentor

Subsystems being worked on

Handler Status Who I should CC
do_info_netdev Protocol defined. Updating the previous patches to comply. 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>
do_info_qdm Need to confirm libvirt's needs/priority about this.

do_info_netdev

TODO:

  • Coding the support for the protocol.

do_savevm/do_loadvm

TODO:

  • Code a new patch based on Luiz and Kevin's chat.
  • Get do_savevm() UUID stuff more in shape for sending an RFC.
  • Update do_loadvm() do load an snapshot using an UUID.
  • Update do_delvm() do delete an snapshot using an UUID.

Day by Day

June 22

  • Chat with mentor and Kevin Wolf about the patch I've sent to update the monitor output. Need to code new version.
  • Log from the chat so I don't forget what I have to do:
<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
  • Coded the query-netdev specification. I'm facing some difficulties and ended the day stuck with tap/sndbuf. It is very OS dependent, no way to check if its OK, a lot of stub functions.
  • Updated the examples in the query-netdev protocol spec.

June 21

  • After discussing with other devs on qemu-devel, the draft sent on June 18 was updated and resent do the list: http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg02629.html
  • What has changed:
    • Got rid of vlans, a separate command for them will be created if needed
    • Removed socket as a type (it is used to connect vlans)
    • 'script', 'downscript' and 'vhostfd' are now optional when type is 'tap'
    • Reworded the explanation of 'peer'

June 18

June 17

June 16

  • Got mentor's review from query-netdev.
  • Some back and forth about the last monitor patch, coded a new version.

June 15

June 11

  • Coded an small patch that updates the monitor output to show snapshot information of all supported devices.

June 10

June 9

  • Coded and tested the new query-netdev.
  • Wrestled with git rebase, now I understand it. How could I leave without it?

June 8

  • Sent to qemu-devel the RFC for the new QMP command query-snapshots.

June 7

  • A lot of back and forth over email from all sorts of people about query-netdevices and some chat with Anthony on IRC.
  • Resolutions about it:
    • Rename the command to query-netdev
    • Show only the backend information (user, tap, socket, vde)
    • Guest devices (frontend) are already available via info qtree, don't need to show them.

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"
           },
        },

June 4

  • Chat with mentor and Kevin Wolf.
  • Sent to qemu-devel the RFC for the new QMP command query-netdevices. I will wait for feedback before coding. http://www.mail-archive.com/qemu-devel@nongnu.org/msg34634.html
  • Sent to mentor the RFC for the new QMP command query-snapshots before sending to qemu-devel. This might avoid some noise in the list.
  • Lesson learned: compile qemu without --enable-debug before submitting anything, damn it! The do_savevm() v3 patch had an warning that was not caught by me and latter on caught by Kevin Wolf: http://www.mail-archive.com/qemu-devel@nongnu.org/msg34707.html After a few minutes chatting with him on IRC we figured that --enable-debug disables -O2, then some warnings could not be seen. Fixed and resent v4. I hope that know this think gets merged :-D

June 3

May 31 thru June 2

  • Studied and toke some exams. Classes are over :-D

May 29

May 28

  • Some chat with mentor.

May 27

  • Got mentor's review about last do_info_netdevices(). Will begin fixing things after finishing some more do_savevm/do_loadvm work.
  • do_info_snapshots() now displays snapshot information of all devices.
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

May 26

  • Got parent snapshot saving working. Using global variable, not sure if it is best option.
  • Updated bdrv_snapshot_dump() to properly show the UUID information. It looks really big.
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
  • Fixed extra_data_size offset handling when loading a qcow2 image with an empty extra area.

May 22

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.

May 21

  • Got saving UUID information in a qcow2 file, using QCowSnapshot->extra_data_size and displaying it on 'info snapshots'. It seams we can have snapshot inheritance without breaking the file format or any old code. Now time to actually save the inheritance.

Helpful references:

May 19

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.

From late March thru May 18

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:

Retrieved from "https://wiki.qemu.org/index.php?title=Google_Summer_of_Code_2010/QMP&oldid=383"