Dimitry,
On Thu, Jan 29, 2009 at 03:45:15PM -0500, Dimitry Golubovsky wrote: [...] > Exactly. The reason for this: VMs come and go, diskless setup on > client is much easier to accomodate with that. But general services > provided to all VMs (DHCP, DNS, HTTP cache/proxy) belong to the > "host". Ok, it's more clear :-) > What I am trying to achieve in general: > > There is a headless host running various VMs. There is a separate PC > (or several of them) used for interactive stuff. Once turned on, the > PC gets the PXE boot menu from the host. Then, either local boot (from > PC's own HD), So, you'll do a PXE boot. But is it possible to point pxelinux.cfg to the local HD after that ? (Dunno / not tried) > or a diskless boot may be chosen depending on the > purpose. Diskless boot may target one VM or another as provider of > root filesystem and applications. But the boot server is always the > same, the "host". Ideally all I had to do to enable another booting > method, would be to copy necessary image files (kernel, initrd) to the > TFTP directory on the host, and update the pxelinux.cfg menu items. > > So IMHO this could be considered for LTSP as a feature: specify NBD or > NFS root path in the kernel boot parameters obtained from pxelinux. I see what you mean, but after thinking a bit at this setup, of course in respect with your purpose, I don't see why you would separate the boot server from the root server... Do you see any advantage or necessity to do that ? The client's kernel and root filesystem (be it chroot or NBD image) are not called to change frequently. So, this two functions can be assumed together by the same machine (or same VM, as I do it here in a Xen DomU in fact). After that, for the applications servers (named "AS" here after), it's different : - you can have any number of VMs that you want (in my setup, I've several other Xen DomUs), each one playing the AS role, dedicated to different tasks, with different applications installed, etc ; - you boot your client against your (unique) boot/root server, until you arrive under LDM ; - in LDM, you choose the right AS that you need for the job ; - if you do a mistake / bad action / something else, you just blow up that VM and restore it from last backup, etc... That's nothing else that LTSP's natural way of spliting servers, and I think it's more flexible/light than having the same number of AS (in VMs) *but also with the TC root filesystem on them* (providing that one can do it technicaly) : it will be more tricky to setup at first, and you will need to maintain more boot/root servers, without any mandatory reason to do so, as far as I can see at least. You'll have perhaps a reason that I haven't see ? A+ -- JFS. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
