[libvirt] [PATCH v3 0/4] command line fd passing using fd sets
This series adds command line file descriptor passing support via a new -add-fd option. This is a follow-on to the existing QMP fd passing support provided in the following patch series: comments.gmane.org/gmane.comp.emulators.qemu/165463 The new -add-fd option is designed to mirror the add-fd QMP option as much as possible. Corey Bryant (4): monitor: Allow add-fd to any specified fd set monitor: Enable adding an inherited fd to an fd set monitor: Prevent removing fd from set during init qemu-config: Add new -add-fd command line option monitor.c | 142 +++++++++++++++++++++++++++++++++---------------------- monitor.h | 3 ++ qapi-schema.json | 2 +- qemu-config.c | 22 +++++++++ qemu-options.hx | 36 ++++++++++++++ vl.c | 72 ++++++++++++++++++++++++++++ 6 files changed, 220 insertions(+), 57 deletions(-) -- 1.7.11.4
On 10/16/2012 11:51 AM, Corey Bryant wrote:
This series adds command line file descriptor passing support via a new -add-fd option. This is a follow-on to the existing QMP fd passing support provided in the following patch series: comments.gmane.org/gmane.comp.emulators.qemu/165463
The new -add-fd option is designed to mirror the add-fd QMP option as much as possible.
Before this can still be useful in libvirt, we need a way to pass in fds for all of a backing chain, and not just the top-level. And you can't argue that libvirt should be temporarily rewriting qcow2 metadata to stick in names such as /dev/fdset/1 into the metadata. Consider the case of: /- guest1.img base.img <- snap1.img < \- guest2.img snap1.img is supposed to be read-only, and there's no guarantee that /dev/fdset/1 will be available for both guest1 and guest2 to rewrite the header. Thus, I argue that snap1.img must encode the name base.img in its metadata, but that we must also have a way to tell qemu to open /dev/fdset/1 instead of trying open(base.img) in order to get the open fd for base.img. But even though we are still not at a point where the overall feature is useful, I can at least review these patches for getting us incrementally closer to our goal. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 10/16/2012 03:26 PM, Eric Blake wrote:
On 10/16/2012 11:51 AM, Corey Bryant wrote:
This series adds command line file descriptor passing support via a new -add-fd option. This is a follow-on to the existing QMP fd passing support provided in the following patch series: comments.gmane.org/gmane.comp.emulators.qemu/165463
The new -add-fd option is designed to mirror the add-fd QMP option as much as possible.
Before this can still be useful in libvirt, we need a way to pass in fds for all of a backing chain, and not just the top-level. And you can't argue that libvirt should be temporarily rewriting qcow2 metadata to stick in names such as /dev/fdset/1 into the metadata. Consider the case of:
/- guest1.img base.img <- snap1.img < \- guest2.img
snap1.img is supposed to be read-only, and there's no guarantee that /dev/fdset/1 will be available for both guest1 and guest2 to rewrite the header. Thus, I argue that snap1.img must encode the name base.img in its metadata, but that we must also have a way to tell qemu to open /dev/fdset/1 instead of trying open(base.img) in order to get the open fd for base.img.
I think the -blockdev command is going to solve this. Stefan, do you have any information on the -blockdev support?
But even though we are still not at a point where the overall feature is useful, I can at least review these patches for getting us incrementally closer to our goal.
Thanks Eric. -- Regards, Corey Bryant
participants (2)
-
Corey Bryant -
Eric Blake