Virtualization

[tc@tinycore:#/]

I'm wanting to consider an option for TC, but need some feedback on how it would work. I've got my TC on aan SD Card, and would like to put a /tce directory on it with only virtualization-specific extensions (ie- VirtualBox) and computer-specific (ie- audio and video drivers, wireless tools, etc.), as well as its deps. This is all I want on my SD Card, for the sake of writing unnecessary files over and over to the SD Card through backup. What I'm wanting to do this way is boot TC each time into VB, then start TC as a guest in VB for kernel customization, as well as other personal projects.

Now, when I state a /tce directory in my bootloader, will my guest operating systems (which will also be TC for the most part) use that said /tce directory, or will they generate a new /tce directory in the memory of that said guest? I'm wanting to keep my SD Cards /tce untouched, but allow for a fresh /tce for those TC's for customization and play.

[curaga]

If you give the SD card as a direct drive to the guest, then it will use the tce dir there.

Otherwise, you could set up that tce dir inside a virtual hd, and pass that to the guest. I don't know of VB, but in Qemu I can specify -snapshot, which causes all changes to that HD to go into temp files instead. Those files are removed when the guest shuts down.

That way you could keep the dir the same between boots, but still let the guest use it safely.

[maro]

IIRC the feature to not change the original disk is know in VBox as "immutable images". One could change the type of a (virtual) disk to 'immutable', but that would be a permanent change (until one changes it back to 'normal'). AFAIK there is no equivalent to the '-snapshot' option of QEMU which is a run-time parameter. In principle something similar to qemu-img create -f qcow2 -o backing_file=/dev/hda hda_disk.img should allow you to use the entire host disk, where all the changes are only ever written to 'hda_disk.img'. Obviously you'd then use something like qemu -hda hda_disk.img  to use the "disk". Albeit all this applies when using QEMU, which IMHO is pretty capable. Unfortunaltely the TC 3.x repository has no support for KQEMU, so on older hardware this might not be a viable option at all. KVM should be supported, so on newer hardware it would be a good alternative to VBox.

Now for VBox I've done a small proof of concept. It uses the fact that VMDK disks can be used to describe physical disks. Details can be found on this page (also best to take note of the syntax if one wants to tweak things a bit). Instead of creating one by hand I realised that VBox now has an internal command for this task. In the following I've used CLI commands as a efficient way to describe my steps. Alternatively one could use for the later steps the GUI to achieve the same.

Code: [Select]

# create the VMDK file and change the type to immutable
VBoxManage internalcommands createrawvmdk -filename hda_disk.vmdk -rawdisk /dev/hda
VBoxManage openmedium disk hda_disk.vmdk --type immutable

# create a dummy VM for this test
VBoxManage createvm --name test --register

# boot the VM with the TC CD-ROM in the host CD-ROM drive and the immutable hard disk
VBoxSDL --startvm test --memory 256 --cdrom /dev/hdc --boot d --hda hda_disk.vmdk

One thing to be aware of is that the immutable disk creates a differencing image. This is stored in the 'Snapshots' directory of the VM. At the next restart of the VM the file will be emptied again, but it requires diskspace. In a typical setup this file will be under '~/.VirtualBox' and therefore consume RAM. So one could run into a situation that VBox freezes the VM as it can't grow the differencing file any further.

[tc@tinycore:#/]

What I'm gathering is that qemu is likely more capable of this task, and likely a preferable choice for virtualization on TC.

[hopley]

I just built a tcl v3.3 and mcl v3.3 in KVM on Fedora 14.

 Is KVM the choice?  I have used (for centos in centos) XEN previously and am looking forward.

 My mcl VM has really slow screen refreshes. 

 Seems an option is to use different VGA modes.  But prior to jumping in when there are many variables I thought I would ask and see if there was any input on making the response smooth/fast.

 The host OS is Fedora 14, I have a good amount of RAM on the host machine (configured mcl VM for 128MB which I  think ought to be good as I have an old laptop with 128MB (not exactly apples/apples but ...)).

 Let me know if I need to provide more details or if any of you have thoughts/feedback on this

thanks in advance