On Fri, Jun 18, 2010 at 5:28 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 06/18/2010 11:26 AM, Miguel Di Ciurcio Filho wrote: >> >> These commands show the information about active backend network devices. >> >> Signed-off-by: Miguel Di Ciurcio Filho<miguel.fi...@gmail.com> >> --- >> qemu-monitor.hx | 105 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 105 insertions(+), 0 deletions(-) >> >> diff --git a/qemu-monitor.hx b/qemu-monitor.hx >> index 9f62b94..8fc5ed6 100644 >> --- a/qemu-monitor.hx >> +++ b/qemu-monitor.hx >> @@ -1674,6 +1674,111 @@ show the various VLANs and the associated devices >> ETEXI >> >> STEXI >> +...@item info netdev >> +show information about the current backend network devices >> +ETEXI >> +SQMP >> +query-netdev >> +------------ >> + >> +Each device is represented by a json-object. The returned value is a >> json-array >> +of all devices. >> + >> +Each json-object contains the following: >> + >> +- "id": the device's ID, must be unique (json-string) >> +- "type": device type (json-string) >> + - Possible values: "tap", "user", "vde", "socket" >> +- "vlan": QEMU's internal vlan identification. Only present if the device >> is >> + attached to a VLAN (json-int, optional) >> +- "peer": ID of the frontend device when on a 1:1 relationship >> (json-string, >> + optional) >> > > I think we should only return items with a valid peer property and drop > anything attached to vlans. The current info network already provides vlan > information. >
We need a strong compromise that sometime in the future, the qemu "vlan" concept will be removed, deprecated, or something like that. Otherwise we will end up with QMP not exporting networking configuration that can be setup by a user or management software. Previous discussions about the "vlan" removal: http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00947.html Will it break for some people? Yes, but the current status quo is not good. Interconnecting virtual network devices should be done by software like VDE or Open vSwitch on the host. I think even devices without a peer must be listed. After a netdev_add command, there is going to be no way to verify that the netdev is there, only after adding a guest NIC associated with the netdev if we put a restriction like that. Regards, Miguel