On 01/04/14 11:00, Ian Collins wrote: > Tom Robinson wrote: >> On 31/03/14 17:03, Daniel Malon wrote: >> >>> About „the one big partition“ thing: >>> It is the system partition. You should add a second data disk for all your >>> stuff (that will >>> automatically get formatted and mounted at /data). >>> I guess none will be happy if you set a fixed disk size for the image … >>> because honestly >>> everyone wants to have it a different size. >> Obviously I'm having problems coming across from the RHEL mentality. >> Typically one would mount >> several volumes and use LVM: >> >> Filesystem Size Used Avail Use% Mounted on >> /dev/mapper/vg-root 1008M 239M 719M 25% / >> tmpfs 499M 0 499M 0% /dev/shm >> /dev/vda1 248M 33M 203M 14% /boot >> /dev/mapper/vg-home 1008M 34M 924M 4% /home >> /dev/mapper/vg-tmp 504M 17M 462M 4% /tmp >> /dev/mapper/vg-usr 3.0G 477M 2.4G 17% /usr >> /dev/mapper/vg-var 1008M 104M 854M 11% /var >> >> Is there an adverse impact of using LVM inside the SmartOS KVM instance? > > An extra layer of complexity you don't need? I had a similar conversation > with a local admin who > wanted to use LVM RAID on an AWS VM; there really wasn't any point in a > virtualised environment. I agree that RAID is unnecessary in the virtualised environment. LVM potentially not, however. LVM would allow you to keep a single volume but slice it up.
> >> I see that one can add more >> disks but I haven't tried this. Is it easier to manage volumes from the >> SmartOS side? Is there >> documentation for this? > > You can just add virtual disks in the VM's original JSON payload, or add them > later with vmadm. > See the disks section in the man page. Thanks, I'll take a look. > >> >> Possibly it would look something like this: >> >> Filesystem Size Used Avail Use% Mounted on >> /dev/vda1 1008M 239M 719M 25% / >> tmpfs 499M 0 499M 0% /dev/shm >> /dev/vdb1 248M 33M 203M 14% /boot >> /dev/vdc1 1008M 34M 924M 4% /home >> /dev/vdd1 504M 17M 462M 4% /tmp >> /dev/vde1 3.0G 477M 2.4G 17% /usr >> /dev/vdf1 1008M 104M 854M 11% /var >> >> > > If you felt the need (is /tmp really a volume?) to yes. Given VMs tend to > have a dedicated > function, is there anything to be gained from such fine grained partitioning? > You will run into > all sorts of problems if you want to image a VM built in this way. > Yes, /tmp is a volume, not mapped to memory. RHEL has this legacy. It could survive on the main, root partition with little issue but years of RHEL training says otherwise. See my other post about why one would slice up a volume this way. Given that individual volumes would create imaging problems, see the notes above regarding LVM. ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
signature.asc
Description: OpenPGP digital signature
