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

Re: [Xen-users] DomU's unable to connect to vnet0 / bridge

  • To: Xen User-List <xen-users@xxxxxxxxxxxxxxxxxxx>
  • From: "Fajar A. Nugraha" <fajar@xxxxxxxxx>
  • Date: Wed, 17 Jun 2009 08:22:04 +0700
  • Delivery-date: Tue, 16 Jun 2009 18:22:46 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

On Wed, Jun 17, 2009 at 2:56 AM, <cyber@xxxxxxxxxxxxxxxxxxx> wrote:
> I'm working now.  I talked with one of the NOC nerds here at work and he had
> JUST fought through the same problems the previous weekend so had the
> solution at hand.  In the end, it seems that the XEN bridge scripts for RHEL
> 5.3 will ONLY work for ETH0.

If it's true, that would be a bug, and you should use RHN to report
that. After all, that's what you're paying RHEL support for isn't it?

>  I made a number of changes along the way, so
> I'm not 100% sure exactly which modifications were required to get things
> working, but this is the best guess at the mods made that got me working:
> 1)  Switched over my named.conf to only listen on lo, eth0, and eth1.
> 2)  Set dnsmasq.conf to only listen on vnet1 and exclude lo, eth0, and eth1.

I'm actually confused to read this. What's vnet1? xen on RHEL only
create xenbr0 and virbr0 by default. Did you create your own bridge?

> 3)  Set the network-bridge script to have hardcoded values for:
>    vifnum=1
>    bridge=xenbr1
>    netdev=eth1
> 4)  Uncomment the line for the network-bridge device in the
>    xend-config.sxp script:
>    [root@cerberus xen]# grep eth1 xend-config.sxp
>    # To use a different one (e.g. eth1) use
>    (network-script 'network-bridge netdev=eth1')

This should be the right way to create bridge over eth1. But I see
you've hardcoded the values anyway :)

> 6)  Give up on trying to use dnsmasq or dhcpd for DHCP on the VMs and just
>    hardcode them for static IP's in 10.0.2.xxx space.
> It seems my attempts to use 192.168.122.xxx for the VM space (as explained
> to me) was unnecessary, as I could ignore that and just use my 10-net for
> the VMs... is the default address space for virbr0. If you want
to use it, you can simply put your domUs on virbr0 and it should just
work without any additional config. dnsmasq already configure as DNS
and DHCP server, and iptables NAT rule already created.

> I've got one CentOS and one Windows Server 2003 VMs currently running, and
> all seems to be well.  I would have been nice if there was some sort of
> how-to doc on the wiki (I searched and was unable to find anything) for
> switching over from eth0 over to an eth1 config, but maybe that's not as
> common of a configuration as I thought it might have been.  {shrug}

... and since you use RHEL reading their doc wont hurt either.

In my case I gave up xen's default bridge a long time ago (had some
problems back in the days of Xen 3.0), so I create my bridges manually
using /etc/sysconfig/network-scripts/ifcfg-*

>> From what I hear, RHEL / CentOS will be moving away from XEN and moving
> over to KVM (this was new news for me, certainly way old for y'all tho I'm
> guessing) so who knows...  maybe with the 5.4 updates (or maybe RHEL 6)

RH should still support Xen for the lifetime of RHEL 5.x. Don't know
about RHEL6 though.

> it'll all be moot anyway...  I certainly like the performance of XEN and am
> not looking forward to a VM akin to VMWare (which it seems KVM is more akin
> to)

If I understand correctly, several reasons for the move is that :
- KVM is more integrated with Linux (whereas Xen dom0 support is not
yet integrated in vanilla kernel)
- newer pv_ops kernel should be able to detect KVM environment, and
avoid using "expensive" instructions, which should lead to comparable
performance (cpu-wise) to that of Xen PV.
- PV drivers should reduce I/O performance penalty, which (ideally)
should lead to comparable performance (I/O-wise) to that of Xen PV
- CPUs with hardware virtualization support is quite common nowadays

In any case you could still use Xen as long as you like. Note that
opensolaris also uses Xen, so that could be an alternative if you want
OS-supported Xen version in the future.


Xen-users mailing list



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