On 01/29/2013 03:23 AM, Daniel P. Berrange wrote:
On Mon, Jan 28, 2013 at 02:54:28PM -0700, Eric Blake wrote:
> On 01/26/2013 09:17 PM, Stefan Berger wrote:
>>> In a subsequent patch we now test inside that function whether the new
>>> command line parameter is available using the capability (from another
>>> patch) and create fd=/dev/set/10 and vhostfd=/dev/set/20 respectively
>>> *and* already add "-add-fd set=10,fd=21" and "-add-fd
set=20,fd=23" to
>>> virCommand using the functions I already posted (as the lowest layer).
>>>
>>> Would it be that simple, or do we need to add more parameters to
>>> -add-fd set=10,fd=21,xyz under certain circumstances?
>
> Ideally, we'd also want to use the opaque parameter of each -add-fd
> call, so that when we later use QMP commands to query what fdsets exist,
> the opaque parameter can tell us what filenames we passed in (it makes
> bookkeeping easier if you know that fd 5 was tied to /dev/tpm, compared
> to just knowing that it is an open fd but not what it came from).
That implies that you trust the output from QEMU monitor commands
to be telling you the truth. We can't do that, so IMHO we can't
rely on the 'opaque' parameter.
Fair enough - libvirt will have to track in vm->priv anything that it
needs for reconstructing state, even across libvirtd restarts. Still,
we _ought_ to populate the opaque member with useful information, so
that debugging is easier (that is, while libvirt can't rely on
query-fdsets, a developer using 'virsh qemu-monitor-command' on a
trusted guest certainly should be able to).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org