[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-discuss] qemu-kvm: -netdev user: Parameter 'id' i
Re: [Qemu-devel] [Qemu-discuss] qemu-kvm: -netdev user: Parameter 'id' is missing
Wed, 25 Jul 2012 16:00:08 +0100
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
>>> 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
You are right that this is underdocumented and confusing. Answers to
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
>> 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
> 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
> 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.
* No gateway or DNS fields in the DHCP reply - guest has no external
* 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).