qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Miguel Di Ciurcio Filho <miguel.filho@gmail.com>
Cc: armbru@redhat.com, jan.kiszka@siemens.com, qemu-devel@nongnu.org,
	avi@redhat.com
Subject: [Qemu-devel] Re: [PATCH v2] QMP: Introduce the documentation for query-netdev and info netdev
Date: Mon, 21 Jun 2010 11:42:59 -0300	[thread overview]
Message-ID: <20100621114259.13e615ee@redhat.com> (raw)
In-Reply-To: <1276878387-9489-1-git-send-email-miguel.filho@gmail.com>

On Fri, 18 Jun 2010 13:26:27 -0300
Miguel Di Ciurcio Filho <miguel.filho@gmail.com> wrote:

> These commands show the information about active backend network devices.
> 
> Signed-off-by: Miguel Di Ciurcio Filho <miguel.filho@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)

 There were some talking about changing this to 'device. Jan, Markus?

> +- "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)
> +- "info": json-object containing the configuration information about the device.
> +        - When "type" is "tap", the following values might be available:
> +            - "fd": available if connected to an already opened TAP interface
> +              (json-int, optional)
> +            - "script": path to an script used to configure the interface, if
> +              the value is "no" then no script is used. (json-string, only
> +              present if "fd" is not present)

 What if the script is called "no"? Better not to include the key in this case.

> +            - "downscript": path to an script used to deconfigure the interface,
> +              if the value is "no" then no script is used. (json-string, only
> +              present if "fd" is not present)

 Same as above.

> +            - "ifname": name of the attached host interface (json-string, only
> +              present if "fd" is not present)
> +            - "vhost": vhost acceleration status, true if enabled, false
> +              otherwise (json-boolean)
> +            - "vnet_hdr": true if the IFF_VNET_HDR flag must be set, false 
> +              otherwise (json-boolean)

 Why is vnet_hdr important?

> +            - "vhostfd": positive number if the device is connected to an
> +              already opened vhost net device, -1 otherwise (json-int)

 Making the key option is better, IMO.

> +            - "sndbuf": send buffer size, in bytes (json-int)
> +        - When "type" is "vde", the following values might be available:
> +            - "sock": path to the VDE listening socket (json-string)
> +            - "port": port number connected to virtual switch (json-int)
> +            - "group": group name (json-string)
> +            - "mode": permission mode, in octal (json-int)
> +        - When "type" is "user", the following values might be available:
> +            - "hostname": client hostname reported by the builtin DHCP server,
> +              (json-string, optional)
> +            - "restrict": true if guest is isolated from the host,
> +              false otherwise (json-boolean)
> +            - "net": network address (json-string)
> +            - "netmask": netmask (json-string)
> +            - "host": guest-visible address of the host (json-string)
> +            - "tftp": root directory of the built-in TFTP server (json-string,
> +              optional)
> +            - "bootfile": BOOTP filename (json-string, optional)
> +            - "dhcpstart": the first of the 16 IPs the built-in DHCP server can
> +              assign (json-string)
> +            - "dns": guest-visible address of the virtual nameserver
> +              (json-string)
> +            - "smb": root directory of the built-in SMB server (json-string,
> +              optional)
> +            - "smbserver": IP address of the built-in SMB server (json-string,
> +              optional)
> +            - "hostfwd": guest port number to forward incoming TCP or UDP
> +              connections (json-int, optional)
> +            - "guestfwd": IP address and port to forward guest TCP connections
> +              (json-int, optional)
> +        - When "type" is "socket", the following values might be available:
> +            - "host": IP address (json-string)
> +            - "service": port number (json-int)
> +            - "family": IP version, possible values "ipv4" or "ipv6"
> +              (json-string)
> +            - "server": true if the socket is receiving incoming connections,
> +              false otherwise (json-boolean)
> +
> +Example:
> +
> +-> { "execute": "query-netdev" }
> +<- {
> +      "return": [
> +         {
> +            "id": "tap.0",
> +            "type": "tap",
> +            "vlan": 0,
> +            "info": {
> +               "script": "/etc/qemu-ifup",
> +               "downscript": "/etc/qemu-ifdown",
> +               "ifname": "tap0",
> +               "vhost": true
> +            },
> +         },
> +         {
> +            "id": "user.0",
> +            "type": "user",
> +            "peer": "e1000.0",
> +            "info": {
> +               "net": "10.0.2.0",
> +               "netmask": "255.255.255.0"
> +            },
> +         },
> +      ]
> +   }
> +
> +EQMP
> +
> +STEXI
>  @item info chardev
>  show the character devices
>  ETEXI

  parent reply	other threads:[~2010-06-21 14:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-18 16:26 [Qemu-devel] [PATCH v2] QMP: Introduce the documentation for query-netdev and info netdev Miguel Di Ciurcio Filho
2010-06-18 20:28 ` Anthony Liguori
2010-06-18 20:40   ` Luiz Capitulino
2010-06-21  8:27     ` Markus Armbruster
2010-06-21 14:34       ` Luiz Capitulino
2010-06-18 21:15   ` Miguel Di Ciurcio Filho
2010-06-18 21:20     ` Anthony Liguori
2010-06-21  8:23   ` Markus Armbruster
2010-06-21 14:42 ` Luiz Capitulino [this message]
2010-06-21 14:47   ` [Qemu-devel] " Jan Kiszka
2010-06-21 16:44     ` Markus Armbruster
2010-06-22  8:50       ` Jan Kiszka
2010-06-22 11:53         ` Markus Armbruster
2010-06-21 17:58   ` Miguel Di Ciurcio Filho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100621114259.13e615ee@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=armbru@redhat.com \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=miguel.filho@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).