cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Whitehead <dri...@megahappy.net>
Subject Re: Questions about KVM storage backends and resize/migrations
Date Sun, 17 Feb 2013 04:31:32 GMT
Whatever the default is with cloud-agent for kvm. I'm running centos 6.3 +
some level of updates for most packages.

I'm still running cloudstack 3.0.2 fwiw.


On Sat, Feb 16, 2013 at 9:36 AM, John Kinsella <jlk@stratosec.co> wrote:

> Bryan - are you running the KVM disks with writethrough or writeback
> caching? From my exp, I had to switch to writethrough for gluster to work,
> and that resulted in a 4x performance hit for a VM to write to the gluster
> store vs writing to gluster directly on the host...
>
> John
>
> On Feb 7, 2013, at 1:28 PM, Bryan Whitehead <driver@megahappy.net> wrote:
>
> > 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
> >>
>
> Stratosec - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message