TCL as Xen Dom0?

[TheNewbie]

As the title states, I'd like to know if anybody has had success with using tinycore/microcore as the dom0 for Xen, and, if so, their experience with it. If not, then it'd be great if somebody could help me a little bit with installing (if that's the right word) TC/MC as dom0:

- Do I need to remaster TC/MC with a new kernel to support a Xen installation?
- Do I have to compile Xen from source and convert it to tcz or some such, or is there a more preferable method to "install" Xen?
- Assuming Xen can be installed properly, would it be required to remaster TC/MC with Xen installed to use it as dom0 (considering that the virtualization is supposedly kernel-level)?

Sorry if my questions are idiotic and this has been answered somewhere else >.<

Also, if anybody knows a smaller, more convenient alternative is available... (type-1 hypervisor, I find type-2 is too laggy and is too poor of a solution to support Windows and various games/utilities)

[curaga]

- Do I need to remaster TC/MC with a new kernel to support a Xen installation?

Yes. Xen and 486 support are mutually exclusive.

There are some threads on running TC as a Xen guest, but I don't remember if any were as a host.


I don't know if gaming under virtualization is a good idea no matter the system used, there's always overhead.

[danielibarnes]

I'd like to know if anybody has had success with using tinycore/microcore as the dom0 for Xen

Linux as a dom0 was only supported as of 2.6.37 in January (TC 3.x is 2.6.33.3). The kernel backends were not added until 3.0. Short answer: you can't do it yet, but it should be possible to remaster TC 4.0 to do it.

[curaga]

TC is fairly kernel agnostic, I've run 3.x with anything from .30 to .37. Sub-.33 need an udev rule added, but upwards upgrades should be fairly easy.

[TheNewbie]

I don't know if gaming under virtualization is a good idea no matter the system used, there's always overhead.

Well, it's not just the overhead (although type-1 hypervisors are supposedly much faster too), there's a lack of decent driver support and such for guest OS's to use a GFX card's 3D acceleration, etc.

The wiki has a short guide on remastering (is that the right word? >.>) TC with a new kernel, but what are the TC kernel patches?

[curaga]

http://ftp.nluug.nl/pub/metalab/distributions/tinycorelinux/3.x/release/src/kernel/33-patch-series/

[TheNewbie]

Where are there so many squashfs patches?   I assume that the ones in the 3.6 folder are the most recent. Is the "try-harder" patch necessary, or just the most recent squashfs-2011XXXX.patch?

On another note, I think Xen requires a 64-bit system (which I have), but TC seems to be finding only ~3.3GB of RAM (when in fact I have 4GB), which seems like it's acting like a 32-bit system. I was under the impression that TC is (or includes) 64-bit by default?

[curaga]

Only the -warning and -try-harder patches are needed for a recent version, as the dated squashfs ones are backports to our kernel.

TC is 32-bit by default, but there is a 64-bit kernel available.

[TheNewbie]

Only the -warning and -try-harder patches are needed for a recent version, as the dated squashfs ones are backports to our kernel.

So both the -warning and -try-harder patches are needed?

TC is 32-bit by default, but there is a 64-bit kernel available.

Hmmm. I noticed that there is a microcore64.gz, but there is no tinycore64.gz ... Also, there is a bzImage64, but when I tried editing boot options to use bzImage64 instead of bzImage, some error or other popped up =\

[maro]

Hmmm. I noticed that there is a microcore64.gz, but there is no tinycore64.gz ... Also, there is a bzImage64, but when I tried editing boot options to use bzImage64 instead of bzImage, some error or other popped up =\

Are you using the 64-bit kernel (i.e. 'bzImage64') together with the 64-bit initrd for MC (i.e. 'microcore64.gz')?

You are correct that there is no "tinycore64.{iso|gz}" to be found for downloading, but after booting into a 64-bit MC system you can "create" one by just running
    tce-load -wi Xorg-7.5 Xprogs Xlibs wbar flwm_topside
(plus executing startx). And if you use persistence you won't have to do it again. You could also remaster your very own "tinycore64.gz". Just note that the 'Xvesa' X server is not compatible with 64-bit, hence the use of 'Xorg' instead.

[Juanito]

Xvesa will not work with a 64-bit kernel, hence there's no tinycore64

[curaga]

So both the -warning and -try-harder patches are needed?

Well, so far all of our patches are only to improve the user experience. You can run a completely vanilla kernel on TC without anything breaking.

tmpfs-root may become mandatory in the future, breaking this tradition.

[TheNewbie]

So, I'm going to get this straight -- I could update MC64 with a 2.6.37 kernel and apply various patches to get a pretty standard MC64 with a 2.6.37 kernel.

Following this, I would tce-load Xorg (as opposed to Xvesa), Xprogs, wbar, and a wm (flwm being the standard). Optionally, I could remaster the whole thing as a TC64.

I think that's the end of the TC-specific process, so if anything's wrong or weird, please do explain to me. If anybody's had experience with Xen in any Linux distro, feel free to help me out a bit, but for now, I'm going Googling for some tutorials.

[maro]

... I could update MC64 with a 2.6.37 kernel and apply various patches to get a pretty standard MC64 with a 2.6.37 kernel. ...

I trust you understand that not just the kernel (i.e. 'bzImage') but also all kernel modules will have to be replaced for your private "MC64 with a 2.6.37 kernel". Furthermore I'm sure you understand that not all 2.33.3 patches will apply cleanly against a more recent sources.

BTW, what stopping you to "go for broke" and pick the most recent stable one (i.e. 2.6.39.3) as the basis of your experiment?

[TheNewbie]

I trust you understand that not just the kernel (i.e. 'bzImage') but also all kernel modules will have to be replaced for your private "MC64 with a 2.6.37 kernel". Furthermore I'm sure you understand that not all 2.33.3 patches will apply cleanly against a more recent sources.

BTW, what stopping you to "go for broke" and pick the most recent stable one (i.e. 2.6.39.3) as the basis of your experiment?

Well...

TC is fairly kernel agnostic, I've run 3.x with anything from .30 to .37. Sub-.33 need an udev rule added, but upwards upgrades should be fairly easy.

Curaga claims that 2.6.37 is relatively simple to work with. I wouldn't want to overstep my boundaries by attempting to use 2.6.39.3 on my first try.



On another note...

If you are unsure, build all of your files into the initrd. This will give you a tinycore.gz which is significantly larger than the one provided by standard TC, but in most cases you could probably live with that until you have the time to sort out the details of what modules should be put where.

How can I find out which modules/firmware are in the standard tinycore.gz?

Also, how do I obtain a 64-bit kernel? kernel.org doesn't seem to differentiate, yet TC has a bzImage and a bzImage64.