Question about storage for virtualisation
 

Hi !

I'm about to deploy a new server that will host several virtual host for
mainly website hosting purposes. My server will be a Xeon 3440 or 3450
with 32 gigs of ram (the max of that board). So I will have 8 logical
cores. At the moment, I don't know how many vms I will have, in the
order of 5 or 6.

I am quite new to managing VMs, I did play alot with them over the
course of the last couple of weeks. I used kvm to startup and manage my
vms and my main source of info was this blog entry :
http://blog.mattbrock.co.uk/2012/02/12/virtualisation-with-kvm-and-lvm-on-centos-6-via-the-command-line/

I have some general questions about VM.

If I set vcpu let's say to 2-3 for a single vm, does this mean that
those CPU are dedicated to that vm or many vm can share the same
physicial cpus ?

So, I was wondering what's the best for managing storage for VMs ? I see
mostly recomandations for LV for storing VM's disks. It seem to helps to
create snapshots for backup purposes. Is this the fastest way of
creating backups ? And will data access be faster that if I use regular
files ?

In my case, the "main" setup of each vm is rather simple. The minimal
OS, updates, my own httpd, my own php a couple of other packages. So
restoring a VM from scratch can take less than an hour. So I was
thinking of not taking snapshot of the whole VM and only sync the data
partition.

As for the guest paritions, I am accustomed of separating my servers
disks with separate /, /usr, /var, /home and /data partitions. I can't
recall today why I started doing this, 15 years ago, but I still like it
that way and continue to do so. Do I still "need" to do this with VMs ?

Thanks for the help !
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Question about storage for virtualisation
 

On Tue, Jun 26, 2012 at 9:05 AM, Nicolas Ross
<rossnick-lists@cybercat.ca> wrote:
> I have some general questions about VM.
>
> If I set vcpu let's say to 2-3 for a single vm, does this mean that
> those CPU are dedicated to that vm or many vm can share the same
> physicial cpus ?
No, all the CPU will be virtualized and shared.
Although there is "affinity" option where physical CPU is locked to a
certain VM. But in general this option gives more bad effect than
good.

> So, I was wondering what's the best for managing storage for VMs ? I see
> mostly recomandations for LV for storing VM's disks. It seem to helps to
> create snapshots for backup purposes. Is this the fastest way of
> creating backups ? And will data access be faster that if I use regular
> files ?
Using LV will give you flexibility among other things. Better have it
in the beginning rather than sorry later (e.g. running out of space,
etc).
The performance difference is insignificant.

> In my case, the "main" setup of each vm is rather simple. The minimal
> OS, updates, my own httpd, my own php a couple of other packages. So
> restoring a VM from scratch can take less than an hour. So I was
> thinking of not taking snapshot of the whole VM and only sync the data
> partition.
That's ok.

> As for the guest paritions, I am accustomed of separating my servers
> disks with separate /, /usr, /var, /home and /data partitions. I can't
> recall today why I started doing this, 15 years ago, but I still like it
> that way and continue to do so. Do I still "need" to do this with VMs ?
The reason of creating separate partitions is mainly for security and
preserve data during reinstallation.
I believe it's still good to do your way.


--
http://linux3.arinet.org
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Question about storage for virtualisation
 

On 06/25/2012 06:05 PM, Nicolas Ross wrote:
>
> If I set vcpu let's say to 2-3 for a single vm, does this mean that
> those CPU are dedicated to that vm or many vm can share the same
> physicial cpus ?

Normally, they won't be dedicated. You cannot assign more CPUs to a
guest than there are in the host system, but you can overcommit CPUs in
general. That is, if you have 8 cores, you can create two guests with 6
virtual CPUs each. If the guests both become busy enough to fully
utilize 6 CPUs, the performance of each will naturally be degraded
relative to only one guest being busy enough to fully utilize 6 CPUs.

While CPUs cannot be overcommitted, memory can. Again, if you
overcommit memory, the host will swap excess utilization and severely
degrade guest performance. Take care to avoid doing this.

> So, I was wondering what's the best for managing storage for VMs ? I see
> mostly recomandations for LV for storing VM's disks. It seem to helps to
> create snapshots for backup purposes. Is this the fastest way of
> creating backups ? And will data access be faster that if I use regular
> files ?

Yes, performance of guests backed by LVs will be significantly better
than the performance of guests backed by regular files.

No, you cannot make reliable backups of guests using snapshots of the
LV. A snapshot taken at any given time may have inconsistent data. Run
your backup software in the guest rather than in the host. Under a
Linux guest, you're able to snapshot filesystems and make backups.

When you make a snapshot under LVM, the file system contained therein is
made consistent (though I'm having trouble finding actual documentation
to that effect) before the snapshot is taken. If you have open files,
you may need to take additional steps to make that data consistent (as
you would if you were backing up a MySQL database). Taking a snapshot
of a running KVM guest will not make data consistent, so you won't be
able to reliably make a backup that way.

Finally, do not use snapshots as your primary means of backup. If your
media fails, you will lose your data.

> As for the guest paritions, I am accustomed of separating my servers
> disks with separate /, /usr, /var, /home and /data partitions. I can't
> recall today why I started doing this, 15 years ago, but I still like it
> that way and continue to do so. Do I still "need" to do this with VMs ?

I don't believe there's any more or less need to do so. I would
strongly recommend that you not segregate / and /usr. Fedora and future
versions of RHEL/CentOS will expect a unified / and /usr.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Question about storage for virtualisation
 

