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

[Stéphane Jourdois]

Hi,

2010/7/15 Dmitry Nedospasov <dmitry at nedos.net>:
> On Thu, Jul 15, 2010 at 03:15:31PM +0200, Stéphane Jourdois wrote:
>> When those will be reviewed (and merged/rejected), I'm going to
>> implement further patches to permit configuration of multiple vifs.
>> I'm still asking myself how to do it so that :
>>  - config file remains simple to edit ;
>>  - old config files continue to work as before ;
>>
>> I see two solutions :
>>  - add ip2,netmask2,...,ip3,netmask3,etc :
>>    this is _not_ beautiful code, but works, and xen doesn't support
>> ...
>
> AFAIK, you /CAN/ set multiple ips right now.

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.

> I'm not sure that extending xen-tools functionality as to being able to
> support such a complex configuration is really something that we need.

That is a good point. That's why I provided an example, please compare :

----
# Uncomment and adjust these network settings if you wish to give your
# new instances static IP addresses.
#gateway = 1.2.3.4
#netmask = 255.255.255.0
#broadcast = 1.2.3.255
# Uncomment this if you wish the images to use DHCP
#dhcp = 1
----
to :
----
# Uncomment and adjust these network settings if you wish to give your
# new instances static IP addresses on the first virtual interface.
# vif1 = gateway,netmask,broadcast
#vif1 = 1.2.3.4,255.255.255.0,1.2.3.255
# Uncomment this if you wish the images to use DHCP on first virtual interface
#vif1 = dhcp
----

Would it really be more complex for administrators using xen ?

> 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 :-(

Anyway, thanks very much for taking the time to discuss this !
Stéphane (kwisatz) Jourdois