On Tue, Jul 24, 2012 at 8:02 PM, anatoly techtonik <techto...@gmail.com> wrote: > On Tue, Jul 24, 2012 at 1:23 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> On Mon, Jul 23, 2012 at 10:41 PM, anatoly techtonik <techto...@gmail.com> >> wrote: >>> Forwarding per discussion in qemu-discuss. >>> Please CC. >>> >>> ---------- Forwarded message ---------- >>> From: Mike Lovell <m...@dev-zero.net> >>> Date: Mon, Jul 23, 2012 at 10:58 PM >>> Subject: Re: [Qemu-discuss] qemu-kvm: -netdev user: Parameter 'id' is >>> missing >>> To: qemu-disc...@nongnu.org >>> >>> >>> On 07/20/2012 04:10 PM, anatoly techtonik wrote: >>>> >>>> The documentation at http://wiki.qemu.org/Documentation/Networking >>>> makes people think that 'id' parameter for -netdev user is optional, >>>> which doesn't appear to be true: >>>> >>>> $ qemu-kvm -hda image.img -netdev user >>>> qemu-kvm: -netdev user: Parameter 'id' is missing >> >> I have updated the wiki page. > > Even with -net nic considered obsolete (is the whole -net family > obsolete?), it looks like there is no complete replacement for it. For > example, there is no equivalent for -net nic,model=? (referenced from > wiki). It is also strange to read proposal to "see the qemu man page > for the various options that you can pass to -net nic". Unfortunately, > -netdev is completely undocumented in man and there is no info that > -net nic and -net user are obsolete there. All this stuff is > confusing.
You are right that this is underdocumented and confusing. Answers to your points: 1. -device ? lists all device models built into QEMU. This includes NICs but they are not grouped in an easy-to-find way. Here is an example of the output: name "e1000", bus PCI, desc "Intel Gigabit Ethernet" 2. -netdev is undocumented on the man page. I'm fixing this and will send the patch to qemu-devel. 3. There is a little bit of -netdev/-device documentation in docs/qdev-device-use.txt. >> A -netdev needs to be paired with a NIC -device. That's why the >> identifier is essential, it allows you to say -netdev >> <type>,id=netdev0 -device <type>,netdev=netdev0. > > It still says "The id option can be used with the -device...", where > "can be" looks like it should be replaced by "must". Strictly speaking "can be" is correct because -device id= is optional. You can also do: -net user -device virtio-net-pci,vlan=0 This is basically equivalent to: -net user -net nic,model=virtio What's going on here is that -device is used but with the legacy QEMU "VLAN" feature that can be used to connect NICs and backends. Things aren't as simple as they should be but I think the problem here is really the documentation. We can try to improve it so that it doesn't leave open questions like this, maybe without going into every nasty detail. > Why is it impossible for -netdev to create NIC device automatically if > not explicitly set? As a user I don't really know which net device do > I need. This would greatly simplify user experience (and lower Qemu > bounce rate). There was a similar discussion about -drive for block devices just the other day. I don't think there's a good answer except that QEMU command-line has historic baggage and that everyone has a different use case so it can be hard to come up with a good simplified command-line option set. The area where I think we can fix things easily is by offering better documentation. > There is also a question about user mode. It is said "the guest is not > directly accessible from the host or the external network" and also > "You can isolate the guest from the host (and broader network) using > the restrict option". ??? Guest is already not directly accessible - > why use the restrict? You are correct that the guest is not directly accessible from the host. I think what the line about isolation means to say is that you can prevent the guest from communicating with anything besides the emulated network inside QEMU. restricted=on means: * No gateway or DNS fields in the DHCP reply - guest has no external connectivity * No TCP connections to external host:port unless explicitly allowed * No UDP except for the built-in DHCP/TFTP server You could use this if you don't want software inside the guest to phone home, for example, but still want some basic network services (like TFTP boot). Stefan
