Re: [PATCH] Expose SLIRP attributes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/28/2014 01:03 PM, Richard W.M. Jones wrote:
> On Fri, Mar 28, 2014 at 12:16:43PM +0200, Laine Stump wrote:
>> 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
> I don't understand why this should be mandatory.

Well, if the <ip> element is present, there should be *something* in it,
otherwise why bother? But I do see the point that someone might want to
specify the network (or rather the gateway), but not care which IP on
that network was used by the guest.

>  Actually I don't
> think any of them should be mandatory (the same as qemu), but the only
> one which libguestfs would specify is the network.  The guest can
> choose any IP address on the network >= .5 and things will work.  The
> libguestfs appliance arbitrarily uses .10 since DHCP would be too
> slow.

But if the guest is going to choose an IP address itself rather than
getting one from DHCP, it should know that it's choosing an address on
the correct network, and I don't like the idea of depending on qemu's
current choice of default network/host IP/dns IP to remain constant.
That's why I think that, even if the attributes aren't required (or
present) in the XML, we should define defaults for anything that could
affect the correctness of what *is* specified, and always fill them in
on the qemu commandline.


>> * 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)
> Right, qemu does this if you don't specify it on the command line.
>
>> * gateway should default to
>>
>>       address & ~(0xffffffff<<(32-prefix)) + 1
> qemu will choose .2 unless specified.


Yes, currently that's what it will do, and it's not likely to change,
but it might. And if we support this config for a different network
implementation, their default probably *won't* be .2.


>
> [...]
>
> For libguestfs we only care about setting the network address + prefix,
> and to fix this bug I'm quite happy for the patch to only do that, and
> we can worry about the other things another time.

Sure, that's fine with me too, as long as we don't do it in a way that
paints us into a corner such that we *can't* add the other things in a
logical manner. (/me has gotten in the habit of considering patches as
one would consider moves in a chess game, which sometimes has the
unfortunate side effect of leading to gridlock)

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]