On 06/26/12 9:29 AM, Gordon Messmer wrote:
>> As for the guest paritions, I am accustomed of separating my servers
>> >disks with separate /, /usr, /var, /home and /data partitions. I can't
>> >recall today why I started doing this, 15 years ago, but I still like it
>> >that way and continue to do so. Do I still "need" to do this with VMs ?
> I don't believe there's any more or less need to do so. I would
> strongly recommend that you not segregate / and /usr. Fedora and future
> versions of RHEL/CentOS will expect a unified / and /usr.
> _______________________________________________

I concur. I'll definitely put /home on a seperate volume if there's
going to be a need for a large /home (some of my servers have hardly any
/home as there are no interactive users to speak of, others use nfs
mounted /home dirs for interactive logins). /var I'm kind of on the
fence on. things like postgres, which like to put the databases in
/var/lib/pgsql/x.y/data, I've been recently mounting my dedicated raid10
database volumes as such, so /var itself has very little. but we all
know spools, logs can grow unexpectedly large, so constraining /var to a
dedicated LV is probably a good idea.

--
john r pierce N 37, W 122
santa cruz ca mid-left coast

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Question about storage for virtualisation
 

On Jun 26, 2012, at 10:29 AM, Gordon Messmer wrote:
>
> I don't believe there's any more or less need to do so. I would
> strongly recommend that you not segregate / and /usr. Fedora and future
> versions of RHEL/CentOS will expect a unified / and /usr.


I may be behind, but this is the first I've heard of this...

Any good references as to WHY?! they want to break this decades old convention?

Thanks,

Nate

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Question about storage for virtualisation
 

On Fri, 29 Jun 2012, Nate Duehr wrote:



On Jun 26, 2012, at 10:29 AM, Gordon Messmer wrote:


I don't believe there's any more or less need to do so. I would
strongly recommend that you not segregate / and /usr. Fedora and future
versions of RHEL/CentOS will expect a unified / and /usr.



I may be behind, but this is the first I've heard of this...

Any good references as to WHY?! they want to break this decades old
convention?


Solaris broke it years ago.

It'll certainly help builds and packaging, since no one needs to
specify where, e.g., ls or rm is located.


And granted that my experience is far from universal, I haven't seen a
production Linux box that remote-mounts /usr in a decade.


--
Paul Heinlein
heinlein@madboa.com
45°38' N, 122°6' W_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Question about storage for virtualisation
 

Am 29.06.2012 20:17, schrieb Nate Duehr:
>
> On Jun 26, 2012, at 10:29 AM, Gordon Messmer wrote:
>>
>> I don't believe there's any more or less need to do so. I would
>> strongly recommend that you not segregate / and /usr. Fedora and future
>> versions of RHEL/CentOS will expect a unified / and /usr.
>
> I may be behind, but this is the first I've heard of this...
>
> Any good references as to WHY?! they want to break this decades old convention?

Decades old I'll grant you, but hardly a convention anymore.
There was a time when this made sense ... about twenty-five
years ago. We didn't have journaling filesystems then, fsck was
still new, and if your root filesystem was corrupted you had to
boot to single user mode in order to fix it manually. You had
every interest to keep your root filesystem small, simple and
static.

But times have changed. Nowadays, a system that has experienced
a power cut in full activity will come back up with hardly a
hiccup when power is restored. Dividing up your disks into
partitions has become a nuisance because there's always one
which is too small while others have space left. So it's gone
out of fashion. I haven't seen a Unix or Linux system with
separate / and /usr partitions in the last five years, and not
set one up myself for ten at least.

--
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Question about storage for virtualisation
 

On 06/29/2012 11:17 AM, Nate Duehr wrote:
> Any good references as to WHY?! they want to break this decades old convention?

http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

All of the reasons you'd put /usr on a separate partition from / were
resolved decades ago. There's no reason to do that, and a long list of
reasons not to.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Question about storage for virtualisation
 

On Fri, Jun 29, 2012 at 11:19 PM, Gordon Messmer <yinyang@eburg.com> wrote:
> On 06/29/2012 11:17 AM, Nate Duehr wrote:
>> Any good references as to WHY?! they want to break this decades old convention?
>
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
>
> All of the reasons you'd put /usr on a separate partition from / were
> resolved decades ago. *There's no reason to do that, and a long list of
> reasons not to.

Umm, yeah... Nobody would ever want to boot from small alternate media
devices in these days of 3TB drives.... I suppose most of what /bin
was supposed to hold and the reasons for putting it there have been
usurped by the initrd that is normally required to boot linux, though.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Question about storage for virtualisation
 

On Sat, Jun 30, 2012 at 09:56:59AM -0500, Les Mikesell wrote:

> devices in these days of 3TB drives.... I suppose most of what /bin
> was supposed to hold and the reasons for putting it there have been
> usurped by the initrd that is normally required to boot linux, though.

Historically for Linux /bin and /sbin were meant to hold the minimum
necessary tools to bring the rest of the filesystems online and to do
basic restores in case the thing exploded (basically, "single user mode"
tools). Everything else was meant to be in /usr. /lib requirements came
from /bin. At least that was the rationale we put into FSSTND back in the
early-mid 90s. (I'm not sure RedHat ever really followed this properly;
there's too much stuff in /bin :-))

With initrd and similar ramdisk boot systems these requirements have
changed and the distinction between /bin and /usr/bin has definitely
dropped.

--

rgds
Stephen
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos