Thanks to all. This explicitly clarifies what is often assumed but
never actually stated. Once read it makes perfect sense, but until you
hear some one say it, there's always some doubt.
On Fri, Jun 11, 2010 at 5:31 AM, Fajar A. Nugraha <fajar@xxxxxxxxx> wrote:
> On Fri, Jun 11, 2010 at 1:40 AM, Bruce Edge <bruce.edge@xxxxxxxxx> wrote:
>> I read that this is one of the benefits of pv-ops,
> Actually, domU can use dom0's kernel whether it's -xen kernel or pv_ops
> The different with pv_ops is that it can also be used to boot native
> (non-xen) or full-virtualization.
>> but is it really good
>> practice to use the same kernel options for both dom0 and domUs?
> Depends on what you need, and who you ask.
> As an illustration, Redhat uses the same kernel-xen rpm for both dom0
> and domU. The benefit is that you only have to maintain small number
> of kernel package (only kernel and kernel-xen).
> Ubuntu, on the other hand, have several different kernel package for
> different purposes. linux-image-server is the general kernel package
> suitable for common server purposes. However, there's also
> linux-image-virtual, which contains much fewer modules and suitable
> for domU/HVM kernel, thus can result to smaller installation size and
> (slightly) faster boot times (due to the smaller initrd).
>> If not, what options should differ between dom0 and domU pv-ops kernels?
>> I'm using jeremy's 2.6.32.x tree and dom0/domU are ubuntu 10.04.
> If you want to go with "smallest kernel possible for commonly used PV
> domU" then you could start by excluding most drivers (disk, network,
> multimedia, etc.). PV domU's hardware is pretty common, so you should
> only need drivers for Xen frontend disk, network, console, and
> (optionally) virtual frame buffer.
> If you want to reduce it even further, you can also remove some packet
> filtering support. I usually have dedicated firewall box or
> specialized domUs for firewall, so most of my domUs won't need packet
> filtering support. Same thing goes with raid (as I usually do raid in
> dom0 or hadware).
> Then you can also remove xen dom0 and backend support, although I'm
> not sure how big the size reduction would be for this one.
Xen-users mailing list