Re: [Qemu-devel] using -net dump with tap networking
Paolo Bonzini pbonz...@redhat.com writes: Il 21/02/2013 15:41, Markus Armbruster ha scritto: Trouble is the user interface is as confusing as ever. Worse, in a way, because we now have to explain how vlan and the hubport netdev relate. Permit me a brief rant. Have you read the manual page on -netdev and -net recently? Have you tried to explain setting up QEMU networking to a neophyte? Were you able to keep a straight face? If yes, congrats, you got a great future ahead of you. We have so many ways to do the same thing, complicating our docs enormously. Just one of them makes sense for almost all uses, but I doubt mortal users could guess which one just from the docs. Can we do for the docs what Stefan did for the code, i.e. get vlans out of the way? Specifically, what's missing to let us deprecate -net completely? Less important: the fact that -net dump is quite useful and requires vlans. Let me rephrase: dumping network traffic is quite useful, and our current way to do that from within QEMU requires vlans. The dump vlan client is neither a net frontend nor a net backend, it's a passive listener. Could also be viewed as special case of a filter that happens not to change anything. If it's the only useful listener or filter, we could just special-case it and be done. If not, we need a way to attach listeners to the 1:1 netdev connections, or turn it in a chain with filters as interior nodes. (-net socket has some usecases too: -net bridge helps placing a VM's network on a bridge, but adding a bridge still requires root privileges). -netdev socket and -netdev bridge don't cut it? More important: the fact that qdev and -device really only works for ISA and PCI devices. Boards whose NICs are sysbus devices can only add networking with -net nic. To be more precise: -device currently works only for devices on pluggable buses. Anything you could plug on a physical machine should be on a pluggable bus (whether we implemented plugging is another question). Anything you couldn't plug on a physical machine must be soldered onto the board. Boards often come in a few flavours with different onboard devices. Virtual boards tend to sprout more flavours. Because of that, thinking in board options you can combine is often more convenient than having a finite number of board variants. QOM will hopefully enable us to stitch devices together without the need for buses. But we're not there, yet. When we are, we still have to bridge the gap from interface suitable for building machines from components to nice command line interface for customizing machines. So, I quite agree that we need a way to configure board options. Our current way to do that for NICs is multiplexed into -net as -net nic. -net nic is quite unlike the other -net: it doesn't create a vlan client, it asks the board to create a NIC device. Parameter model lets you ask for a specific one. Boards can do what they want with these requests. Some boards don't support NICs and simply ignore these requests (generic code attempts to detect that and warn). Others treat models they don't know as fatal error. Some boards create exactly the NICs you asked for. Others create exactly their onboard NICs, whether you asked for them or not (asking is merely a way to supply configuration parameters). Most (all?) boards can tell you what models they support (-net nic,model=help), but some lie, e.g. PCs neglect to mention model ne2k_isa. Boards supporting PCI generally recognize a few common PCI NIC models. But you're better off using -device there, because it gives you access to all device models and options at no extra charge. Well, here's another nice mess you've gotten me into, Stanley! TL;DR: I quite agree that we can't just throw away -net without a replacement. I just think it's a mess, and should be replaced.
Re: [Qemu-devel] using -net dump with tap networking
On 2013-02-22 10:35, Markus Armbruster wrote: (-net socket has some usecases too: -net bridge helps placing a VM's network on a bridge, but adding a bridge still requires root privileges). -netdev socket and -netdev bridge don't cut it? Reminds me: Last time I tried -netdev socket, it was broken. There should be nothing preventing this setup conceptually. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] using -net dump with tap networking
Il 22/02/2013 10:35, Markus Armbruster ha scritto: Paolo Bonzini pbonz...@redhat.com writes: Il 21/02/2013 15:41, Markus Armbruster ha scritto: Trouble is the user interface is as confusing as ever. Worse, in a way, because we now have to explain how vlan and the hubport netdev relate. Permit me a brief rant. Have you read the manual page on -netdev and -net recently? Have you tried to explain setting up QEMU networking to a neophyte? Were you able to keep a straight face? If yes, congrats, you got a great future ahead of you. We have so many ways to do the same thing, complicating our docs enormously. Just one of them makes sense for almost all uses, but I doubt mortal users could guess which one just from the docs. Can we do for the docs what Stefan did for the code, i.e. get vlans out of the way? Specifically, what's missing to let us deprecate -net completely? Less important: the fact that -net dump is quite useful and requires vlans. Let me rephrase: dumping network traffic is quite useful, and our current way to do that from within QEMU requires vlans. The dump vlan client is neither a net frontend nor a net backend, it's a passive listener. Could also be viewed as special case of a filter that happens not to change anything. If it's the only useful listener or filter, we could just special-case it and be done. If not, we need a way to attach listeners to the 1:1 netdev connections, or turn it in a chain with filters as interior nodes. (-net socket has some usecases too: -net bridge helps placing a VM's network on a bridge, but adding a bridge still requires root privileges). -netdev socket and -netdev bridge don't cut it? -netdev bridge works great. If you want to bridge multiple guest NICs on the same socket, however, you need the VLAN mechanism (though actually you can also use -netdev socket,mcast if that works). To be more precise: -device currently works only for devices on pluggable buses. Anything you could plug on a physical machine should be on a pluggable bus (whether we implemented plugging is another question). Anything you couldn't plug on a physical machine must be soldered onto the board. Boards often come in a few flavours with different onboard devices. Virtual boards tend to sprout more flavours. Because of that, thinking in board options you can combine is often more convenient than having a finite number of board variants. QOM will hopefully enable us to stitch devices together without the need for buses. Still, you have to tell the board this is NIC 0, because it is the board logic that knows the MMIO base address of the NICs---not the NIC itself. At least, that's how the authors of embedded ports structure their code (see recent disappearance of sysbus_add_memory; enabling pervasive use of -device would instead require sysbus_mmio_map to disappear!). Paolo So, I quite agree that we need a way to configure board options. Our current way to do that for NICs is multiplexed into -net as -net nic. -net nic is quite unlike the other -net: it doesn't create a vlan client, it asks the board to create a NIC device. Parameter model lets you ask for a specific one. Boards can do what they want with these requests. Some boards don't support NICs and simply ignore these requests (generic code attempts to detect that and warn). Others treat models they don't know as fatal error. Some boards create exactly the NICs you asked for. Others create exactly their onboard NICs, whether you asked for them or not (asking is merely a way to supply configuration parameters). Most (all?) boards can tell you what models they support (-net nic,model=help), but some lie, e.g. PCs neglect to mention model ne2k_isa. Boards supporting PCI generally recognize a few common PCI NIC models. But you're better off using -device there, because it gives you access to all device models and options at no extra charge. Well, here's another nice mess you've gotten me into, Stanley! TL;DR: I quite agree that we can't just throw away -net without a replacement. I just think it's a mess, and should be replaced.
Re: [Qemu-devel] using -net dump with tap networking
Paolo Bonzini pbonz...@redhat.com writes: Il 22/02/2013 10:35, Markus Armbruster ha scritto: Paolo Bonzini pbonz...@redhat.com writes: Il 21/02/2013 15:41, Markus Armbruster ha scritto: Trouble is the user interface is as confusing as ever. Worse, in a way, because we now have to explain how vlan and the hubport netdev relate. Permit me a brief rant. Have you read the manual page on -netdev and -net recently? Have you tried to explain setting up QEMU networking to a neophyte? Were you able to keep a straight face? If yes, congrats, you got a great future ahead of you. We have so many ways to do the same thing, complicating our docs enormously. Just one of them makes sense for almost all uses, but I doubt mortal users could guess which one just from the docs. Can we do for the docs what Stefan did for the code, i.e. get vlans out of the way? Specifically, what's missing to let us deprecate -net completely? Less important: the fact that -net dump is quite useful and requires vlans. Let me rephrase: dumping network traffic is quite useful, and our current way to do that from within QEMU requires vlans. The dump vlan client is neither a net frontend nor a net backend, it's a passive listener. Could also be viewed as special case of a filter that happens not to change anything. If it's the only useful listener or filter, we could just special-case it and be done. If not, we need a way to attach listeners to the 1:1 netdev connections, or turn it in a chain with filters as interior nodes. (-net socket has some usecases too: -net bridge helps placing a VM's network on a bridge, but adding a bridge still requires root privileges). -netdev socket and -netdev bridge don't cut it? -netdev bridge works great. If you want to bridge multiple guest NICs on the same socket, however, you need the VLAN mechanism (though actually you can also use -netdev socket,mcast if that works). I don't mind keeping vlans around for somewhat exotic use cases, now that Stefan restructured the code to get them out of the way. I'm looking for ways to get a similar improvement in the user interface. Right now, qemu(1) mentions vlan first, and netdev second, if at all. Additionally, I'm wondering whether we can further reduce vlan use cases. To be more precise: -device currently works only for devices on pluggable buses. Anything you could plug on a physical machine should be on a pluggable bus (whether we implemented plugging is another question). Anything you couldn't plug on a physical machine must be soldered onto the board. Boards often come in a few flavours with different onboard devices. Virtual boards tend to sprout more flavours. Because of that, thinking in board options you can combine is often more convenient than having a finite number of board variants. QOM will hopefully enable us to stitch devices together without the need for buses. Still, you have to tell the board this is NIC 0, because it is the board logic that knows the MMIO base address of the NICs---not the NIC itself. At least, that's how the authors of embedded ports structure their code (see recent disappearance of sysbus_add_memory; enabling pervasive use of -device would instead require sysbus_mmio_map to disappear!). To be precise: you tell the board how you want NIC 0 configured. My argument is that -net nic is a lousy way to do that. In more detail: So, I quite agree that we need a way to configure board options. Our current way to do that for NICs is multiplexed into -net as -net nic. -net nic is quite unlike the other -net: it doesn't create a vlan client, it asks the board to create a NIC device. Parameter model lets you ask for a specific one. Boards can do what they want with these requests. Some boards don't support NICs and simply ignore these requests (generic code attempts to detect that and warn). Others treat models they don't know as fatal error. Some boards create exactly the NICs you asked for. Others create exactly their onboard NICs, whether you asked for them or not (asking is merely a way to supply configuration parameters). Most (all?) boards can tell you what models they support (-net nic,model=help), but some lie, e.g. PCs neglect to mention model ne2k_isa. Boards supporting PCI generally recognize a few common PCI NIC models. But you're better off using -device there, because it gives you access to all device models and options at no extra charge. Well, here's another nice mess you've gotten me into, Stanley! TL;DR: I quite agree that we can't just throw away -net without a replacement. I just think it's a mess, and should be replaced.
Re: [Qemu-devel] using -net dump with tap networking
Stefan Hajnoczi stefa...@redhat.com writes: On Tue, Feb 19, 2013 at 09:16:56PM +0100, Laszlo Ersek wrote: On 02/19/13 18:50, Markus Armbruster wrote: Your example uses -net to connect additional backends to the hubport. If I understand you correctly, you can't use -netdev to do that. Ignorant question: fundamental reason or just not implemented? In order to take a stab at your question at last: - the two (parallel, opposing) links created in (3) connect two backends, - -netdev does not set the peer link in the backend, so you cannot use that, - -device *would* set the links in both directions, but it's for creating frontends. IOW (3) is unique because it links backend to backend. Right. -netdev doesn't allow you to specify a peer, only NICs (-device) do that. This means there is no way to hook up -netdev dump with -netdev hubport, they are both -netdevs :(. This is why I said it's just playing games with syntax. I don't think it buys us anything in the end. -netdev doesn't let you connect to anything, because it's designed for use with -device, which wants to do the connecting, and wants the connection to be 1:1. And that's fine. Since we rather twist ourselves into knots than dropping a misfeature, we also have vlans. Here's how the two things are related (correct me if I get it wrong). Vlan is older than netdev, so when netdev came around, it got shoehorned into the existing code. Last year, Stefan cleaned that up so that netdevs are the normal case, and vlans are implemented as special netdev hubport. Really nice code improvement, because now the misfeature sits off the side rather than all over the place, complicating things. Trouble is the user interface is as confusing as ever. Worse, in a way, because we now have to explain how vlan and the hubport netdev relate. Permit me a brief rant. Have you read the manual page on -netdev and -net recently? Have you tried to explain setting up QEMU networking to a neophyte? Were you able to keep a straight face? If yes, congrats, you got a great future ahead of you. We have so many ways to do the same thing, complicating our docs enormously. Just one of them makes sense for almost all uses, but I doubt mortal users could guess which one just from the docs. Can we do for the docs what Stefan did for the code, i.e. get vlans out of the way? Specifically, what's missing to let us deprecate -net completely?
Re: [Qemu-devel] using -net dump with tap networking
Il 21/02/2013 15:41, Markus Armbruster ha scritto: Trouble is the user interface is as confusing as ever. Worse, in a way, because we now have to explain how vlan and the hubport netdev relate. Permit me a brief rant. Have you read the manual page on -netdev and -net recently? Have you tried to explain setting up QEMU networking to a neophyte? Were you able to keep a straight face? If yes, congrats, you got a great future ahead of you. We have so many ways to do the same thing, complicating our docs enormously. Just one of them makes sense for almost all uses, but I doubt mortal users could guess which one just from the docs. Can we do for the docs what Stefan did for the code, i.e. get vlans out of the way? Specifically, what's missing to let us deprecate -net completely? Less important: the fact that -net dump is quite useful and requires vlans. (-net socket has some usecases too: -net bridge helps placing a VM's network on a bridge, but adding a bridge still requires root privileges). More important: the fact that qdev and -device really only works for ISA and PCI devices. Boards whose NICs are sysbus devices can only add networking with -net nic. Paolo
Re: [Qemu-devel] using -net dump with tap networking
On Tue, Feb 19, 2013 at 09:16:56PM +0100, Laszlo Ersek wrote: On 02/19/13 18:50, Markus Armbruster wrote: Your example uses -net to connect additional backends to the hubport. If I understand you correctly, you can't use -netdev to do that. Ignorant question: fundamental reason or just not implemented? In order to take a stab at your question at last: - the two (parallel, opposing) links created in (3) connect two backends, - -netdev does not set the peer link in the backend, so you cannot use that, - -device *would* set the links in both directions, but it's for creating frontends. IOW (3) is unique because it links backend to backend. Right. -netdev doesn't allow you to specify a peer, only NICs (-device) do that. This means there is no way to hook up -netdev dump with -netdev hubport, they are both -netdevs :(. This is why I said it's just playing games with syntax. I don't think it buys us anything in the end. Stefan
Re: [Qemu-devel] using -net dump with tap networking
On Tue, Feb 19, 2013 at 06:50:22PM +0100, Markus Armbruster wrote: Stefan Hajnoczi stefa...@gmail.com writes: On Tue, Feb 19, 2013 at 09:53:07AM +0100, Markus Armbruster wrote: Stefan Hajnoczi stefa...@redhat.com writes: On Tue, Feb 19, 2013 at 12:37:28PM +1100, Alexey Kardashevskiy wrote: On 14/02/13 21:26, Stefan Hajnoczi wrote: Now I want to enable network dump. With the old -net syntax I could do that with -net dump but I cannot with the new syntax, tried many variants, none works. What would the correct syntax be for the case above? The question was about new -netdev interface. I would do: qemu-system-ppc64 ... -net tap,ifname=tap0,script=qemu-ifup.sh -net nic,model=virtio -net dump,file=./dump.lan.qemu.virtio The answer is about old -net interface which I know how to use. Does this mean that there is no way to use dump with -netdev tap? It is not possible using just -netdev/-device. The closest you can get is: $ qemu -netdev hubport,hubid=1,id=hubport0 \ -device virtio-net-pci,netdev=hubport0,... \ -net tap,vlan=1,... \ -net dump,vlan=1,... Care to explain briefly how hubport works, and how it's connected to the legacy vlan feature? -netdev hubport instantiates a new port on a hub with vlan number hubid=number. hubport is a -netdev, so it allows you to hook up a NIC to a hub using -netdev/-device syntax. This is just playing games with syntax, we still have a hub in between the virtio-net-pci, tap, and dump devices. I didn't check if the offload features get plumbed through, but I wouldn't count on it. Thanks. Would you mind documenting net backend hubport in qemu-options.hx? Was forgotten in commit f6c874e3. Sure. Stefan
Re: [Qemu-devel] using -net dump with tap networking
On Tue, Feb 19, 2013 at 12:37:28PM +1100, Alexey Kardashevskiy wrote: On 14/02/13 21:26, Stefan Hajnoczi wrote: Now I want to enable network dump. With the old -net syntax I could do that with -net dump but I cannot with the new syntax, tried many variants, none works. What would the correct syntax be for the case above? The question was about new -netdev interface. I would do: qemu-system-ppc64 ... -net tap,ifname=tap0,script=qemu-ifup.sh -net nic,model=virtio -net dump,file=./dump.lan.qemu.virtio The answer is about old -net interface which I know how to use. Does this mean that there is no way to use dump with -netdev tap? It is not possible using just -netdev/-device. The closest you can get is: $ qemu -netdev hubport,hubid=1,id=hubport0 \ -device virtio-net-pci,netdev=hubport0,... \ -net tap,vlan=1,... \ -net dump,vlan=1,... Stefan
Re: [Qemu-devel] using -net dump with tap networking
Stefan Hajnoczi stefa...@redhat.com writes: On Tue, Feb 19, 2013 at 12:37:28PM +1100, Alexey Kardashevskiy wrote: On 14/02/13 21:26, Stefan Hajnoczi wrote: Now I want to enable network dump. With the old -net syntax I could do that with -net dump but I cannot with the new syntax, tried many variants, none works. What would the correct syntax be for the case above? The question was about new -netdev interface. I would do: qemu-system-ppc64 ... -net tap,ifname=tap0,script=qemu-ifup.sh -net nic,model=virtio -net dump,file=./dump.lan.qemu.virtio The answer is about old -net interface which I know how to use. Does this mean that there is no way to use dump with -netdev tap? It is not possible using just -netdev/-device. The closest you can get is: $ qemu -netdev hubport,hubid=1,id=hubport0 \ -device virtio-net-pci,netdev=hubport0,... \ -net tap,vlan=1,... \ -net dump,vlan=1,... Care to explain briefly how hubport works, and how it's connected to the legacy vlan feature?
Re: [Qemu-devel] using -net dump with tap networking
On Tue, Feb 19, 2013 at 09:53:07AM +0100, Markus Armbruster wrote: Stefan Hajnoczi stefa...@redhat.com writes: On Tue, Feb 19, 2013 at 12:37:28PM +1100, Alexey Kardashevskiy wrote: On 14/02/13 21:26, Stefan Hajnoczi wrote: Now I want to enable network dump. With the old -net syntax I could do that with -net dump but I cannot with the new syntax, tried many variants, none works. What would the correct syntax be for the case above? The question was about new -netdev interface. I would do: qemu-system-ppc64 ... -net tap,ifname=tap0,script=qemu-ifup.sh -net nic,model=virtio -net dump,file=./dump.lan.qemu.virtio The answer is about old -net interface which I know how to use. Does this mean that there is no way to use dump with -netdev tap? It is not possible using just -netdev/-device. The closest you can get is: $ qemu -netdev hubport,hubid=1,id=hubport0 \ -device virtio-net-pci,netdev=hubport0,... \ -net tap,vlan=1,... \ -net dump,vlan=1,... Care to explain briefly how hubport works, and how it's connected to the legacy vlan feature? -netdev hubport instantiates a new port on a hub with vlan number hubid=number. hubport is a -netdev, so it allows you to hook up a NIC to a hub using -netdev/-device syntax. This is just playing games with syntax, we still have a hub in between the virtio-net-pci, tap, and dump devices. I didn't check if the offload features get plumbed through, but I wouldn't count on it. Stefan
Re: [Qemu-devel] using -net dump with tap networking
On 02/19/13 09:53, Markus Armbruster wrote: Stefan Hajnoczi stefa...@redhat.com writes: On Tue, Feb 19, 2013 at 12:37:28PM +1100, Alexey Kardashevskiy wrote: On 14/02/13 21:26, Stefan Hajnoczi wrote: Now I want to enable network dump. With the old -net syntax I could do that with -net dump but I cannot with the new syntax, tried many variants, none works. What would the correct syntax be for the case above? The question was about new -netdev interface. I would do: qemu-system-ppc64 ... -net tap,ifname=tap0,script=qemu-ifup.sh -net nic,model=virtio -net dump,file=./dump.lan.qemu.virtio The answer is about old -net interface which I know how to use. Does this mean that there is no way to use dump with -netdev tap? It is not possible using just -netdev/-device. The closest you can get is: $ qemu -netdev hubport,hubid=1,id=hubport0 \ -device virtio-net-pci,netdev=hubport0,... \ -net tap,vlan=1,... \ -net dump,vlan=1,... Care to explain briefly how hubport works, and how it's connected to the legacy vlan feature? This is the v2 blurb: http://thread.gmane.org/gmane.comp.emulators.qemu/161502 A so called diagram: http://article.gmane.org/gmane.comp.emulators.qemu/161245 Laszlo
Re: [Qemu-devel] using -net dump with tap networking
Stefan Hajnoczi stefa...@gmail.com writes: On Tue, Feb 19, 2013 at 09:53:07AM +0100, Markus Armbruster wrote: Stefan Hajnoczi stefa...@redhat.com writes: On Tue, Feb 19, 2013 at 12:37:28PM +1100, Alexey Kardashevskiy wrote: On 14/02/13 21:26, Stefan Hajnoczi wrote: Now I want to enable network dump. With the old -net syntax I could do that with -net dump but I cannot with the new syntax, tried many variants, none works. What would the correct syntax be for the case above? The question was about new -netdev interface. I would do: qemu-system-ppc64 ... -net tap,ifname=tap0,script=qemu-ifup.sh -net nic,model=virtio -net dump,file=./dump.lan.qemu.virtio The answer is about old -net interface which I know how to use. Does this mean that there is no way to use dump with -netdev tap? It is not possible using just -netdev/-device. The closest you can get is: $ qemu -netdev hubport,hubid=1,id=hubport0 \ -device virtio-net-pci,netdev=hubport0,... \ -net tap,vlan=1,... \ -net dump,vlan=1,... Care to explain briefly how hubport works, and how it's connected to the legacy vlan feature? -netdev hubport instantiates a new port on a hub with vlan number hubid=number. hubport is a -netdev, so it allows you to hook up a NIC to a hub using -netdev/-device syntax. This is just playing games with syntax, we still have a hub in between the virtio-net-pci, tap, and dump devices. I didn't check if the offload features get plumbed through, but I wouldn't count on it. Thanks. Would you mind documenting net backend hubport in qemu-options.hx? Was forgotten in commit f6c874e3. Your example uses -net to connect additional backends to the hubport. If I understand you correctly, you can't use -netdev to do that. Ignorant question: fundamental reason or just not implemented?
Re: [Qemu-devel] using -net dump with tap networking
On 02/19/13 18:50, Markus Armbruster wrote: Your example uses -net to connect additional backends to the hubport. If I understand you correctly, you can't use -netdev to do that. Ignorant question: fundamental reason or just not implemented? (I'll let Stefan correct me, but I should be able to understand it as well, since I reviewed his series...) N 1 NetClientState - NICConf ^ ^ | | | | user/tap/socket/ e1000/virtio-net-pci vde/bridge/hubport-device -netdev -netdev describes an object (a backend) derived from NetClientState. NetClientState has a single peer. -device describes a frontend (a guest device). Some of those are network interfaces, derived from NICConf. (They also inherit a bunch of other stuff). NICConf has an array of peers. When a backend is created with -netdev, qemu_new_net_client() is called in such a way that the peer to set is NULL, no links are created. The linkage is established from the NIC side, (a) -net nic,model=...,netdev=...; in qemu_new_nic(), (b) -device e1000,netdev=...; in parse_netdev() I think. All 2*N links are created from the NIC side (two per each guest queue I think), ie. when the frontend is added, that sets the peer link inside all N referencedbackends as well. NetHubPort is a special backend (host device) that forwards to all other NetHubPort backends on the same NetHub. This is internal to NetHubPort. -net is super-confusing. (1) -net nic,model=...,netdev=... corresponds to case (a) above, it adds a frontend and links back all referenced, pre-existent backends to it. (2) -net nic,model=...[,vlan=...] creates a NetHubPort backend on the specified NetHub (vlan defaults to 0), creates the frontend as well, and links them together. (3) -net BACKEND[,vlan=...], including BACKEND==dump, creates a NetHubPort backend on the specified NetHub, also creates an instance of the requested backend type, and links them together via each one's peer link. ( Regarding the (non-hub) backend created in (3), its peer link is already occupied, hence you cannot set different linkage for it from the frontend side, as in (a) or (b). In (a) it triggers an assert(), in (b) it returns -EEXIST I think. ... I can't actually trigger the assert in (a) -- looks like (b) is always reached first --, but I can trigger the -EEXIST in (b): # qemu -net dump,name=dump0 -net nic,model=e1000,netdev=dump0 qemu-system-x86_64: Property 'e1000.netdev' can't take value 'dump0', it's in use Aborted # qemu -net dump,name=dump0 -device e1000,netdev=dump0 qemu-system-x86_64: -device e1000,netdev=dump0: Property 'e1000.netdev' can't take value 'dump0', it's in use (no abort, exit status 1) ) In order to take a stab at your question at last: - the two (parallel, opposing) links created in (3) connect two backends, - -netdev does not set the peer link in the backend, so you cannot use that, - -device *would* set the links in both directions, but it's for creating frontends. IOW (3) is unique because it links backend to backend. (It could tempt us to create an infinite loop between two NetHubPorts, ie. -net hubport,hubid=0; one path via the NetHub, the other through the direct peer link. net_init_hubport() is smart enough to prevent that; you can only add a hubport with -netdev, which doesn't set the peer link for the backend, and then you can only set it with a -device or -net nic from the other side.) Laszlo
Re: [Qemu-devel] using -net dump with tap networking
On 14/02/13 21:26, Stefan Hajnoczi wrote: Now I want to enable network dump. With the old -net syntax I could do that with -net dump but I cannot with the new syntax, tried many variants, none works. What would the correct syntax be for the case above? The question was about new -netdev interface. I would do: qemu-system-ppc64 ... -net tap,ifname=tap0,script=qemu-ifup.sh -net nic,model=virtio -net dump,file=./dump.lan.qemu.virtio The answer is about old -net interface which I know how to use. Does this mean that there is no way to use dump with -netdev tap? -- Alexey
Re: [Qemu-devel] using -net dump with tap networking
On Thu, Feb 14, 2013 at 11:51:42AM +1100, Alexey Kardashevskiy wrote:
On 14/02/13 05:02, Laszlo Ersek wrote:
On 02/13/13 15:48, Alexey Kardashevskiy wrote:
Hi!
I am running qemu as:
qemu/ppc64-softmmu/qemu-system-ppc64 -m 1024 -M pseries -trace
events=trace_events -netdev user,id=virtnet,hostfwd=tcp::5000-:22
-device virtio-net-pci,netdev=virtnet -nographic -vga none -enable-kvm
-kernel vml36_64k -initrd 1.cpio
Now I want to enable network dump. With the old -net syntax I could do
that with -net dump but I cannot with the new syntax, tried many
variants, none works. What would the correct syntax be for the case above?
Ugh, I'm a bit confused, but if I say something stupid that should still
help ignite the discussion.
So, in general there are two ways to specify this:
(1) -net dump,id=dump0,vlan=VLAN_ID,len=SIZE_LIMIT,file=PATHNAME
(2) -netdev dump,id=dump0,len=SIZE_LIMIT,file=PATHNAME
I believe the first option (legacy) should work.
The second one will not work; actually I think it will trigger an
assert. The generic init code in net_client_init1() [net/net.c] says:
NetClientState *peer = NULL;
/* Do not add to a vlan if it's a -netdev or a nic with a netdev=
* parameter. */
if (!is_netdev
(opts-kind != NET_CLIENT_OPTIONS_KIND_NIC ||
!opts-nic-has_netdev)) {
peer = net_hub_add_port(u.net-has_vlan ? u.net-vlan : 0,
NULL);
}
if (net_client_init_fun[opts-kind](opts, name, peer) 0) {
So in (2) we don't add the dump netdev to any hub/vlan; however the
specific code (net_init_dump(), [net/dump.c]) asserts (peer != NULL).
Otherwise I think the idea would be to add the dump netdev *afterwards*
to a vlan/hub, by changing its vlan property. See set_vlan() in
[hw/qdev-properties-system.c]; it calls net_hub_port_find() [net/hub.c]
whose task is to Find a available port on a hub; otherwise create one
new port.
See
http://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03182.html.
Hence I think you're back to (1), the legacy format. Assuming qemu
doesn't barf on that option immediately, I believe you *also* have to
add your -netdev user to the same hub as the dumper is on.
In total you have to create both netdevs (a, b) and assign both to a
common hub/vlan (c, d). Again, unfortunately the dump netdev only works
with the legacy format, but that already includes the assignment to the
hub (a, c). So you have to take care of creating the other netdev
(-netdev user, b), and assign it through its vlan qdev property to the
same hub (d), so that data can flow from it to the dump netdev.
Hm... Looks like you can't do that directly on -netdev user (it seems
to have no such property). virtio-net-pci does have it however. At
least in a quick info qtree check:
bus: main-system-bus
type System
dev: i440FX-pcihost, id
bus: pci.0
type PCI
dev: virtio-net-pci, id net0
dev-prop: vlan = null
Also confirmed by qemu-system-x86_64 -device virtio-net-pci,help.
So
-netdev user,id=virtnet,hostfwd=tcp::5000-:22 \
-device virtio-net-pci,netdev=virtnet,vlan=2 \
-net dump,vlan=2,len=SIZE_LIMIT,file=PATHNAME
Or some such...
Ok. So, there is user device (interface to the world) and 2 QEMU
network devices - virtio and dump, attached to the same virtual
bridge within the QEMU.
Now let's make it more fun. Actually I want to trace a tap config
(I put it into the subject but later changed the actual example in a
hope that it makes things simpler but I was wrong :-) ):
qemu-impreza/ppc64-softmmu/qemu-system-ppc64 -m 1024 -M pseries
-nographic -vga none -enable-kvm -kernel vml36_64k -initrd 1.cpio
-netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh
-device virtio-net-pci,netdev=tapnet,vlan=100
-net dump,vlan=100,file=./dump.lan.qemu.virtio
So I have a virtual bridge but it is in the host, not in the QEMU.
To the command line above QEMU says:
Warning: vlan 100 is not connected to host network
Warning: netdev tapnet has no peer
qemu -help says -net tap accepts vlan=n but -netdev
tap,vlan=100,... generates an error (Invalid parameter 'vlan').
Those options don't make sense because:
1. A -netdev does not have a peer or a vlan. It simply defines a host
net device that can been peered with -device ...,netdev=id.
2. A -device ...,netdev=tapnet,vlan=100 doesn't make sense since netdev=
specifies the peer and so does vlan=100. Either it can be connected
directly (peered) to tapnet or it can be connected to vlan 100. You
can't have both.
I would do:
qemu-system-ppc64 ...
-net tap,ifname=tap0,script=qemu-ifup.sh
-net nic,model=virtio
-net dump,file=./dump.lan.qemu.virtio
Sure I can run tcpdump on the host with the tap0 interface but I
would like to catch trafic between virtio-net-pci and tap0 if it is
possible. Is it?
-nic dump kind of
Re: [Qemu-devel] using -net dump with tap networking
On 02/13/13 15:48, Alexey Kardashevskiy wrote:
Hi!
I am running qemu as:
qemu/ppc64-softmmu/qemu-system-ppc64 -m 1024 -M pseries -trace
events=trace_events -netdev user,id=virtnet,hostfwd=tcp::5000-:22
-device virtio-net-pci,netdev=virtnet -nographic -vga none -enable-kvm
-kernel vml36_64k -initrd 1.cpio
Now I want to enable network dump. With the old -net syntax I could do
that with -net dump but I cannot with the new syntax, tried many
variants, none works. What would the correct syntax be for the case above?
Ugh, I'm a bit confused, but if I say something stupid that should still
help ignite the discussion.
So, in general there are two ways to specify this:
(1) -net dump,id=dump0,vlan=VLAN_ID,len=SIZE_LIMIT,file=PATHNAME
(2) -netdev dump,id=dump0,len=SIZE_LIMIT,file=PATHNAME
I believe the first option (legacy) should work.
The second one will not work; actually I think it will trigger an
assert. The generic init code in net_client_init1() [net/net.c] says:
NetClientState *peer = NULL;
/* Do not add to a vlan if it's a -netdev or a nic with a netdev=
* parameter. */
if (!is_netdev
(opts-kind != NET_CLIENT_OPTIONS_KIND_NIC ||
!opts-nic-has_netdev)) {
peer = net_hub_add_port(u.net-has_vlan ? u.net-vlan : 0, NULL);
}
if (net_client_init_fun[opts-kind](opts, name, peer) 0) {
So in (2) we don't add the dump netdev to any hub/vlan; however the
specific code (net_init_dump(), [net/dump.c]) asserts (peer != NULL).
Otherwise I think the idea would be to add the dump netdev *afterwards*
to a vlan/hub, by changing its vlan property. See set_vlan() in
[hw/qdev-properties-system.c]; it calls net_hub_port_find() [net/hub.c]
whose task is to Find a available port on a hub; otherwise create one
new port.
See
http://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03182.html.
Hence I think you're back to (1), the legacy format. Assuming qemu
doesn't barf on that option immediately, I believe you *also* have to
add your -netdev user to the same hub as the dumper is on.
In total you have to create both netdevs (a, b) and assign both to a
common hub/vlan (c, d). Again, unfortunately the dump netdev only works
with the legacy format, but that already includes the assignment to the
hub (a, c). So you have to take care of creating the other netdev
(-netdev user, b), and assign it through its vlan qdev property to the
same hub (d), so that data can flow from it to the dump netdev.
Hm... Looks like you can't do that directly on -netdev user (it seems
to have no such property). virtio-net-pci does have it however. At
least in a quick info qtree check:
bus: main-system-bus
type System
dev: i440FX-pcihost, id
bus: pci.0
type PCI
dev: virtio-net-pci, id net0
dev-prop: vlan = null
Also confirmed by qemu-system-x86_64 -device virtio-net-pci,help.
So
-netdev user,id=virtnet,hostfwd=tcp::5000-:22 \
-device virtio-net-pci,netdev=virtnet,vlan=2 \
-net dump,vlan=2,len=SIZE_LIMIT,file=PATHNAME
Or some such...
Laszlo
Re: [Qemu-devel] using -net dump with tap networking
Il 13/02/2013 19:02, Laszlo Ersek ha scritto: I am running qemu as: qemu/ppc64-softmmu/qemu-system-ppc64 -m 1024 -M pseries -trace events=trace_events -netdev user,id=virtnet,hostfwd=tcp::5000-:22 -device virtio-net-pci,netdev=virtnet -nographic -vga none -enable-kvm -kernel vml36_64k -initrd 1.cpio Now I want to enable network dump. With the old -net syntax I could do that with -net dump but I cannot with the new syntax, tried many variants, none works. What would the correct syntax be for the case above? Ugh, I'm a bit confused, but if I say something stupid that should still help ignite the discussion. So, in general there are two ways to specify this: (1) -net dump,id=dump0,vlan=VLAN_ID,len=SIZE_LIMIT,file=PATHNAME (2) -netdev dump,id=dump0,len=SIZE_LIMIT,file=PATHNAME I believe the first option (legacy) should work. Yes. -net dump is meant to be used with vlans: you typically use a 3-port VLAN (actually a hub, not just in code but also as a mental model) with a tap device, a NIC and the dumper. Hence I think you're back to (1), the legacy format. Assuming qemu doesn't barf on that option immediately, I believe you *also* have to add your -netdev user to the same hub as the dumper is on. In total you have to create both netdevs (a, b) and assign both to a common hub/vlan (c, d). Again, unfortunately the dump netdev only works with the legacy format, but that already includes the assignment to the hub (a, c). So you have to take care of creating the other netdev (-netdev user, b), and assign it through its vlan qdev property to the same hub (d), so that data can flow from it to the dump netdev. Hm... Looks like you can't do that directly on -netdev user (it seems to have no such property). Right, just use -net user/-net tap and it will create both a hub port and a backend. virtio-net-pci does have it however. At least in a quick info qtree check: bus: main-system-bus type System dev: i440FX-pcihost, id bus: pci.0 type PCI dev: virtio-net-pci, id net0 dev-prop: vlan = null Also confirmed by qemu-system-x86_64 -device virtio-net-pci,help. It may well be broken. In this case, again just use -net nic. I learnt yesterday that the legacy syntax disables checksum and fragmentation offloading. The reason is that peer_test_vnet_hdr only work if the NIC is connected directly to the TAP device, with no hubs in between. Anyway you probably don't care about that if you want to get dumps; in fact having correct checksums in the dumps will probably help. Paolo
Re: [Qemu-devel] using -net dump with tap networking
On 14/02/13 05:02, Laszlo Ersek wrote:
On 02/13/13 15:48, Alexey Kardashevskiy wrote:
Hi!
I am running qemu as:
qemu/ppc64-softmmu/qemu-system-ppc64 -m 1024 -M pseries -trace
events=trace_events -netdev user,id=virtnet,hostfwd=tcp::5000-:22
-device virtio-net-pci,netdev=virtnet -nographic -vga none -enable-kvm
-kernel vml36_64k -initrd 1.cpio
Now I want to enable network dump. With the old -net syntax I could do
that with -net dump but I cannot with the new syntax, tried many
variants, none works. What would the correct syntax be for the case above?
Ugh, I'm a bit confused, but if I say something stupid that should still
help ignite the discussion.
So, in general there are two ways to specify this:
(1) -net dump,id=dump0,vlan=VLAN_ID,len=SIZE_LIMIT,file=PATHNAME
(2) -netdev dump,id=dump0,len=SIZE_LIMIT,file=PATHNAME
I believe the first option (legacy) should work.
The second one will not work; actually I think it will trigger an
assert. The generic init code in net_client_init1() [net/net.c] says:
NetClientState *peer = NULL;
/* Do not add to a vlan if it's a -netdev or a nic with a netdev=
* parameter. */
if (!is_netdev
(opts-kind != NET_CLIENT_OPTIONS_KIND_NIC ||
!opts-nic-has_netdev)) {
peer = net_hub_add_port(u.net-has_vlan ? u.net-vlan : 0, NULL);
}
if (net_client_init_fun[opts-kind](opts, name, peer) 0) {
So in (2) we don't add the dump netdev to any hub/vlan; however the
specific code (net_init_dump(), [net/dump.c]) asserts (peer != NULL).
Otherwise I think the idea would be to add the dump netdev *afterwards*
to a vlan/hub, by changing its vlan property. See set_vlan() in
[hw/qdev-properties-system.c]; it calls net_hub_port_find() [net/hub.c]
whose task is to Find a available port on a hub; otherwise create one
new port.
See
http://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03182.html.
Hence I think you're back to (1), the legacy format. Assuming qemu
doesn't barf on that option immediately, I believe you *also* have to
add your -netdev user to the same hub as the dumper is on.
In total you have to create both netdevs (a, b) and assign both to a
common hub/vlan (c, d). Again, unfortunately the dump netdev only works
with the legacy format, but that already includes the assignment to the
hub (a, c). So you have to take care of creating the other netdev
(-netdev user, b), and assign it through its vlan qdev property to the
same hub (d), so that data can flow from it to the dump netdev.
Hm... Looks like you can't do that directly on -netdev user (it seems
to have no such property). virtio-net-pci does have it however. At
least in a quick info qtree check:
bus: main-system-bus
type System
dev: i440FX-pcihost, id
bus: pci.0
type PCI
dev: virtio-net-pci, id net0
dev-prop: vlan = null
Also confirmed by qemu-system-x86_64 -device virtio-net-pci,help.
So
-netdev user,id=virtnet,hostfwd=tcp::5000-:22 \
-device virtio-net-pci,netdev=virtnet,vlan=2 \
-net dump,vlan=2,len=SIZE_LIMIT,file=PATHNAME
Or some such...
Ok. So, there is user device (interface to the world) and 2 QEMU network
devices - virtio and dump, attached to the same virtual bridge within
the QEMU.
Now let's make it more fun. Actually I want to trace a tap config (I put
it into the subject but later changed the actual example in a hope that it
makes things simpler but I was wrong :-) ):
qemu-impreza/ppc64-softmmu/qemu-system-ppc64 -m 1024 -M pseries
-nographic -vga none -enable-kvm -kernel vml36_64k -initrd 1.cpio
-netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh
-device virtio-net-pci,netdev=tapnet,vlan=100
-net dump,vlan=100,file=./dump.lan.qemu.virtio
So I have a virtual bridge but it is in the host, not in the QEMU. To the
command line above QEMU says:
Warning: vlan 100 is not connected to host network
Warning: netdev tapnet has no peer
qemu -help says -net tap accepts vlan=n but -netdev
tap,vlan=100,... generates an error (Invalid parameter 'vlan').
Sure I can run tcpdump on the host with the tap0 interface but I would like
to catch trafic between virtio-net-pci and tap0 if it is possible. Is it?
btw is there any way to get for the -netdev device what -device NAME,help
does (i.e. list of actually supported parameters)?
--
Alexey
