[Gllug] Virtual disk allocation advice requested

David L Neil Mailing list a/c GLLUG at getaroundtoit.co.uk
Sun Jun 29 19:57:48 UTC 2008


Thank you for such a considered reply - comments interposed:-

Richard Jones wrote:
> On Sun, Jun 29, 2008 at 11:31:59AM +0100, David L Neil Mailing list a/c wrote:
>> Using a single large HDD initially, I thought:
>> a) primary partition, <1GB, ext3, /boot
>> b) LVM logical volume(s) for Xen's Dom0
>> c) multiple logical volumes, one for each Xen DomU
>> d) NFS shared space (both for network and between DomUs)
>> e) Samba shared space (somewhat optional because have other such spaces)
>> - that latter revealing that I have an heterogeneous network
> My standard layout looks something like this:
>   /dev/sda1     /boot     256MB-1GB
>   /dev/sda2     Allocate all the rest of the space to a single LVM PV/VG

>   VolGroup/Dom0Swap       2 GB
>   VolGroup/Dom0Root       At least 6 GB
> Optionally you could have other Dom0 partitions, as required.
> Then for each guest (eg. a guest called 'email') I would have:
>   VolGroup/Email          At least 6 GB

> To the guest, VolGroup/Email will appear as a device (/dev/xvda) which
> you can partition as required.  You can even use LVM-on-LVM, although
> for guests there's probably not much benefit.  In Xen the maximum
> number of devices supported per guest is 16.
>> Queries:
>> 1 would it make better sense to put all of the Dom0 onto the primary
>> partition or even a separate extended partition?
> It's just so much easier and flexible to use LVM for everything that I

=thank you. Will check performance - once I get it all going...

>> 2 for Dom0 I thought something like:
>>  2GB, swap, /swap
>>  5GB, reiser, /var
>>  2GB, reiser, /root (rootuser)
>>  10GB, ext3, /
>> but is it as necessary to break things out in a Dom0 situation?
> Jokes about murderfs aside, why use reiser instead of ext3?  I guess
> it would only make sense if /var is storing newsgroups.  Also I'm a
> bit confused as to why you've decided to use a separate /root
> partition, since I wouldn't normally expect someone to store large
> numbers of files under /root.

=blind faith, (false?) memories of past wisdom, and ignorance!
1 forgot that whereas ext2 was NOT a journalling file system, ext3 is. Duh!
2 thought one kept /root separate so that even if some other part of the
file system was jammed up, root could still log-on (same rationale as /var)

=No I'm not working with newsgroups (email and groupware, web, web dev,
desktop and maybe play DVDs video (may be easier to put this and dev
together!?), and a throw-away test VM for 'playing').

=I did however neglect to say that as the processor is a pre-Pacifica
AMD, I'm talking "paravirtualised". I don't know if this makes a
difference in any of these points (apologies if does).

=I will give ext3 a try BUT (and this is a double-duh!) in my notes I
have the following:
recommendation: PV mode = non-journalling file system, such as ext2.
If VM crashes/disorderly shtdn, pending trans cannot rec from jnl.
Set VM boot own pn, non-jnl fs=ext2.
(sorry, not clear where I read this)
Thus suspect the combo should be ext2 and ext3 to avoid criminal trials,
Does this make any sense at all?


>> 4 I haven't figured out where/when/how one allocates space within a
>> DomU. Does/should one separate out space allocated to logs, the root
>> user, etc, as we were advised in 'the good old days' or has such gone by
>> the board/become irrelevant in the brave new virtual world?
> I usually use a single root partition for guests (/dev/xvda1 = /boot,
> /dev/xvda2 = /)

=is there a particular reason why you don't worry about logs exceeding
the space available, or some such doomsday scenario - eg you actually
monitor your system properly?
(are probably religious about backups too...bless you my son!)

>> 5 will NFS 'play nicely' in an LVM logical volume or should it be an
>> extended partition?
>> 6 similarly will Samba go into an LVM logical volume or should it be an
>> extended partition?
> NFS can use anything.  Use an LVM logical volume by choice.  A more
> interesting question is where should you run the NFS / Samba server?
> In an ideal world you would run it inside a guest, so that the dom0 is
> protected from NFS server security problems, but in reality this is
> very slow, so it's best to run these servers in the dom0.

=I had read this, but also read conflicting comment - and not competent
to compare and contrast.

=Logic says that if use NFS, eg for /home within any VM and 'house' the
NFS server within another VM, that at boot time Xen will not guarantee
that one domain will be up and running prior to another being started
and thus the situation may produce a time-race condition.

=Contrarily: the advice is to keep everything possible out of Dom0. All
very well until I get an errmsg telling me that the manager won't run
without a graphics system (see 'confession' later) so I ended up loading
Gnome (and it wouldn't let me try to avoid loading the whole kitchen
sink). Now I think about it, wonder if just X would have been enough???

=Either way, sounds sensible for it to be a separate LV from that used
by the domain itself. Right?

>> 7 if I set up a DomU temporarily, eg to test some software/project, and
>> subsequently discontinue it, should I also remove the partition/virtual
>> disk allocated within LVM and then build space anew before creating some
>> future DomU, or can/should one simply recycle the nominated logical volume?
> Just use lvremove to remove the guest's LV, and that space is
> automatically given back to the volume group, ready for next time you
> run lvcreate.

=Please don't tell your colleague Tony Dixon, but this is coming off an
OpenSuSE 11.0 disk I was given-paint still wet! Their graphical manager
doesn't seem to work this way/wipe the old conf file (which I find a
little odd, now I ...). [mainline command line people please look away
now] Whilst I'm playing and learning, I find the GUI helpful, but (per
above) I'm not so sure about it's efficacy on a production server!?

> Rich.

=Many thanks,

Gllug mailing list  -  Gllug at gllug.org.uk

More information about the GLLUG mailing list