Ubuntu
ipvsadm package

Memory allocation problem with ipvsadm

Bug #1028585 reported by Stephen Murcott
36
This bug affects 6 people
Affects Status Importance Assigned to Milestone
ipvsadm (Ubuntu)
Confirmed
High
Unassigned

Bug Description

This looks like the bug listed here http://lists.openwall.net/netdev/2011/03/22/4 but I may be wrong. I have included as much information as possible to help make it clear.

I was able to replicate on 3 seperate clean installs of the following:

ubuntu-12.04-server-i386.iso with md5sum 32184a83c8b5e6031e1264e5c499bc03
(have reproduced on different kernels)

Linux lvs 3.2.0-27-generic-pae #43-Ubuntu SMP Fri Jul 6 15:06:05 UTC 2012 i686 i686 i386 GNU/Linux

Steps to reproduce:-

Setup - install ubuntu 12.04 i386 server with sshd
apt-get upgrade
reboot

enabled ipv4 forwarding
net.ipv4.ip_forward = 1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

aptitude install ipvsadm keepalived

ipvsadm -A -t $VIP:$PORT -s rr
Memory allocation problem

lsmod | grep vs
ip_vs_wrr 12615 0
ip_vs_wlc 12471 0
ip_vs_sh 12572 0
ip_vs_sed 12471 0
ip_vs_rr 12538 0
ip_vs_nq 12468 0
ip_vs_lc 12468 0
ip_vs_lblcr 12802 0
ip_vs_lblc 12747 0
ip_vs_ftp 13014 0
ip_vs_dh 12572 0
nf_nat 24959 3 ip_vs_ftp,ipt_MASQUERADE,iptable_nat
ip_vs 121543 24 ip_vs_wrr,ip_vs_wlc,ip_vs_sh,ip_vs_sed,ip_vs_rr,ip_vs_nq,ip_vs_lc,ip_vs_lblcr,ip_vs_lblc,ip_vs_ftp,ip_vs_dh
nf_conntrack 73847 5 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4,ip_vs
libcrc32c 12543 1 ip_vs

strace ipvsadm -A -t 192.168.122.21:80 -s -rr
execve("/sbin/ipvsadm", ["ipvsadm", "-A", "-t", "192.168.122.21:80", "-s", "-rr"], [/* 20 vars */]) = 0
brk(0) = 0x8cd1000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77ec000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=15720, ...}) = 0
mmap2(NULL, 15720, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77e8000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libpopt.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\30\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=47012, ...}) = 0
mmap2(NULL, 49804, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x768000
mmap2(0x773000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa) = 0x773000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libnl-genl-3.so.200", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\21\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=18460, ...}) = 0
mmap2(NULL, 21116, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xc5d000
mmap2(0xc61000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0xc61000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libnl-3.so.200", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200E\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=91856, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77e7000
mmap2(NULL, 94756, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xe5e000
mmap2(0xe74000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15) = 0xe74000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\226\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1713640, ...}) = 0
mmap2(NULL, 1723100, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x374000
mmap2(0x513000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19f) = 0x513000
mmap2(0x516000, 10972, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x516000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p[\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=124663, ...}) = 0
mmap2(NULL, 107008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x173000
mmap2(0x18a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16) = 0x18a000
mmap2(0x18c000, 4608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x18c000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/i386-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000D\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=173576, ...}) = 0
mmap2(NULL, 176256, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xea6000
mmap2(0xed0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x29) = 0xed0000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77e6000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77e5000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb77e56c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x513000, 8192, PROT_READ) = 0
mprotect(0xed0000, 4096, PROT_READ) = 0
mprotect(0x18a000, 4096, PROT_READ) = 0
mprotect(0xe74000, 4096, PROT_READ) = 0
mprotect(0xc61000, 4096, PROT_READ) = 0
mprotect(0x773000, 4096, PROT_READ) = 0
mprotect(0x8054000, 4096, PROT_READ) = 0
mprotect(0x171000, 4096, PROT_READ) = 0
munmap(0xb77e8000, 15720) = 0
set_tid_address(0xb77e5728) = 2297
set_robust_list(0xb77e5730, 0xc) = 0
futex(0xbf9f4ec4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, b77e56c0) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x178570, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x1785f0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys="Linux", node="lvs", ...}) = 0
brk(0) = 0x8cd1000
brk(0x8cf2000) = 0x8cf2000
open("/proc/net/psched", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77eb000
read(3, "000003e8 00000040 000f4240 3b9ac"..., 1024) = 36
close(3) = 0
munmap(0xb77eb000, 4096) = 0
time(NULL) = 1343125167
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, 16) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=2297, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=2297, groups=00000000}, [12]) = 0
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\20\0\5\3\257v\16P\371\10\0\0\3\1\0\0", 20}], msg_controllen=0, msg_flags=0}, 0) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"t\0\0\0\20\0\2\0\257v\16P\371\10\0\0\1\2\0\0\v\0\2\0nlctrl\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 1520
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\257v\16P\371\10\0\0\0\0\0\0\v\0\2\0nlctrl\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20
close(3) = 0
time(NULL) = 1343125167
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, 16) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=2297, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=2297, groups=00000000}, [12]) = 0
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\20\0\5\3\257v\16P\371\10\0\0\3\1\0\0", 20}], msg_controllen=0, msg_flags=0}, 0) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"t\0\0\0\20\0\2\0\257v\16P\371\10\0\0\1\2\0\0\v\0\2\0nlctrl\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 1520
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\257v\16P\371\10\0\0\0\0\0\0\v\0\2\0nlctrl\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\30\0\5\0\260v\16P\371\10\0\0\17\1\0\0", 20}], msg_controllen=0, msg_flags=0}, 0) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"$\0\0\0\30\0\0\0\260v\16P\371\10\0\0\16\1\0\0\10\0\1\0\1\2\1\0\10\0\2\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 36
close(3) = 0
time(NULL) = 1343125167
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, 16) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=2297, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=2297, groups=00000000}, [12]) = 0
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\20\0\5\3\257v\16P\371\10\0\0\3\1\0\0", 20}], msg_controllen=0, msg_flags=0}, 0) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"t\0\0\0\20\0\2\0\257v\16P\371\10\0\0\1\2\0\0\v\0\2\0nlctrl\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 1520
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\257v\16P\371\10\0\0\0\0\0\0\v\0\2\0nlctrl\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"h\0\0\0\30\0\5\0\260v\16P\371\10\0\0\1\1\0\0T\0\1\0\6\0\1\0\2\0\0\0"..., 104}], msg_controllen=0, msg_flags=0}, 0) = 104
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"|\0\0\0\2\0\0\0\260v\16P\371\10\0\0\376\377\377\377h\0\0\0\30\0\5\0\260v\16P"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 124
close(3) = 0
write(2, "Memory allocation problem\n", 26Memory allocation problem
) = 26
exit_group(-1) = ?

