[xen-tools-dev] [PATCH] Use dom0 resolv.conf when chrooting

[Stéphane Jourdois]

Le 15 juillet 2010 16:39, Dmitry Nedospasov <dmitry at nedos.net> a écrit :
> On Thu, Jul 15, 2010 at 04:17:56PM +0200, Stéphane Jourdois wrote:
>> Apart from the fact that AFAIR it doesn't properly works in roles
>> scripts ($ip1 contains all ips, $ip2 is empty), you can only add
>> multiple aliases, and with the _same_ netmask as the first alias.
>> You can't add several virtual interfaces using xen-tools for the
>> moment, even by using modified templates.
>
> Okay, but to be fair, i think this is all that the most users will
> need.

That is so true... and that is a pity ! :-D

>> That is a good point. That's why I provided an example, please compare :
>>
>> [...]
>>
>
> Okay, i like this. It should however to default to the classic settings
> if vif1 isn't set.

Agreed.

> Another important consideration to think about is
> that it is possible to specify a vifname in the config file. This patch
> shouln't break that functionality.

Agreed, same applies for bridge name.

>> > Anyway the only use-case I see is running a management subnet and a
>> > public subnet where the services are hosted, but I'm not sure this
>> > needs to be automated.
>>
>> This is exactly my need, and the only way to have secured domU's
>> without ssh listening on public IPs, while keeping the simplicity of
>> bridged networking :-)
>> Even if this doesn't _need_ to be automated, a fact that I would tend
>> to agree to, it should not be impossible to do it... and currently it
>> is :-(
>
> Okay, well ideally, use-cases should be implemented in role scripts.
> Setting up the second interface via a role script should be possible,
> however it still requires adding the parsing and parameters to the main
> script.

Why not, this is not a bad idea. The vifN options would then only be
documented in the roles script.
But roles are not distribution-specific, and network settings are :-(
IMHO, this invalidates this good idea.

> Anyway, I'll gladly take a look when you have it running. Like i said my
> personal preference for such patches would be to setup the second
> interface in a roll script.
>
> Keep in mind that at some point we want to greatly reduce the current
> code duplication by making scripts that are comman to all distributions.
> This is yet another reason to try to stay away from patching the core
> code to much; a role script ofcourse is a step in the right direction.

That of course is a thing to keep in mind that I didn't know.

Let's see then what Axel thinks about this discussion ?
Cheers.