Page 1 of 1
Kernel for ASL incompatible with Xen?
Posted: Tue Jun 10, 2008 12:14 pm
by Spazholio
I just received this from tech support at Layered Tech:
"Also, it appears that this specific kernel isn't configured/compiled for xen arch, I moved the config/kernel/initrd to /boot/2.6.25-temp - if you edit the config for the kernel it shows CONFIG_XEN is not set which would cause the issue I'm having, I notice in the article it said the 2.6.24 version of the ats kernel was configured for xen, but it doesn't seem this particular one is, are there any other versions available that I could look at?"
The version I have is: vmlinuz-2.6.25.4-4.art.i686. If anyone could point me in the right direction, or just kick me in the head and tell me what I am (they are) doing wrong, it'd be greatly appreciated.
Posted: Tue Jun 10, 2008 2:59 pm
by Spazholio
Ok, I got a reply from support, who said:
"You can provision Xen, KVM, QEMU, Lguest, and vserver virtual servers under the ASL kernel, you cannot use ASL inside a Xen virtual server at this time. "
Which seems to not follow some of the info I'm seeing
here. Have I misinterpreted what was posted in that forum link?
Posted: Tue Jun 10, 2008 6:51 pm
by scott
Yeah thats correct, once we get rolling on the virtualization stuff, which we need to add to the voting for features thread I might add, we'll have a kernel-xen package so you can run it in a guest too. You can use the ASL kernel to create VM's under it. You can use the ASL kernel in KVM, QEMU, or Vmware virtual machine.
Right now that isn't on the list because... well... we didnt have it on the list
http://atomicrocketturtle.com/forum/vie ... php?t=2299 <- The list!
Posted: Tue Jun 10, 2008 8:28 pm
by Spazholio
Wait, let me get this straight - if I were using almost ANY other VM machine, the ASL kernel would be usable?
*headdesk*
Just my luck. Well, put me down for a vote for Xen compatibility, wouldja? =)
Posted: Tue Jun 10, 2008 10:21 pm
by scott
Correct, there is no Xen guest kernel yet. This is because Xen is in the middle ground of virtualization, it requires a customized xen-aware operating system for both the master, and the slave OS's. So the quick chart:
Full Hypervisor- QEMU, KVM, Vmware, Virtualbox, Parallels, etc (no custom OS required)
Para-Virtualization - Xen (custom, Xen aware kernel required)
Container - Vserver, Virtuozzo/Openvz, etc. (no kernel used)
What that means is that you can basically install any x86 based OS into a full-hypervisor virtualization system. If the master is linux, you can run freebsd, windows, linux, osx, etc under it. No changes to the guest OS's are required.
Paravirtualization means you can run any Xen-aware OS under it, so if you're running Linux, you can run Xen-Windows, or Xen-Linux as a slave OS. Mainly this means that the slave OS's have unique, xen kernels. This means that you boot the master off of one kernel, and then the guests boot again in their special xen guest kernels.
Container virtualization is limited to the OS of the master, if the master is linux, then the slaves are linux, since everything is running under the same kernel. The main advantage of a container type system is that it scales farther than the other two.