Revision history for this message
Stephen Murcott (scmurcott) wrote :

I basically worked around this issue by doing the following on the same server:-

aptitude purge ipvsadm

aptitude install git-core build-essential autoconf automake autotools-dev dh-make debhelper devscripts fakeroot libpopt-dev libnl-dev dpatch

mkdir tmp && cd tmp

git clone git://github.com/formorer/pkg-ipvsadm.git

cd pkg-ipvsadm

dpkg-buildpackage -rfakeroot
cd ..
dpkg -i ipvsadm_1.25_i386.deb
dpkg-reconfigure ipvsadm
ipvsadm -A -t $VIP:$PORT -s rr

working layer 4 lb.

Serge Hallyn (serge-hallyn)
Changed in ipvsadm (Ubuntu):
importance: Undecided → High
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Cannot reproduce on Quantal.

$ sudo ipvsadm -A -t 10.248.8.73:80 -s rr
$

ipvsadm:
  Installed: 1:1.26-1ubuntu1
  Candidate: 1:1.26-1ubuntu1
  Version table:
 *** 1:1.26-1ubuntu1 0
        500 http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages
        100 /var/lib/dpkg/status

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Also could not reproduce on precise. I notice though that both systems have been amd64 so perhaps this is specific to i386.

Revision history for this message
Stephen Murcott (scmurcott) wrote : Re: [Bug 1028585] Re: Memory allocation problem with ipvsadm
Download full text (12.3 KiB)

I filed it for i386 did not test on 64bit... I did not see why a tiny pair
of ipv4 load balancers would need 64bit arch.

On Sun, Aug 5, 2012 at 2:24 AM, Clint Byrum <email address hidden> wrote:

