Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-users@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <68b337a1ff4062d52b86ad53e211f813@li.nux.ro>
References: <711b66f9bd711255231e6e159dce2f76@li.nux.ro>
	<CAFtUSExU8fwM3Xfw0ji-+t7+pxsC7yVsNanRQXbKMML4EBOEwA@mail.gmail.com>
	<68b337a1ff4062d52b86ad53e211f813@li.nux.ro>
Date: Thu, 7 Feb 2013 13:28:56 -0800
Message-ID: 
 <CAA3XVTygLyfLpyU-yDAJ3eW9f_891128X1i5dmtKSwFXAvZHtQ@mail.gmail.com>
Subject: Re: Questions about KVM storage backends and resize/migrations
From: Bryan Whitehead <driver@megahappy.net>
To: cloudstack-users@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d043c7d605a0e6804d52921f3

--f46d043c7d605a0e6804d52921f3
Content-Type: text/plain; charset=ISO-8859-1

I'm currently using glusterfs as a SharedMountPoint with great success.
I've had server failures and HA smoothly powered up VM's that got hit
without a hitch. (Each VM host has about ~4TB contributing to a volume with
replica=2). I've also been able to migrate VM's around for maintenance on
specific hosts.

NOTE: I have an infinband/IPoIB interconnect so glusterfs has all the IO it
needs. I easily can push 130MB/sec write speeds inside a VM with kvm/qcow2
backed setup.


On Wed, Feb 6, 2013 at 12:55 PM, Nux! <nux@li.nux.ro> wrote:

> On 06.02.2013 19:55, Chris Sears wrote:
>
>>
>> I'm not sure anyone could give you a "recommended" option for primary
>> storage without knowing more about your requirements and environment,
>> but NFS seems to be fairly common for production usage. For KVM, your
>> storage options are NFS, RDB, CLVM, or SharedMountPoint (which could
>> be any shared file system, eg GFS).
>>
>
> Thanks, CLVM looks really neat and I imagine the snapshotting is also
> superior to what we can see today with kvm+qcow2. I guess I could also use
> Glusterfs as SharedMountPoint.
>
>
>
>> Yes, CS can resize volumes, but it doesn't do anything inside the
>> guest to resize the local filesystem/partitions.
>>
>
> That's fair enough.
>
>
>
>>  If the requested resize needs more resources than the current physical
>>> host
>>> can provide, can CS (live) migrate the VM to another one?
>>>
>>
>> I'm not aware of any such automatic migration feature. Most of the
>> primary storage options would expose the same shares/LUNs to all the
>> hosts in a cluster, so I'm not sure how often this would come up.
>>
>
> In my case the local storage is significantly faster than anything
> "shared" I could come up with so this feature is quite appealing. The other
> competition's stack can do this and I wondered if cloudstack can also do
> it. But CLVM might be a decent compromise, remains to be seen.
>
> Thanks a lot!
>
>
> Lucian
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

--f46d043c7d605a0e6804d52921f3--