headers
gen2 | 1 May 01:54

Re: domU network falling asleep SOLVED

gen2 wrote:
> Hi there,
> 
> One of my dom0's has taken to tcp sleeping, where an ssh session will 
> just freeze up, as though paused. "Nudging" the stack with tcpdump (or 
> other network activity) on another terminal wakes up the the first 
> terminal. Then it's all back to normal, for a varying amount of time 
> (4-30 minutes) til the console goes to sleep again, and it "freezes". 
> Happens to all the open consoles at once, except for the one accessed 
> via "xm console <domU>".
> 
> Any pointers as to where I should start digging?
> 
> Many Thanks!
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users <at> lists.xensource.com
> http://lists.xensource.com/xen-users
> 

had 2 domU's assigned the same mac address...DOH!
Permalink | Reply | 0 comments |
headers
Petersson, Mats | 1 May 12:38
Picon

RE: X86_64 and 4GB RAM

John, 

> any ideas on where to go from here?
> Is it normal for it to only show
> Upper memory (to first chipset hole): 3144640K
> at the grub boot menu?

What revision of processor do you have, and how large is your graphics
memory? 

If you have a graphics card that eats a fair bit of memory (256 or
512MB) on a processor that doesn't support "memory hoisting"[1] (i.e.
remapping of "behind PCI memory" to a higher address), then I wouldn't
be surprised if you don't see more than 3.x GB - the reason being that
the rest of the memory is "behind" the PCI bus devices. 

Processors from Rev E has a more "flexible" memory hoisting
functionality, where there is a proper "set of memory hole registers". 

Also, if you have a newer processor you may need a new BIOS to support
this, and you'll possibly also need to enable "memory hoisting" (or
memory hole or some such) in the BIOS setup. 

[1] All processors do have a form of memory hoisting using the
"chipselect" method, however, this is only possible to use under certain
conditions, and it's limited to moving a whole chipselect-bank at a time
[which in your case may be 1-2GB, and the BIOS may deem it better to
leave a few hundred MB below 32-bit than to move a whole heap of 1 or
2GB above the 4GB boundary - particularly since a majority of users
still prefer to use 32-bit OS's that can't get past 4GB!].
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Hannfield | 1 May 12:52
Picon

Re: X86_64 and 4GB RAM

Hi Mats

> What revision of processor do you have, and how large is your graphics
> memory?

The system has 2 dual core Opteron 2210's in it.
cat /proc/cpuinfo

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 65
model name      : Dual-Core AMD Opteron(tm) Processor 2210
stepping        : 2
cpu MHz         : 1800.283
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm
cr8_legacy
bogomips        : 3604.24
TLB size        : 1024 4K pages
(Continue reading)

Permalink | Reply | 1 comment |
headers
Petersson, Mats | 1 May 13:45
Picon

RE: X86_64 and 4GB RAM


> -----Original Message-----
> From: John Hannfield [mailto:hal9020 <at> gmail.com] 
> Sent: 01 May 2007 11:53
> To: Petersson, Mats
> Cc: xen-users <at> lists.xensource.com
> Subject: Re: [Xen-users] X86_64 and 4GB RAM
> 
> Hi Mats
> 
> > What revision of processor do you have, and how large is 
> your graphics
> > memory?
> 
> The system has 2 dual core Opteron 2210's in it.

Ah, yes that is a Rev F, so it definitely allows memory hoisting. 

> cat /proc/cpuinfo
> 
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 15
> model           : 65
[snip]
> 
> 
> > If you have a graphics card that eats a fair bit of memory (256 or
> > 512MB) on a processor that doesn't support "memory 
> hoisting"[1] (i.e.
(Continue reading)

Permalink | Reply | 0 comments |
headers
François Lapointe | 1 May 13:45
Picon

NetBSD DomU PCI device

Hello List,

  I'm trying to use a pci device in a NetBSD 3.1 DOMU under Xen
3.0.4-1. The domain boots normally, but I can't get the kernel to
compile to add support for this specific network card. Here is the
custom config file :

*********************************
include "arch/i386/conf/XEN3_DOMU"

pci* at hypervisor? bus ?
ep* at pci? dev ? function ?        # that's a 3com 3c59x
****************

"config" and "make depend" complete without error. The following is
the output when I perform "make". Am I missing something?

*********************************
#   compile  PERU/xen_bus_dma.o
cc -ffreestanding -g -O2 -march=i686 -Werror -Wall -Wno-main
-Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes
-Wstrict-prototypes -Wno-sign-compare -fno-zero-initialized-in-bss
-Di386 -I. -I/usr/src/sys/arch/i386/compile/PERU/xen-ma
-I../../../../arch -I../../../.. -nostdinc -DMAXPHYS=32768 -DLKM
-DDIAGNOSTIC -DDEBUG -DCOMPAT_30 -DMAXUSERS=32 -D_KERNEL -D_KERNEL_OPT
-I../../../../dist/ipf -c ../../../../arch/xen/x86/xen_bus_dma.c
../../../../arch/xen/x86/xen_bus_dma.c: In function `_xen_alloc_contig':
../../../../arch/xen/x86/xen_bus_dma.c:102: warning: implicit
declaration of function `HYPERVISOR_dom_mem_op'
../../../../arch/xen/x86/xen_bus_dma.c:102: error:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fong Vang | 2 May 01:33
Picon

iptables and ipvsadm in domU

The documentation for Xen mentions that iptables in dom0 may affect domUs.  If iptables and ipvsadm is heavily used in a domU, how does this impact dom0?

In my particular case, I want both dom0 and ONE domU (FW_domu) to be visible to the external network (eth1).  There will be several other domU's that will be behind FW_domU).  

