OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Talk:NFS doesn't work

2007-06-26T21:41:03Z

Master: New page: Start portmap on the client? --~~~~

Start portmap on the client? --[[User:Master|Master]] 17:41, 26 June 2007 (EDT)

User:Master

2007-06-13T17:32:19Z

Master:

I'm using OpenVZ on [[x86]] and on [[sparc]]. I've build an image for [sparc] that can be found on
[http://openvz.i88.de http://openvz.i88.de]

User:Master

2007-06-13T17:31:35Z

Master:

I'm using OpenVZ on [x86] and on [sparc]. I've build an image for [sparc] that can be found on
[http://openvz.i88.de http://openvz.i88.de]

User:Master

2007-06-13T17:31:15Z

Master: New page: I'm using OpenVZ on [x86] and on [sparc]. I've build an image for [sparc] that can be found on [[http://openvz.i88.de http://openvz.i88.de]

I'm using OpenVZ on [x86] and on [sparc]. I've build an image for [sparc] that can be found on
[[http://openvz.i88.de http://openvz.i88.de]

Porting the kernel

2007-06-13T17:26:59Z

Master:

OpenVZ kernel supports x86, x86_64, IA64, power64, and [[sparc]] architectures as of now. Below are the quick and dirty information about how to port the kernel to yet another architecture.

* UBC: need to account any platform specific VMAs created by hand in arch specific code. i.e. if there are calls of <code>insert_vm_struct()</code> this should be accounted with <code>ub_memory_charge()</code>. Didn't find such thing on sparc64.

* If there are user triggerable <code>printk()</code>'s (related to the user, not the system as a whole) better replace them with <code>ve_printk()</code>. Otherwise user can flood (DoS). minor actually.

* Call to functions <code>find_task_by_pid()</code>, <code>for_each_process()</code> and <code>do_each_thread()</code>/<code>while_each_thread()</code> should be replaced with it's counterparts - <code>find_task_by_pid_XXX()</code>, <code>for_each_process_XXX()</code> and <code>do_each_thread_XXX()</code>/<code>while_each_thread_XXX()</code>, where <code>XXX</code> is either <code>all</code> or <code>ve</code>. Here <code>all</code> means that all system processes in the system will be scanned, while <code>ve</code> means that only the [[VE]] accessible from this task (current context - <code>get_exec_env()</code>) will be visible. So you need to decide whether the code in question is about system or user context.

* <code>task->pid</code> should be changed with <code>virt_pid(task)</code> in some places. The rule is simple: user should see only virtual pids, while kernel operate on global pids. e.g. in signals, virtual pid should be delivered to app.

* In interrupt handlers one need to set global host ([[VE0]]) context. i.e. <code>set_exec_env()</code>, <code>set_exec_ub()</code>. i.e. interrupt handlers are running in VE0 context.

* In <code>kernel_thread()</code> one needs to prohibit kernel threads in VE. Mostly security related...

* Extend <code>show_registers()</code> (or <code>show_regs()</code>) to show current VE.

* <code>utsname</code> should be virtualized. This mostly means that <code>system_utsnames</code> should be replaced with <code>ve_utsname</code>. See any arch code for this.

* Some exports will be required. e.g. <code>show_mem()</code> and probably <code>cpu_khz</code>. Easy.

* Everything else are bugfixes.

All these are straightforward and really simple, so it should take a few hours to do.

== External links ==
* [http://forum.openvz.org/index.php?t=msg&goto=3338&&srch=sparc#msg_num_5 Original forum post]

[[Category: Kernel]]
[[Category: Development]]
[[Category: Internals]]

Sparc

2007-06-13T17:26:18Z

Master: New page: Ready to use OpenVZ kernel 2.6.18 images for debian on sparc (Ultra10) can be found on: <br> [http://openvz.i88.de http://openvz.i88.de]

Ready to use OpenVZ kernel 2.6.18 images for debian on sparc (Ultra10) can be found on: <br>
[http://openvz.i88.de http://openvz.i88.de]

Kernel configuration

2007-06-12T22:22:56Z

Master: /* OpenVZ related kernel config options */

This article summarises various kernel configuration issues.

== OpenVZ related kernel config options ==

Please make sure the following config options are enabled
in your kernel .config file before compilation process:
CONFIG_SCHED_VCPU=y
CONFIG_FAIRSCHED=y

CONFIG_SIM_FS=m
CONFIG_VZ_QUOTA=m
# CONFIG_VZ_QUOTA_UNLOAD is not set
CONFIG_VZ_QUOTA_UGID=y

CONFIG_VE=y
CONFIG_VE_CALLS=m
CONFIG_VZ_GENCALLS=y
CONFIG_VE_NETDEV=m
CONFIG_VE_ETHDEV=m
CONFIG_VZ_DEV=m
CONFIG_VE_IPTABLES=y
CONFIG_VZ_WDOG=m
CONFIG_VZ_CHECKPOINT=m #(CONFIG_VZ_CHECKPOINT=n on sparc)

== ACPI sleep ==

It is a bit tricky to make ACPI sleep and OpenVZ work together.

ACPI sleep is enabled by <code>ACPI_SLEEP</code> kernel option. The following dependencies are declared in kernel configs:

ACPI_SLEEP depends on X86 && (!SMP || SUSPEND_SMP)
SUSPEND_SMP depends on HOTPLUG_CPU && X86 && PM
FAIRSCHED depends on SCHED_VCPU

And <code>SCHED_VCPU</code> is incompatible with <code>HOTPLUG_CPU</code>:

./kernel/cpu.c:#error "CONFIG_HOTPLUG_CPU isn't supported with CONFIG_SCHED_VCPU"

On non-SMP machine, you may disable <code>SMP</code>, this will resolve the conflict.

If you have SMP machine, you can only disable <code>FAIRSCHED</code> and <code>SCHED_VCPU</code>. This will loose some isolation between VEs (CPU scheduling will be performed per-task, not per-VE, and <code>cpuunits</code> and <code>cpulimit</code> settings will not take effect), but it is acceptable solution if your VEs are trusted (and it's hard to imagine untrusted VEs on a notebook ;)

[[Category:Kernel]]
[[Category:HOWTO]]