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.
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
