I opened bug 395 because of what I considered a regression in test007
compared to test005. The original message:
[EMAIL PROTECTED] ~]# uname -r
2.6.18-ovz028test007.1-smp
[EMAIL PROTECTED] ~]# vzctl start 114
Starting VE ...
VE is mounted
Setting CPU units: 1000
VE start in progress...
[EMAIL PROT
The kernel kernel-smp-2.6.18-ovz028test018.1 (and others before it)
has CONFIG_SECURITY and therefore CONFIG_SECURITY_CAPABILITIES turned
off. Unfortunately, quagga (zebra, actually) needs capabilities in at least
Fedora Core.
Would it be possible to enable CONFIG_SECURITY and make
CONFIG_SECURITY
>>>>> "BA" == Benny Amorsen <[EMAIL PROTECTED]> writes:
BA> Would it be possible to enable CONFIG_SECURITY and make
BA> CONFIG_SECURITY_CAPABILITIES a module in the standard OpenVZ
BA> kernel? Does OpenVZ fundamentally not work with capabilities?
Ah, a
[EMAIL PROTECTED] /]# service zebra start
Starting zebra: Nothing to flush.
privs_init: initial cap_set_proc failed
[FAILED]
This is with kernel-smp-2.6.18-ovz028test018.1 and quagga-0.98.6-2.1
from Fedora Core 6.
$ fgrep CONFIG_SECURITY
> "KK" == Kirill Korotaev <[EMAIL PROTECTED]> writes:
KK> No, it looks like you used non-OVZ config and disabled OVZ options
KK> like CONFIG_FAIRSCHED and CONFIG_SCHED_VCPU. So compilation
KK> failed. So this one is not related to zebra/capabilities.
$ egrep '(CONFIG_FAIRSCHED|CONFIG_SCHED_VC
> "KK" == Kirill Korotaev <[EMAIL PROTECTED]> writes:
KK> Ahh... I forget that CONFIG_SECURITY automatically disables
KK> CONFIG_VE due to: kernel/Kconfig.openvz: config VE bool "Virtual
KK> Environment support" default y depends on !SECURITY this! So
KK> if you remove this line it should
The solution is to simply:
for CAP in net_admin net_raw sys_admin; do vzctl set 114 --capability ${CAP}:on
--save ; done
It was http://forum.openvz.org/index.php?t=msg&goto=4214&; which got me
on the right track.
/Benny
___
Users mailing list
Users
> "BW" == Brian West <[EMAIL PROTECTED]> writes:
BW> The tools do not work on x86_64 and I feel that it must be
BW> addressed but it seems to be overlooked as of yet.
Indeed, it is most unfortunate.
What we do is run a 64-bit kernel with 32-bit userland. It isn't
perfect, but our guests only
> "BW" == Brian West <[EMAIL PROTECTED]> writes:
BW> Have you ever looked at sipXpbx? /b
If you find a way to run sipXpbx without the whole Java-based GUI, it
might be interesting. As it is, the memory requirements are just too
high for more than just a few virtual servers.
/Benny
___
> "GM" == Gregor Mosheh <[EMAIL PROTECTED]> writes:
GM> How stable is OpenVZ considered on 64-bit platforms, specifically
GM> Intel Xeons? I did some searches on the site, but couldn't find
GM> anything solid on the subject, only mention of "fixes"
GM> I ask because the tech who's setting up
> "GM" == Gregor Mosheh <[EMAIL PROTECTED]> writes:
GM> Sorry - I forgot to mention this probably-relevant fact: I have no
GM> intention of using vzrpm or vzyum.
GM> I prefer to work within the VE, so I'd either use "vzctl exec" or
GM> just enter the VE and run yum as usual.
That still leave
When I try to add a bonding device to a guest, I get this:
# /usr/sbin/vzctl set 114 --netdev_add bond0 --save
Saved parameters for VE 114
# /usr/sbin/vzctl start 114
Starting VE ...
VE is mounted
Unable to add netdev bond0: Invalid argument
VE start failed
Stopping VE ...
VE was stopped
VE is u
"H.H. Ding" <[EMAIL PROTECTED]>
writes:
> Can't It work like chroot but with more isolated environment?
Linux-vserver can do that. It does only minor virtualization of the
network, and stuff like routing tables stay in the host.
/Benny
___
Users mai
I'm trying to build a debuginfo kernel from
kernel-2.6.22-ovz005.1.src.rpm. I tried setting builddebuginfo to 1 in
the spec file, but that didn't give me any debuginfo packages.
What am I doing wrong?
/Benny
___
Users mailing list
Users@openvz.org
ht
Jan Tomasek <[EMAIL PROTECTED]> writes:
> I'm not sure, but I think that my setup is router independent. For my
> virtual servers I got prefix 2001:718:1:e::/64 (which is unbelivable
> waste of IP range but they say this is normal in IPv6).
Don't worry too much about address waste. E.g. every sin
I have struck a few problems compiling latest git (as of a few hours
ago). Some of the problems are due to the sanitization of kernel
headers, where it seems some openvz definitions have escaped out of
the #ifdef __KERNEL__ clause. Patch for those:
--- linux-2.6.24-openvz/include/linux/capability.
Starting VE 111: kobject 'eth0.111' cannot be renamed to 'eth0.111' as
'eth0.111' is already in existence.
WARNING: at net/core/dev.c:4179 __dev_change_net_namespace()
Pid: 25609, comm: vzctl Not tainted 2.6.24-ovz001ba.3 #1
Call Trace:
[] __dev_change_net_namespace+0x1f5/0x25a
[] :vzmon:real_ve
Gregor Mosheh <[EMAIL PROTECTED]> writes:
> My question is why you'd want to use both. What particular need or
> deployment scenario would require Xen and OpenVZ together?
This example is probably more typically done with VMWare today, but I
bet Xen would like a piece of the pie:
A company decla
"Michael H. Warfield"
writes:
> That doesn't make sense. IPv6 is a higher layer protocol. Switches
> will bridge and span based on MAC addresses on the link layer regardless
> of the IP layer version. I have yet to see a switch not pass native
> IPv6 properly (much less tunneled IPv6
Ade writes:
> My quesion is - is this on the roadmap to be addressed - looking at
> the date of this thread I guess its not. Thats a shame
vzpkg2 has solved all the problems I had with 64-bit guests. As a
result, we have switched to 64-bit guests. I am very grateful.
/Benny
___
Alastair Neil writes:
> Are there any guidelines on setting up a server that is multihomed? � I
> want to have VPS on different networks.� The two networks are partitioned
> by a firewall and the fact that ip_forward is turned on is I believe
> causing issues.� Doubtless there is some dee
Michael Stauber
writes:
> The exploit allows an unprivileged user to gain root access. However: The
> exploit (as is) *only* works on the master node. NOT inside a VE.
That is a very weak assurance. The failure of a specific implementation
of an attack means very little.
> Somehow the virtua
Josip Rodin writes:
> A lot of this namespace code was submitted into the mainline kernel by
> OpenVZ developers, so in a way they helped enable this. On the other hand
> the troubling bit for OpenVZ users may be the apparently missing link on
> this end - scarce movement in OpenVZ itself to ad
Suno Ano writes:
> I hate bridges therefore I use lxc.network.type = macvlan which is the
> equivalent to OpenVZ's venet device ... basically a pipe-like connection
> between container and host. No bridge involved. Imho a bride just
> complicates a setup and introduces an additional layer of in
Razvan Deaconescu
writes:
> Is it possible to use tc inside an OpenVZ container?
Yes that is definitely possible, at least with physical (VLAN)
interfaces in the guest, but I bet it can be done with venet too.
> I've tried using tc against the virtual network interface (venet) and
> a virtua
Dietmar Maurer writes:
> We use reasonable RAID controllers with BBU here. Such controller can handle
> > 1000 fsync/sec. So IMHO above argument does not count at all.
Can they though? I've seen SmartArray controllers with BBU delivering
just 5 synchronous IOPS when doing RAID-5. At first the
Razvan Deaconescu
writes:
> What are the relevant modules? There's no hint from the tc command when
> trying to add a rule, just an "Invalid argument" message.
Whichever of the sch_* modules you need. Normally they would autoload,
but nothing a guest does can cause an autoload in the host.
/
Razvan Deaconescu
writes:
> I've added all sch_* modules on the hardware node. I've restarted the
> OpenVZ container and tried running tc. It still doesn't work. Should
> only the sch_* modules be inserted?
I'm not sure what you mean by "only the sch_* modules".
We use tc extensively with the
Kir Kolyshkin writes:
> More to say, as you can see from [1], vzpkg and vzyum are
> unsupported/unmaintained. Users are expected to use
> precreated templates available from [2]. If you are
> not satisfied with available precreated template, you can
> repack those, or create your own from scratc
"Daniel Bauer" writes:
> Hello,
>
> I've several nics on the hostnode. Only the internal service nic have an
> internal IP. The other nics are without IPs and connected to different
> internal subnets and public www.
>
> I've read the differences between venet and veth
> http://wiki.openvz.org/Di
"Daniel Bauer" writes:
> One thing was, that nobody - only the HN - could change the IP for a
> CT. This issue couldn't be solved by VLAN or veth, so I thought to use
> venet.
I see your point, however techniques for isolating physical servers are
quite mature (e.g. firewall rules or ACL's in rou
31 matches
Mail list logo