> Also could not reproduce on precise. I notice though that both systems
> have been amd64 so perthaps this is specific to i386.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1028585
>
> Title:
> Memory allocation problem with ipvsadm
>
> Status in “ipvsadm” package in Ubuntu:
> New
>
> Bug description:
> This looks like the bug listed here
> http://lists.openwall.net/netdev/2011/03/22/4 but I may be wrong. I
> have included as much information as possible to help make it clear.
>
> I was able to replicate on 3 seperate clean installs of the following:
>
> ubuntu-12.04-server-i386.iso with md5sum 32184a83c8b5e6031e1264e5c499bc03
> (have reproduced on different kernels)
>
> Linux lvs 3.2.0-27-generic-pae #43-Ubuntu SMP Fri Jul 6 15:06:05 UTC
> 2012 i686 i686 i386 GNU/Linux
>
> Steps to reproduce:-
>
> Setup - install ubuntu 12.04 i386 server with sshd
> apt-get upgrade
> reboot
>
> enabled ipv4 forwarding
> net.ipv4.ip_forward = 1
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> aptitude install ipvsadm keepalived
>
> ipvsadm -A -t $VIP:$PORT -s rr
> Memory allocation problem
>
> lsmod | grep vs
> ip_vs_wrr 12615 0
> ip_vs_wlc 12471 0
> ip_vs_sh 12572 0
> ip_vs_sed 12471 0
> ip_vs_rr 12538 0
> ip_vs_nq 12468 0
> ip_vs_lc 12468 0
> ip_vs_lblcr 12802 0
> ip_vs_lblc 12747 0
> ip_vs_ftp 13014 0
> ip_vs_dh 12572 0
> nf_nat 24959 3 ip_vs_ftp,ipt_MASQUERADE,iptable_nat
> ip_vs 121543 24
> ip_vs_wrr,ip_vs_wlc,ip_vs_sh,ip_vs_sed,ip_vs_rr,ip_vs_nq,ip_vs_lc,ip_vs_lblcr,ip_vs_lblc,ip_vs_ftp,ip_vs_dh
> nf_conntrack 73847 5
> ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4,ip_vs
> libcrc32c 12543 1 ip_vs
>
> strace ipvsadm -A -t 192.168.122.21:80 -s -rr
> execve("/sbin/ipvsadm", ["ipvsadm", "-A", "-t", "192.168.122.21:80",
> "-s", "-rr"], [/* 20 vars */]) = 0
> brk(0) = 0x8cd1000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb77ec000
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=15720, ...}) = 0
> mmap2(NULL, 15720, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77e8000
> close(3) = 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> open("/lib/i386-linux-gnu/libpopt.so.0", O_RDONLY|O_CLOEXEC) = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\30\0\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0644, st...

Revision history for this message
Ralf Spenneberg (ralq) wrote :

I can confirm it on amd64 using
ipvsadm 1.25.clean-1ubuntu5
linux-image-3.2.0-23-generic and linux-image-3.2.0-29-generic

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ipvsadm (Ubuntu):
status: New → Confirmed
Revision history for this message
Ralf Spenneberg (ralq) wrote :

Further information:
ipvsadm -A -t 192.168.10.21:80 -s rr
works, while
ipvsadm -A -t 192.168.10.21:80 -s -rr
(obviously wrong syntax) creates a memory allocation error.

Apparently whenever a syntax or semantic error occurs ipvsadm generates an memory allocation error.

So generate a virtual server:
ipvsadm -A -t 10.131.208.21:80 -rr
Add a real server with masquerading:
ipvsadm -a -t 10.131.208.21.80 -r 192.168.0.5 -w 1 -m
Edit the real server without specifying the -m
ipvsadm -e -t 10.131.208.21.80 -r 192.168.0.5 -w 0 -m
memory allocation problem
ipvsadm -e -t -t 10.131.208.21.80 -r 192.168.0.5 -w 0 -m
works.

Apparently syntactical errors always generate a memory allocation error.

Revision history for this message
Peter Matulis (petermatulis) wrote :

@Ralf

1. "Edit the real server without specifying the -m"

ipvsadm -e -t 10.131.208.21.80 -r 192.168.0.5 -w 0 -m

But you did specify the -m ^^^

"ipvsadm -e -t -t 10.131.208.21.80 -r 192.168.0.5 -w 0 -m
works."

"-t -t" ?

Really?

Revision history for this message
Peter Matulis (petermatulis) wrote :

This is what I'm seeing:

$ sudo ipvsadm -Ln

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.100:80 wrr
  -> 192.168.1.101:8080 Masq 1 0 0
  -> 192.168.1.102:8080 Masq 1 0 0
  -> 192.168.1.103:8080 Masq 1 0 0

$ sudo ipvsadm -e -t 192.168.0.100:80 -r 192.168.1.103:8080 -w 0
Memory allocation problem

Revision history for this message
Peter Matulis (petermatulis) wrote :

Ah, I needed to specify the -m !

$ sudo ipvsadm -e -t 192.168.0.100:80 -r 192.168.1.103:8080 -m -w 0

This works.

Revision history for this message
Joel (joel-forsberg) wrote :

After having set up a LVS-DR, I get this while trying to list a particular service on 14.04

ipvsadm -L -t ip.of.ser.vice

Revision history for this message
Joel (joel-forsberg) wrote :

actually, forget my comment. That was my mistake omitting service port.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.