5:16 a.m.
On 03/28/2014 10:47 AM, Richard W.M. Jones wrote:
On Fri, Mar 28, 2014 at 10:33:39AM +0200, Laine Stump wrote:
> Beyond that, a question not with your patch, but with qemu's
> implemenation - does it always assume that the gateway address is
> $network.1 ?
Actually network.2. The default addresses are:
network: 10.0.2.0/24 (ie. mask 255.255.255.0)
default gateway: 10.0.2.2
dns server: 10.0.2.3
dhcp start / normal guest address: 10.0.2.15
It _is_ possible to change the gateway address, by specifying the
(confusingly named) 'host=' parameter. As you suggested I think this
could be mapped to a gateway XML attribute, although libguestfs would
not need to use it.
Ah, good. I didn't see that in the parameters that I found (why is my
first reaction now to do a google search instead of looking at the man
page? What is wrong with me?? :-P).
In that case, I think that the XML should be
<ip address='guest's IP address' prefix='prefix for network'
gateway='host IP address according to guest'
dns='DNS server IP given in DHCP response (and answering requests)'/>
I think that
* address should be mandatory
* prefix should default to the natural prefix for that particular
address (we have a function somewhere in the network conf or driver code
that already does this)
* gateway should default to
address & ~(0xffffffff<<(32-prefix)) + 1
* dns should default to gateway (I know this doesn't match qemu's
default, but we shouldn't be designing our XML based on qemu's default,
nor should we be assuming that their default will remain unchanged in
the future - we've been burned by that before. Rather, we should make
the defaults as similar to what we do in other parts of libvirt as
possible).
As for the setting of qemu's options:
* qemu's "network" option should be filled in with
$(gateway & ~(0xffffffff<<(32-prefix)) / $prefix
* qemu's "host" should be filled in with $gateway
* qemu's "dns" should be filled in with $dns
* qemu's "dhcpstart" should be filled in with $address
(do we also want to add a "domain" attribute, which would default to
empty, and be put into qemu's "dnssearch" option?)
When I saw the list of options, I briefly considered that we should
support restricted, but on reading the details it turns out that option
*completely* shuts down network traffic, even to the host, and you need
to add forwarding rules to individually enable what you want. Although
that might be useful in some cases, it is very different from libvirt
networks' "isolated" vs. forward modes, meaning I don't have a clear
idea of a way to make it fit nicely with existing paradigms, so I won't
pursue it for now (or later, unless someone specifically requests it :-)
Rich.
----------------------------------------------------------------------
Full parameters:
-netdev user,id=id[,option][,option][,...]
-net user[,option][,option][,...]
Use the user mode network stack which requires no administrator
privilege to run. Valid options are:
vlan=n
Connect user mode stack to VLAN n (n = 0 is the default).
id=id
name=name
Assign symbolic name for use in monitor commands.
net=addr[/mask]
Set IP network address the guest will see. Optionally specify
the netmask, either in the form a.b.c.d or as number of valid
top-most bits. Default is 10.0.2.0/24.
host=addr
Specify the guest-visible address of the host. Default is the
2nd IP in the guest network, i.e. x.x.x.2.
restrict=on|off
If this option is enabled, the guest will be isolated, i.e. it
will not be able to contact the host and no guest IP packets
will be routed over the host to the outside. This option does
not affect any explicitly set forwarding rules.
hostname=name
Specifies the client hostname reported by the built-in DHCP
server.
dhcpstart=addr
Specify the first of the 16 IPs the built-in DHCP server can
assign. Default is the 15th to 31st IP in the guest network,
i.e. x.x.x.15 to x.x.x.31.
dns=addr
Specify the guest-visible address of the virtual nameserver.
The address must be different from the host address. Default is
the 3rd IP in the guest network, i.e. x.x.x.3.
dnssearch=domain
Provides an entry for the domain-search list sent by the built-
in DHCP server. More than one domain suffix can be transmitted
by specifying this option multiple times. If supported, this
will cause the guest to automatically try to append the given
domain suffix(es) in case a domain name can not be resolved.
Example:
qemu -net user,dnssearch=mgmt.example.org,dnssearch=example.org
[...]
tftp=dir
When using the user mode network stack, activate a built-in
TFTP server. The files in dir will be exposed as the root of a
TFTP server. The TFTP client on the guest must be configured
in binary mode (use the command "bin" of the Unix TFTP client).
bootfile=file
When using the user mode network stack, broadcast file as the
BOOTP filename. In conjunction with tftp, this can be used to
network boot a guest from a local directory.
Example (using pxelinux):
qemu-system-i386 -hda linux.img -boot n -net
user,tftp=/path/to/tftp/files,bootfile=/pxelinux.0
smb=dir[,smbserver=addr]
When using the user mode network stack, activate a built-in SMB
server so that Windows OSes can access to the host files in dir
transparently. The IP address of the SMB server can be set to
addr. By default the 4th IP in the guest network is used, i.e.
x.x.x.4.
In the guest Windows OS, the line:
10.0.2.4 smbserver
must be added in the file C:\WINDOWS\LMHOSTS (for windows
9x/Me) or C:\WINNT\SYSTEM32\DRIVERS\ETC\LMHOSTS (Windows
NT/2000).
Then dir can be accessed in \\smbserver\qemu.
Note that a SAMBA server must be installed on the host OS.
QEMU was tested successfully with smbd versions from Red Hat 9,
Fedora Core 3 and OpenSUSE 11.x.