as far as the domUs are concerned, this is the layout.

       FW_domU
          |
       LB_domU
          |
    +-----+--+--------+
    |        |        |
    domU1    domU2   domU3

what's the best way to set this up.  LB_domU runs LVS (ipvsadm).  Is this configuration even supported in Xen.

Thanks for any help.

_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Permalink | Reply | 2 comments |
headers
Matthew Palmer | 2 May 02:31
Favicon

Re: iptables and ipvsadm in domU

On Tue, May 01, 2007 at 04:33:02PM -0700, Fong Vang wrote:
> The documentation for Xen mentions that iptables in dom0 may affect
> domUs.  If iptables and ipvsadm is heavily used in a domU, how does this
> impact dom0?

Depends on how your network is setup.

> In my particular case, I want both dom0 and ONE domU (FW_domu) to be visible
> to the external network (eth1).  There will be several other domU's that
> will be behind FW_domU).
> 
> as far as the domUs are concerned, this is the layout.
> 
>       FW_domU
>          |
>       LB_domU
>          |
>    +-----+--+--------+
>    |        |        |
>    domU1    domU2   domU3
> 
> what's the best way to set this up.  LB_domU runs LVS (ipvsadm).  Is this
> configuration even supported in Xen.

It's supported, but complex.  You're going to have to know an awful lot
about bridging, routing, and such to be able to set this up and keep it
running in any sort of good order.  If I were consulting on this, I'd
question the underlying assumptions that have led to this design first, as
there's probably some much simpler way of laying it all out.  But the
diagram above, if given as a virtual network layout, is certainly doable, if
perhaps not optimal.

You can certainly run both iptables and ipvsadm in a Xen domU; it's been an
integral part of one of my clients' setups for about 9 months now, and it
works a treat.

- Matt

--

-- 
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
Permalink | Reply | 0 comments |
headers
Chris Wright | 2 May 02:39

[ANNOUNCE] paravirt_ops i686 Fedora rawhide kernel packages

If you are interested in trying the new paravirt_ops kernels, I've
created some packages and uploaded them to:

  http://et.redhat.com/~chrisw/paravirt_ops/

There you'll find a yum repo (see yum.README for details) and an
INSTALL file for getting started.  With this package you can use a
single kernel[1] for both native (w/out a hypervisor, or under a full
virt hypervisor), domU paravirt under Xen, and a VMI guest.  There is no
support for dom0 kernels ATM.  Running the kernel native is as simple as
installing and rebooting.  However, it requires some manual intervention
to get a domU started (see INSTALL for details).

thanks,
-chris

[1] It's not quite a single kernel.  It's two separate binaries built from
the identical vmlinux.  This is due to the Xen domain builder's inability
to boot a bzImage format kernel binary.  Fixing this is on the todo list.
Permalink | Reply | 0 comments |
headers
Tim Post | 2 May 04:40

Re: iptables and ipvsadm in domU

On Tue, 2007-05-01 at 16:33 -0700, Fong Vang wrote:
> The documentation for Xen mentions that iptables in dom0 may affect
> domUs.  If iptables and ipvsadm is heavily used in a domU, how does
> this impact dom0?
> 
> In my particular case, I want both dom0 and ONE domU (FW_domu) to be
> visible to the external network (eth1).  There will be several other
> domU's that will be behind FW_domU).   
> 
> as far as the domUs are concerned, this is the layout.
> 
>        FW_domU
>           |
>        LB_domU
>           |
>     +-----+--+--------+
>     |        |        | 
>     domU1    domU2   domU3

I would combine the FW and LB. If this is just http/https load balancing
try pound first, http://apsis.ch/pound/ . You will end up with far less
moving parts that can break. Since this is all on one physical server,
anyway, there isn't much sense in breaking them up. 

I'm not saying what you sketched won't work though. With only 3 nodes
you shouldn't run into too much spaghetti. Odd breakage happens more
when you have more nodes, and more NATing around the LB directly to the
guests.

Were you going to use a popular FW helper like Shorewall, or put
something together yourself? Did you figure on using two bridges?

> what's the best way to set this up.  LB_domU runs LVS (ipvsadm).  Is
> this configuration even supported in Xen.

Sure, as long as there is modular support for everything you want to do
(and corresponding modules to load) on the dom-u for iptables, its no
different than anything else for most purposes.

Good luck :)
--Tim
Permalink | Reply | 0 comments |
headers
sagnik dhar | 2 May 05:26
Picon

VNC to a vm

Hello everybody,

I am quite new to Xen and im running Xen on Ubuntu Dapper. I want to VNC into a VM(domU) from a machine on the local LAN. I have assigned a dummy interface so that i can use that IP address as my VM's IP. The output of ifconfig is:

sagnik <at> sagnik-desktop:~$ ifconfig
dummy0    Link encap:Ethernet  HWaddr 7E:3A:16:C5:2E:91
          inet addr:192.168.3.1  Bcast:192.168.3.255   Mask:255.255.255.0
          inet6 addr: fe80::7c3a:16ff:fec5:2e91/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:210 (210.0 b)

eth0      Link encap:Ethernet  HWaddr 00:13:20:78:92:A0
          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::213:20ff:fe78:92a0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1343 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1487 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1069413 (1.0 MiB)  TX bytes:351076 (342.8 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:272 (272.0 b)  TX bytes:272 (272.0 b)

But when i try to execute the command vncviewer and give this IP, i get an error message "tcp connection refused".

Am i going wrong in the method for assigning IPs itself ? If yes, please help me out.

Thanks for the help.

Regards,
Sagnik

_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Permalink | Reply | 0 comments |

Gmane