Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-users@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of andrei@arhont.com designates
 89.187.71.156 as permitted sender)
Date: Thu, 31 Jan 2013 11:08:41 +0000 (GMT)
From: Andrei Mikhailovsky <andrei@arhont.com>
To: cloudstack-users@incubator.apache.org
Message-ID: <22138639.1958.1359630515981.JavaMail.andrei@finka>
In-Reply-To: 
 <790E7BCBCDD98F45BD43B85D7326B8D060C793C5@AMSPRD0710MB364.eurprd07.prod.outlook.com>
Subject: Re: Slow snapshots with KVM
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1957_2041695.1359630515981"

------=_Part_1957_2041695.1359630515981
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Many thanks for all your answers. Indeed, the term Snapshot is a bit confus=
ing, perhaps it should be called something else ))). The trouble with the t=
erm Snapshot here is that the users will think it's a Snapshot and will sta=
rt using it left, right and centre without realising that it takes ages to =
do, especially if many people are doing that simultaneously and it consumes=
 far more disk space compared with the traditional Snapshotting )))=20


----- Original Message -----

From: "Paul Angus" <paul.angus@shapeblue.com>=20
To: cloudstack-users@incubator.apache.org=20
Sent: Thursday, 31 January, 2013 7:23:00 AM=20
Subject: RE: Slow snapshots with KVM=20

These are all valid points, but in the end CloudStack 'snapshots' do not be=
have in the way people from a virtualisation background are likely to expec=
t them to; You can't just press a button and roll back, you can only create=
 a clone of that VM which will have a different MAC and a new IP address an=
d possibly a new hostname...=20

I agree it may not be the best backup solution, but IMHO 'a backup' is clos=
er fit for the functionality than a snapshot.=20

Maybe we should all start calling a it a 'Clone'?=20


Regards,=20

Paul Angus=20
S: +44 20 3603 0540 | M: +447711418784=20
paul.angus@shapeblue.com=20

-----Original Message-----=20
From: Nux! [mailto:nux@li.nux.ro]=20
Sent: 30 January 2013 23:25=20
To: cloudstack-users@incubator.apache.org=20
Subject: Re: Slow snapshots with KVM=20

On 30.01.2013 22:48, David Nalley wrote:=20
>=20
> As long as you realize that these are 'crash consistent' snapshots,=20
> then yes. I personally dislike using the term 'backup' for snapshots -=20
> it's certainly not a method I'd use to backup data that was important=20
> to me.=20
>=20
> --David=20

Crash consistent can be great when you don't have anything else. :-) Plus a=
nother advantage of a full snapshot is that there's no I/O cost in maintain=
g it vs the changes in "master", like it is with the e.g. lvm snapshots. So=
 there are advantages and disadvantages..=20

--=20
Sent from the Delta quadrant using Borg technology!=20

Nux!=20
www.nux.ro=20

ShapeBlue provides a range of strategic and technical consulting and implem=
entation services to help IT Service Providers and Enterprises to build a t=
rue IaaS compute cloud. ShapeBlue=E2=80=99s expertise, combined with CloudS=
tack technology, allows IT Service Providers and Enterprises to deliver tru=
e, utility based, IaaS to the customer or end-user.=20

________________________________=20

This email and any attachments to it may be confidential and are intended s=
olely for the use of the individual to whom it is addressed. Any views or o=
pinions expressed are solely those of the author and do not necessarily rep=
resent those of Shape Blue Ltd. If you are not the intended recipient of th=
is email, you must neither take any action based upon its contents, nor cop=
y or show it to anyone. Please contact the sender if you believe you have r=
eceived this email in error. Shape Blue Ltd is a company incorporated in En=
gland & Wales.=20


------=_Part_1957_2041695.1359630515981--