Erik Fair <fair%netbsd.org@localhost> writes: > If one were setting up a system with Xen to virtualize multiple NetBSD > guest instances and no other OS, what version of the Xen hypervisor > kernel, and which xen management tools are best, where “best” is: A somewhat tough question. I will assume you are talking netbsd-6 for the dom0. netbsd-7 is almost certainly ok, too, but I tend to be conservative abotu dom0 code. I recommend amd64 for the dom0, partially due to xentools42 building issues (below) and partly because I think that's the normal path these days. Note that modern xen is all PAE for i386. So you can use the i386 XEN3PAE_DOMU kernel, or amd64. PCI passthrough is a recurring problem. If you don't need it, don't worry. In the howto, note that boot.cnf lets you boot xen with our bootloader, and you don't need to deal with grub. man boot.cfg has an example. > They work. > > They’re being actively worked on for bugs/improvements, not abandon ware. The versions in pkgsrc seem to be a bit behind what the upstream xen project is using. However, 4.1 and 4.2 are getting security bugfixes (via backporting, sometimes). xen 3.1 and 3.3 are really only of historical interest at this point, or for people that are still running them and haven't upgraded. Given all that, I would say that you should choose from pkgsrc/sysutils/xenkernel41 pkgsrc/sysutils/xenkernel42 and then install the matching xentools. On 4.1, I am using "xm", but that is deprecated and "xl" is recommended; it may be the only way on 4.2. I have found that xenkernel42 does not build on netbsd-6 i386 due to compiler issues with the included qemu. (It needs qemu to support HVM mode.) For a new install, I would recommend 4.2. > They perform well (i.e. the hypervisor and associated toolset impose minimum overhead on the guest OSes). That's not really been a big issue; overheads are reasonable and not particularly different from ersion to version. If you care about overhead, I'd recommend running PV guests. The biggest performance issue will be how you provide storage on the dom0 to hand to domU via xdb. I tend to have files in the dom0, which has some overhead vs raw disk (< 10% usually), and then there is some speed loss from e.g domU rxbd0e to the dom0 file, again < 10%. Your other likely big issue will be having enough memory so that each domU has enough not to page and you don't run out. But if you stay away From that problem, it should work well.
Attachment:
pgpolwVXu7i7e.pgp
Description: PGP signature