Re: [Qemu-devel] [Qemu-discuss] qemu-kvm: -netdev user: Parameter 'id' is missing

[Stefan Hajnoczi]

On Tue, Jul 24, 2012 at 8:02 PM, anatoly techtonik <address@hidden> wrote:
> On Tue, Jul 24, 2012 at 1:23 PM, Stefan Hajnoczi <address@hidden> wrote:
>> On Mon, Jul 23, 2012 at 10:41 PM, anatoly techtonik <address@hidden> wrote:
>>> Forwarding per discussion in qemu-discuss.
>>> Please CC.
>>>
>>> ---------- Forwarded message ----------
>>> From: Mike Lovell <address@hidden>
>>> Date: Mon, Jul 23, 2012 at 10:58 PM
>>> Subject: Re: [Qemu-discuss] qemu-kvm: -netdev user: Parameter 'id' is 
>>> missing
>>> To: address@hidden
>>>
>>>
>>> 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