Is this partitioning scheme reasonable
 

Just wondered if someone could give me an idea whether the following partitioning is likely to be appropriate for a Debian Wheezy KVM Host Server. Especially can I have the boot loader installed on a partition within an LVM group.
Thanks,
Nick

Wow! I didn't know that any BIOS could boot from a volume in a logical volume group! What hardware / BIOS are you using? :scratch:

As to your partitioning scheme, why not put everything under / as a single logical volume? (Including the 250Gb /vm and the 50 Gb /home partitions. (The file system access controls and user quotas are, I believe, sufficient to keep the system clean without physical separation of things already logically separated. Especially if you use SELinux to keep wandering fingers off sensitive places.)

By the way, are you putting all this on a single hard drive? If so, it looks like you'd be using a GUID partition table, not a DOS partition table, so you could, I think, trash the old "extended partition" stuff that is part of the legacy support.

If you're using LVM to manage a pool of disks, you might consider putting all your partition into the LV pool and boot everything from GRUB2.

I presume that the first three partitions are for some Windows system you're not yet ready to trash? If that's the case, why not run those as other virtual systems. Then you could us a really simple scheme: One partition, /, with everything in it.:)

Since this seems a server with (from the proposed size of /home) lots of users, what back-up and fall-over system do you propose to use?

You might have a point about using a GPT disk. The first couple of partitions are indeed windows:

Part1 - Win2008/Hyper-V
Part2 - Win2003

Now when I briefly looked at GTP disks I read that Win2003 cannot use them hence I stuckl with the traditional MBR disk. However I now read that Win2003 with Service Pack 1 can actually use GTP disks. Hence my reason to stick with MBR disk has gone.

So if I wipe the drive and start again as a GPT disk how does that affect where I put the Linux boot loader? I understand that this can be written to a partition rather than to the MBR, I assume that is still the case with GPT disks. If so can that /boot partition be within an LVM group or should it be outside that as a seperate partition.

I am comfortable that I have good reason for keeping both the virtual machines and /home on their own seperate partitions, for example /tmp can be mounted with the nosuid & noexec flags, also hoping to mount the /vm part with no caching, not that I have any idea how to do that yet. Not so sure about seperating out all of the other Linux partitions under one logical volume group, I had just read that it was good practice to do so.

Edit:
I don't think Win2008 can be installed to a GPT disk. At least I have just run through the install sequence and cannot see any method of creating GPT disk.

Well, what about the idea of moving all the Windows programs into the virtual space. That would eliminate the whole partition scheme problem since they could format their virtual disk(s) any way they liked and the virtual system would handle the "real" disk and network access.

I'm not too clear about your reasons for wanting /tmp and /home as separate partitions, but there's probably no harm to doing so. Have you decided to drop the LV idea?

What about back-up? (I've got a software RAID-1 set up to mirror a 1 Tb disk with half a 2 Tb one, with Fedora 16 (and several virtuals) on it, and find that mirroring a drive substantially improves HD response times. And, of course, provides some fail-over redundancy. Since mine is just a hobbyist system, I only store "critical" files - Tax returns, etc. - offline.)

My point about Logical Volume usage is that it seldom makes any sense to use it unless you've got several different physical disk that you want use as a single logical disk. For example, say you had four 3Tb drives that you wanted to use as a mirrored 6Tb drive. Than LVM might be one method of setting that up. But for a single drive system, about all you could get from using a LV would be the snapshot functionality that creates hard links to the inodes that are in use at the time of the snapshot. That gives you an easy roll-back path at the expense of freezing the in-use disk space, which may not be a problem if only user space stuff is changing.

Of course there are other file systems that provide a snapshot feature (btrfs, zfs) and, I believe, you can use rsync to create snapshots of most Linux file systems.

Reason for keeping Windows is that I need support some users using Win2k8 Hyper-V so need to be able to boot to that as well. Also not sure if some of the old Win2003 stuff I have running will all work perfectly under KVM virtualization. So for the moment I just need to get Grub installed in the /boot partition and chainload that through the win2k8/7 bootloader.

After further reading there was some question as to whether Grub & /boot could reside within an LVM volume so I decided to keep this outside. Leaving me with:

Looks reasonable, although a 20Gb swap partition will, hopefully, be a waste of space.

If you need a 20G swap, your system is going to be about as slow as molasses outside in Fairbanks in January. Adding 20Gb to your system's memory would seem like a more rational way to address the applications-in-memory issue. (With 4Gb chips selling for as little as $20, 20Gb would set you back less about $100, and, if your system only has four memory slots, you could put 12Gb in for $80 or so.)

On my system, a quad-core AMD with 12Gb RAM, I've only used my swap space for system save and restore, but never needed it in actual operation. Of course, a real server's usage may be more demanding than a hobby system with just two users ("root" and me), even when I'm running several virtual system. (One of which is an old Win NT one, which seemd fine the few times I've run it. I don't have any newer licences than the old NT one, so I can't really say much about how those would run virtualized.)

My theory on swap is that you should have a swap partition about half the size of your actual memory, and an alarm daemon to monitor it and tell you if it's ever used. In actual operation, that alarm should never trigger, so it (the swap space) is just insurance to tide you over while you address your real problem(s). But that's just my theory, and nothing much rids on whether its correct or not. (I once had a laptop with only 2Gb, and it became really slow whenever it need to use the swap space.)

Anyhow, good luck. Maybe you should drop back after you've got you system up and running, and let us know how it worked out.

Final layout now up and running: