Re: NetBSD domU and the real server

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Dirk H. Schulz wrote:
> Hi folks,
>
> I have stumbled across something that is new to me with NetBSD.
>
> I have setup  domUs with  NetBSD5 on two dual Pentium III servers with 
> Debian5 dom0. When I copy them to a single Xeon 2.8 GHz machine running 
> a Debian5 dom0 and run them there, they dom0 kernel crashes within a few 
> hours; that is reliably reproducable.

What kind of crash? You got a stacktrace from either Xen or Linux?

> When I setup new NetBSD5 domUs on the Xeon machine and run them, the 
> Debian5 dom0 runs fine.
>
> I do not have the same problem with Debian5 domUs on these servers; I 
> have setup several on the Pentium III servers and run them on the Xeon 
> machine without such a problem.

Something is really wrong in the Debian's dom0 then. From a security 
point of view, it is unacceptable (though, not 100% avoidable - bugs, 
you know) that an unprivileged domain (domU) can reliably crash the dom0.

> Does the NetBSD installer configure the domU for a certain hardware?
> Do I have to template domUs for every major intel architecture?
- No
- No

> And if yes, 
> does that depend only on the processor(s) or the chip sets as well?
> Or is it just a problem when transferring the domU from a multi 
> processor to a single processor system?

No

> Any hint or help is appreciated?

I am assuming you are not using PCI passthru, or HVM.

domU is completely hardware independent, except for the machine arch 
(x86). It is expected to be completely isolated (by design) from the 
hardware, and cannot access devices, chipsets, or memory. Literally 
everything has to go and get validated through dom0 and/or Xen.

dom0 is critical in regards to security, and must remain 100% reliable 
even in cases where domU is crippled (security by isolation). If it 
crashes because of a domU, it is clearly buggy, and makes assumption on 
a state or condition it should not to.

Faulty hardware may be a source of problem too.

Without further information, it is hard to tell. A good start would be a 
stacktrace, xm dmesg, or Xen console output.

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost