|
From: | Avi Kivity |
Subject: | [Qemu-devel] Re: [RFC] QMP: Introduce query-netdevices documentation |
Date: | Mon, 07 Jun 2010 16:39:07 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 |
On 06/07/2010 03:57 PM, Miguel Di Ciurcio Filho wrote:
On Sun, Jun 6, 2010 at 12:50 PM, Avi Kivity<address@hidden> wrote:+Each json-object contain the following: + +- "device": device name (json-string) +- "vlan": only present if the device is attached to a VLAN (json-int) +- "info": json-object containing the following: + - "model": type of the device (json-string) + - Possible values: "tap", "socket", "xen", "slirp", "dump", + "vde", "ne2k_pci", "i82551", "i82557b", + "i82559er", "rtl8139", "e1000", "pcnet", + "virtio", "dp83932", "lan9118", "mcf_fec", + "xilinx-ethlite", "lance", "stellaris", + "smc91c111", "ne2k_isa", "mv88w8618", + "mipsnet", "fseth", "dp83932", "usb"This casts the vlan model into concrete. I thought we wanted to move away from it? Instead have separate entries for host and guest devices.The vlan attribute is optional. In this case, it is a vlan inside the context of the VM. I've searched the archives and I've found some references about the confusion about real VLANs (802.1Q) and QEMU's vlans. Correct me if I'm wrong, but I suppose they are completely different animals.
Right. I'm talking about the qemu internal vlans.
When you say separate entries for host and guest devices, you mean something like this: $ qemu -netdev tap,id=tap0 -device e1000,netdev=tap0 This makes a 1:1 relation. So clearly tap0 is a host device, e1000.0 will be a guest device, and they are connected.
Yes. I'd want separate queries for each, or perhaps a single query that returns
{ 'hostdev': some-object-with-host-device-properties-only, 'nic': some-object-that-describes-the-guest-nic }
$ qemu -net tap,ifname=tap0 -net nic,model=e1000 This glues the two devices into a vlan inside the VM. Do you mean that this second model should be deprecated?
I think it is. It doesn't play well with acceleration technologies like vhost that want a 1:1 relationship.
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |