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

[anatoly techtonik]

On Wed, Jul 25, 2012 at 6:00 PM, Stefan Hajnoczi <address@hidden> wrote:
> 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"

I've seen it. 3 page long list of devices is not practical for every day use.

>>> 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

-net user  is deprecated, no?

> 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.

Yes, it would be nice if documentation was user story oriented, going
gradually from the simplest use stories (tutorials) to more difficult:
1. download stuff from internet from guest (NAT) (OS updates, software
installation)
2. run services on guest accessible from host (web server and stuff)
without specialized configuration (i.e. port forwarding)
3. services on guest accessible from other guests (web development
scenarios - guest servers for db, web, client on host)
..
x. routers, vlans, networks, bridges and other hardcore hardware emulation stuff

>> 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.

Do you maintain a list of use cases? It should be easy to forward
people to it when they face with this problem on not-intuitive
interface. Then outsiders can try to help with prototyping this
interface too. For example, with Python's argparse.