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

Re: [Xen-users] Xen4.4 HVM domains and routed setups



Hi

First, from the perspective of the client there is no network (like 1.1.2.0/x), 
so I can currently use .0 and .15 which would
otherwise be the network and broadcast address.
Then I DON?T want the domUs to speak to each other without going through the 
host.
I have no bridge defined whatsoever and I am sure I don?t need it so I would 
like to skip that, if possible.

And as I found a setup that works (see other post) I now only need to find a 
way to tell the vif-route script how to correctly do
that...

Best regards,
  Steffen


-----Ursprüngliche Nachricht-----
Von: xen-users-bounces@xxxxxxxxxxxxx [mailto:xen-users-bounces@xxxxxxxxxxxxx] 
Im Auftrag von Adam Goryachev
Gesendet: Dienstag, 27. Mai 2014 00:06
An: xen-users@xxxxxxxxxxxxx
Betreff: Re: [Xen-users] Xen4.4 HVM domains and routed setups

On 27/05/14 04:50, Steffen Heil (Mailinglisten) wrote:
> Hi
>
>
>> can you elaborate a bit more on what you actually want to do? Cause I 
>> guess you are trying to do something I've got working with a modified 
>> vif-nat setup and can be of help, but I would like to take
the guesswork out of the equation first..
> I have a server and I want to run several vms on it.
> The server itself has one public ip (say 1.1.1.1) and a whole additional 
> network (say 1.1.2.0/28) is routed to that server.
>
> All my vms are running with a point-o-point setup, that is the vm 
> knows it's own ip (say 1.1.2.5) and the hosts ip (1.1.1.1) and routes every 
> packet that is not for itself to the host.
> The vif-route and network-route scripts are active and the configuration file 
> has a line like the following:
>
> vif = [ 'mac=00:16:3e:01:02:05,vifname=vm-fifth,ip=1.1.2.5' ]   // works for 
> linux pv
>
> vif = [ "mac=00:16:3e:01:02:06,vifname=vm-sixth,ip=1.1.2.6,model=e1000" ]
>    // used to work for hvm on modified 4.1, does not on unmodified 4.4
>
> ip_forwading is enabled in the host.
>
>
> That works for linux clients (there are actually two already running), but I 
> cannot get it to work with my windows HVM guest.
> Note that that worked with xen 4.1 and modified scripts and I still 
> have that server running, so I can compare network settings but I did not 
> find the source of the problem.
>
>
> What more details can I supply?
>

Maybe I'm missing something here, but perhaps this will help...

On dom0, create a second bridge with no interfaces in it, perhaps something 
like this:
auto xenbrdomU
iface xenbrdomU inet static
     address 1.1.2.1
     netmask 255.255.255.240

In the domU config, specify this second bridge:

vif = [ 
"mac=00:16:3e:01:02:06,vifname=vm-sixth,ip=1.1.2.6,model=e1000,bridge=xenbr5" ]

Then just use the normal bridged configuration, so all domU's are talking 
together on bridge xenbrdomU and dom0 is talking to the
rest of the net on eth0 or whatever interface you have. You will need to enable 
IP forwarding, and configure routing as per normal,
including the default route. All the domU's will use IP's on the subnet
1.1.2.0/255.255.255.240 and have default route set to 1.1.2.1

The only downside to this is that each domU can talk directly to another domU 
without the dom0 seeing that (not sure if you could
setup some filtering rules on the bridge or similar).

If you really needed to, create a separate bridge for each domU... only then 
you will waste 3 IP's for each domU (one network, one
broadcast, one for dom0).

As far as vif-route, sorry, never tried it so can't help there.

Regards,
Adam

--
Adam Goryachev Website Managers www.websitemanagers.com.au

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.