Date: Fri, 4 Mar 2011 14:12:26 +0000 From: Dr Josef Karthauser <joe@tao.org.uk> To: freebsd-xen@freebsd.org Subject: Xen, and "ops_pv" boot loader? Message-ID: <7F0BEDC0-D2F5-45C1-8DE2-DF89622D42D0@tao.org.uk> References: <F4158AD6-D194-4BF6-B92E-1A121805EA22@unitedlane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello everyone, I'm beginning to play with Freebsd and Xen, and I'm targeting a VPS provider who is giving me a large memory instance for a good price. However, he only supports "ops_pv" kernels, being primarily a linux house. So, I'm trying to work out what the best approach is. Ideally I'd be running amd64, but he doesn't want to run an hvmloader. I guess that means that I need to be running an i386 kernel; hopefully PAE works so that I take advantage of the memory. However, this appears to be an inflexible solution. Doesn't it mean that I will have no ability to tweak kernel variables, because effectively once it's setup he will control the boot process - I'll also not be able to upgrade the kernel easily. Also, no access to single user mode... Ideally I want a boot loader.... So, I was thinking. How do we make the boot loader appear to Xen to be a paravirtualized kernel? Currently it isn't even an elf object, but what it is was. How much work do you think that it might be to make a "loader kernel" that appears to be a kernel, but in fact is a boot strap. The idea being that it could be run as a "ops_pv" kernel on a Xen platform but otherwise behave exactly like our boot loader, processing loader.conf, and booting a kernel in the normal way. Does anyone have any idea of whether that's a possibility? Or, is there something fundamental about the pv_ops model that would prevent this? If this were possible we could boot the amd64 XENHVM kernel in a pv_ops manner, with full control of the kernel configuration. Hmm... Joe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7F0BEDC0-D2F5-45C1-8DE2-DF89622D42D0>