Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Stop using QEMU's human monitor #1542

Open
apoikos opened this issue Dec 24, 2020 · 5 comments · May be fixed by #1667
Open

Stop using QEMU's human monitor #1542

apoikos opened this issue Dec 24, 2020 · 5 comments · May be fixed by #1667
Assignees
@rbott
Milestone
Release 3.1

Comments

@apoikos
Copy link
Member

apoikos commented Dec 24, 2020

Right now we are using a mix of HMP and QMP calls to QEMU, depending on the feature. This adds complexity to the code and confusion to contributors over picking which method to use. Since QMP is supposed to be the machine interface of QEMU, it makes sense to switch everything over to it.

We currently use the human monitor for the following operations:

  • To get CPU thread information (info cpus, QMP command: query-cpus, since 0.14)
  • To set the VNC password (change vnc password, QMP command: change with arguments, since 0.14)
  • To hot-add drives (drive_add, QMP command: blockdev-add, since 2.9)
  • To hot-remove drives (drive_del, QMP command: blockdev-del, since 2.9)
  • To signal shutdown to the guest (system_powerdown, QMP command: system_powerdown, since 0.14)
  • To balloon the guest memory (balloon, QMP command: balloon, since 0.14)
  • To get version information (info version, QMP command: query-version, since 0.14)

(The information on the QMP commands can be found under qapi/ in the QEMU source)

Migrating all these calls to QMP bumps our compatibility to QEMU >= 2.9, which was released in 2017. Since we are anyway no longer compatible with Xenial and Stretch because of Python 3/GHC, there's nothing to lose here.
@apoikos apoikos added this to the Release 3.1 milestone Dec 24, 2020
@rbott
Copy link
Member

rbott commented Dec 24, 2020 •
edited

I entirely agree. I will try to tackle some of these, since I have already done some work on this end in the past months. I'll update this issue when I start working on any of the above tasks.

@rbott rbott self-assigned this Dec 24, 2020
@rbott rbott mentioned this issue Dec 27, 2020
Merged
@rbott rbott linked a pull request Dec 27, 2020 that will close this issue
KVM: shift info queries from human monitor to QMP #1546
Merged
@rbott rbott removed a link to a pull request Dec 27, 2020
KVM: shift info queries from human monitor to QMP #1546
Merged
@gedia gedia mentioned this issue Jan 18, 2021
Merged
@rbott
Copy link
Member

rbott commented Apr 20, 2021

Parts if this PR have been addressed by #1546 (and bumped the minimum QEMU version to 2.12). However, there is still some work to do :-)

@rbott rbott mentioned this issue Jan 23, 2022
Closed
@rbott rbott mentioned this issue Mar 5, 2022
Merged
@rbott
Copy link
Member

rbott commented Mar 5, 2022

@saschalucas @apoikos there is now only the block device part left to address. However, this seems to a bit more complicated: according to this slidedeck blockdev-add|del in QMP do not directly correspond to drive_del|add in HMP and especially not to the -drive commandline parameter of QEMU.

The latter is deprecated and should be replaced by the -blockdev parameter (which in turn is in line with blockdev-add).

So I guess we need to entirely replace the -drive/drive_add/drive_del combination. AFAICT this also makes the disk_cache parameter obsolete as it does not exist any more in this context (other block device related parameters like aio, discard etc. are still available).

Replacing the entire code is one thing, taking care of migrating between -drive and -blockdev is probably going to take some more consideration.

I think this is a worthwhile feature for 3.1 but will probably also bump version requirements for QEMU quite a bit. -blockdev has been present since 2.9 but was apparently declared rather unstable in early versions. This change will require some extensive testing to see how well our use case works with older releases.

@apoikos
Copy link
Member Author

apoikos commented Mar 13, 2022

@rbott QEMU 2.9 was ages ago, I think it's perfectly fine to restrict ourselves to QEMU >= 3 (or even 4).

@apoikos
Copy link
Member Author

apoikos commented Mar 13, 2022

@rbott: digging a bit into QEMU history, QMP blockdev-add and blockdev-del have been stable as of QEMU 2.9 (see qemu/qemu@79b7a77). -blockdev is using qmp_blockdev_add internally (see qemu/qemu@42e5f39) and was also part of 2.9. In short, it looks like 2.9 is all we need for proper QMP blockdev support.

Changing the code should be straightforward once we decide to only use QMP, we just need to check if there's anything affecting running instances and live migrations.

@rbott rbott linked a pull request Apr 6, 2022 that will close this issue
Open
14 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rbott rbott

Labels
None yet
Projects
None yet
Milestone
Release 3.1
Development

Successfully merging a pull request may close this issue.

KVM: replace -drive by -blockdev and make HMP obsolete rbott/ganeti
2 participants
@apoikos @rbott