Mailing List Archive: Netapp: toasters

SMVI - Limitations?

Index | Next | Previous | View Threaded

kwillia at smud

Jan 8, 2009, 11:41 AM

Post #1 of 15 (4652 views)
Permalink

SMVI - Limitations?

We're making the plunge to move to NFS and SMVI (from RDM backed luns
and homegrown snapshot management scripts).

Does anyone know of any limitation to how many VMs can exist in a data
store that SMVI is snapping? Is there any impact when snapping virtual
machines (outside of SQL/Oracle VMs)?

__________________________________________________________
Ken Williams
Storage Administrator, Business Technology Operations
Sacramento Municipal Utility District
E-Mail: kwillia [at] smud
Phone: (916) 732-6744
Cell: (916) 240-4213

hollandwl at gmail

Jan 8, 2009, 3:43 PM

Post #2 of 15 (4570 views)
Permalink

Re: SMVI - Limitations? [In reply to]

Snapmanager for Virtual Infrastructure, RDM to VMFS/NFS Migrations...I've been experimenting with SMVI some and it appears to work hand-in-hand with vCenter. Essentially, it takes a VMware snapshot, followed by a filer snapshot (and snapmirror update if you tell it to), then deletes the VMware snapshot. The VMware snapshot before the filer snapshot ensures the volumes are quiesced and buffers flushed before the filer snapshot to ensure consistency.

I think you'll still have to place your databases in hot backup mode before taking a snapshot.

Currently our Oracle and SQL data, index, redo, and archives exist on iSCSI LUNs with SnapDrive for Windows. As we progress with VMware, we will likely place our OS and Applications either on NFS volumes or VMFS formatted iSCSI LUNs. We will then continue to use SnapDrive for Windows to manage our database LUNs as this is something we are familiar with and are very comfortable with our current recovery model in regards to the databases themselves. Plus we often wish to take snaphots on them several times a day during our production cycles. Simply go into hot backup mode, take snapshot of all but archive volumes, exit hot backup mode, snapshot archive volume. It happens so quickly our users never notice it and we have recovery points at key times during our production cycle should something go wrong during one of the daily operations. This is for Oracle. Our SQL databases are small and not mission critical so simply taking a filer snapshot and letting SQL do its crash recovery if we restore a snapshot works fine.
----- Original Message -----
From: Ken Williams
To: toasters [at] mathworks
Sent: Thursday, January 08, 2009 2:41 PM
Subject: SMVI - Limitations?

We're making the plunge to move to NFS and SMVI (from RDM backed luns and homegrown snapshot management scripts).

Does anyone know of any limitation to how many VMs can exist in a data store that SMVI is snapping? Is there any impact when snapping virtual machines (outside of SQL/Oracle VMs)?

__________________________________________________________
Ken Williams
Storage Administrator, Business Technology Operations
Sacramento Municipal Utility District
E-Mail: kwillia [at] smud
Phone: (916) 732-6744
Cell: (916) 240-4213

kwillia at smud

Jan 8, 2009, 3:50 PM

Post #3 of 15 (4540 views)
Permalink

RE: SMVI - Limitations? [In reply to]

In our environment if we perform a VMWare snapshot of a SQL or Oracle
database it will crash. So we've actually set policy so those do not get
snapshots.

________________________________

From: Bill Holland [mailto:hollandwl [at] gmail]
Sent: Thursday, January 08, 2009 3:43 PM
To: Ken Williams; toasters [at] mathworks
Subject: Re: SMVI - Limitations?

I've been experimenting with SMVI some and it appears to work
hand-in-hand with vCenter. Essentially, it takes a VMware snapshot,
followed by a filer snapshot (and snapmirror update if you tell it to),
then deletes the VMware snapshot. The VMware snapshot before the filer
snapshot ensures the volumes are quiesced and buffers flushed before the
filer snapshot to ensure consistency.

I think you'll still have to place your databases in hot backup mode
before taking a snapshot.

Currently our Oracle and SQL data, index, redo, and archives exist on
iSCSI LUNs with SnapDrive for Windows. As we progress with VMware, we
will likely place our OS and Applications either on NFS volumes or VMFS
formatted iSCSI LUNs. We will then continue to use SnapDrive for
Windows to manage our database LUNs as this is something we are familiar
with and are very comfortable with our current recovery model in regards
to the databases themselves. Plus we often wish to take snaphots on
them several times a day during our production cycles. Simply go into
hot backup mode, take snapshot of all but archive volumes, exit hot
backup mode, snapshot archive volume. It happens so quickly our users
never notice it and we have recovery points at key times during our
production cycle should something go wrong during one of the daily
operations. This is for Oracle. Our SQL databases are small and not
mission critical so simply taking a filer snapshot and letting SQL do
its crash recovery if we restore a snapshot works fine.

----- Original Message -----
From: Ken Williams <mailto:kwillia [at] smud>
To: toasters [at] mathworks
Sent: Thursday, January 08, 2009 2:41 PM
Subject: SMVI - Limitations?

We're making the plunge to move to NFS and SMVI (from RDM backed
luns and homegrown snapshot management scripts).

Does anyone know of any limitation to how many VMs can exist in
a data store that SMVI is snapping? Is there any impact when snapping
virtual machines (outside of SQL/Oracle VMs)?

__________________________________________________________
Ken Williams
Storage Administrator, Business Technology Operations
Sacramento Municipal Utility District
E-Mail: kwillia [at] smud
Phone: (916) 732-6744
Cell: (916) 240-4213

kwillia at smud

Jan 8, 2009, 4:12 PM

Post #4 of 15 (4552 views)
Permalink

RE: SMVI - Limitations? [In reply to]

Our databases are on RDMs, actually all our VMs are on RDMs.

I'm working on migrating to NFS/IP storage and SMVI is part of that
design.

-----Original Message-----
From: Matt Hallmark [mailto:matt [at] cosmictoaster]
Sent: Thursday, January 08, 2009 4:00 PM
To: Ken Williams
Cc: Bill Holland; toasters [at] mathworks
Subject: Re: SMVI - Limitations?

Are your databases on VMDK's, RDM's or are you using an iscsi initiator
in the VM?

Thx,

Matt

On Jan 8, 2009, at 3:50 PM, Ken Williams wrote:

> In our environment if we perform a VMWare snapshot of a SQL or Oracle
> database it will crash. So we've actually set policy so those do not
> get snapshots.
>
> From: Bill Holland [mailto:hollandwl [at] gmail]
> Sent: Thursday, January 08, 2009 3:43 PM
> To: Ken Williams; toasters [at] mathworks
> Subject: Re: SMVI - Limitations?
>
> I've been experimenting with SMVI some and it appears to work hand-
> in-hand with vCenter. Essentially, it takes a VMware snapshot,
> followed by a filer snapshot (and snapmirror update if you tell it
> to), then deletes the VMware snapshot. The VMware snapshot before the

> filer snapshot ensures the volumes are quiesced and buffers flushed
> before the filer snapshot to ensure consistency.
>
> I think you'll still have to place your databases in hot backup mode
> before taking a snapshot.
>
> Currently our Oracle and SQL data, index, redo, and archives exist on
> iSCSI LUNs with SnapDrive for Windows. As we progress with VMware, we

> will likely place our OS and Applications either on NFS volumes or
> VMFS formatted iSCSI LUNs. We will then continue to use SnapDrive for

> Windows to manage our database LUNs as this is something we are
> familiar with and are very comfortable with our current recovery model

> in regards to the databases themselves. Plus we often wish to take
> snaphots on them several times a day during our production cycles.
> Simply go into hot backup mode, take snapshot of all but archive
> volumes, exit hot backup mode, snapshot archive volume. It happens so

> quickly our users never notice it and we have recovery points at key
> times during our production cycle should something go wrong during one

> of the daily operations. This is for Oracle. Our SQL databases are
> small and not mission critical so simply taking a filer snapshot and
> letting SQL do its crash recovery if we restore a snapshot works fine.
> ----- Original Message -----
> From: Ken Williams
> To: toasters [at] mathworks
> Sent: Thursday, January 08, 2009 2:41 PM
> Subject: SMVI - Limitations?
>
> We're making the plunge to move to NFS and SMVI (from RDM backed luns
> and homegrown snapshot management scripts).
>
> Does anyone know of any limitation to how many VMs can exist in a data

> store that SMVI is snapping? Is there any impact when snapping virtual

> machines (outside of SQL/Oracle VMs)?
>
> __________________________________________________________
> Ken Williams
> Storage Administrator, Business Technology Operations Sacramento
> Municipal Utility District
> E-Mail: kwillia [at] smud
> Phone: (916) 732-6744
> Cell: (916) 240-4213
>

Darren.Sykes at csr

Jan 9, 2009, 12:19 AM

Post #5 of 15 (4547 views)
Permalink

RE: SMVI - Limitations? [In reply to]

You can tell SMVI (v1.1) not to perform OS level disk quiecing on those machines if that's any use to you?
You'll then get a completely transparent Netapp level snapshot and won't interfere with the VM itself.

Darren

________________________________

From: owner-toasters [at] mathworks on behalf of Ken Williams
Sent: Thu 1/8/2009 23:50
To: Bill Holland; toasters [at] mathworks
Subject: RE: SMVI - Limitations?

In our environment if we perform a VMWare snapshot of a SQL or Oracle database it will crash. So we've actually set policy so those do not get snapshots.

________________________________

From: Bill Holland [mailto:hollandwl [at] gmail]
Sent: Thursday, January 08, 2009 3:43 PM
To: Ken Williams; toasters [at] mathworks
Subject: Re: SMVI - Limitations?

I've been experimenting with SMVI some and it appears to work hand-in-hand with vCenter. Essentially, it takes a VMware snapshot, followed by a filer snapshot (and snapmirror update if you tell it to), then deletes the VMware snapshot. The VMware snapshot before the filer snapshot ensures the volumes are quiesced and buffers flushed before the filer snapshot to ensure consistency.

I think you'll still have to place your databases in hot backup mode before taking a snapshot.

Currently our Oracle and SQL data, index, redo, and archives exist on iSCSI LUNs with SnapDrive for Windows. As we progress with VMware, we will likely place our OS and Applications either on NFS volumes or VMFS formatted iSCSI LUNs. We will then continue to use SnapDrive for Windows to manage our database LUNs as this is something we are familiar with and are very comfortable with our current recovery model in regards to the databases themselves. Plus we often wish to take snaphots on them several times a day during our production cycles. Simply go into hot backup mode, take snapshot of all but archive volumes, exit hot backup mode, snapshot archive volume. It happens so quickly our users never notice it and we have recovery points at key times during our production cycle should something go wrong during one of the daily operations. This is for Oracle. Our SQL databases are small and not mission critical so simply taking a filer snapshot and letting SQL do its crash recovery if we restore a snapshot works fine.

----- Original Message -----
From: Ken Williams <mailto:kwillia [at] smud>
To: toasters [at] mathworks
Sent: Thursday, January 08, 2009 2:41 PM
Subject: SMVI - Limitations?

We're making the plunge to move to NFS and SMVI (from RDM backed luns and homegrown snapshot management scripts).

Does anyone know of any limitation to how many VMs can exist in a data store that SMVI is snapping? Is there any impact when snapping virtual machines (outside of SQL/Oracle VMs)?

__________________________________________________________
Ken Williams
Storage Administrator, Business Technology Operations
Sacramento Municipal Utility District
E-Mail: kwillia [at] smud
Phone: (916) 732-6744
Cell: (916) 240-4213

To report this email as spam click here <https://www.mailcontrol.com/sr/AbxftuvtwIzTndxI!oX7UsdzF!uV4N23W6fSIXhDKXUfYQ68AXeTICYb0OeSN8LT+UJTMPXhg38WVaQUGz3XVw==> .

netbacker at gmail

Jan 9, 2009, 3:22 PM

Post #6 of 15 (4519 views)
Permalink

Re: SMVI - Limitations? [In reply to]

On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes [at] csr> wrote:
> You can tell SMVI (v1.1) not to perform OS level disk quiecing on those
> machines if that's any use to you?
> You'll then get a completely transparent Netapp level snapshot and won't
> interfere with the VM itself.
>
> Darren
It is SMVI v1.01 BTW, not 1.1
Not sure I understand this correctly, but if you are bypassing OS
disk quiesce (VMWare snapshot) and doing transparent NetApp level
snapshot, then why do you even need SMVI installed? Can't we just do
the regular filer level snap schedule? We just upgraded to 1.01 and
noticed the checkbox and were wondering about its potential use. Any
ideas?

thanks
-G

kwillia at smud

Jan 12, 2009, 11:05 AM

Post #7 of 15 (4488 views)
Permalink

RE: SMVI - Limitations? [In reply to]

Sounds like it can be used on a per machine basis, so it would be good
to exclude trouble machines.

-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of Sto Rage(c)
Sent: Friday, January 09, 2009 3:22 PM
To: toasters [at] mathworks
Subject: Re: SMVI - Limitations?

On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes [at] csr>
wrote:
> You can tell SMVI (v1.1) not to perform OS level disk quiecing on
> those machines if that's any use to you?
> You'll then get a completely transparent Netapp level snapshot and
> won't interfere with the VM itself.
>
> Darren
It is SMVI v1.01 BTW, not 1.1
Not sure I understand this correctly, but if you are bypassing OS disk
quiesce (VMWare snapshot) and doing transparent NetApp level snapshot,
then why do you even need SMVI installed? Can't we just do the regular
filer level snap schedule? We just upgraded to 1.01 and noticed the
checkbox and were wondering about its potential use. Any ideas?

thanks
-G

Darren.Sykes at csr

Jan 12, 2009, 1:10 PM

Post #8 of 15 (4489 views)
Permalink

Re: SMVI - Limitations? [In reply to]

I thought it wasn't able to do that - just on a datastore level?

I'm pretty sure we had to move the machines which wouldn't snapshot properly
onto a dedicated datastore so we could continue to use SMVI for all of our
machines.

We've also got a case open with Netapp and VMWare in an attempt to fix some
bugs in VMWare tools for Windows to handle snapshotting better when
triggered by SMVI.

On 12/01/2009 19:05, "Ken Williams" <kwillia [at] smud> wrote:

> Sounds like it can be used on a per machine basis, so it would be good
> to exclude trouble machines.
>
> -----Original Message-----
> From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
> On Behalf Of Sto Rage(c)
> Sent: Friday, January 09, 2009 3:22 PM
> To: toasters [at] mathworks
> Subject: Re: SMVI - Limitations?
>
> On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes [at] csr>
> wrote:
>> You can tell SMVI (v1.1) not to perform OS level disk quiecing on
>> those machines if that's any use to you?
>> You'll then get a completely transparent Netapp level snapshot and
>> won't interfere with the VM itself.
>>
>> Darren
> It is SMVI v1.01 BTW, not 1.1
> Not sure I understand this correctly, but if you are bypassing OS disk
> quiesce (VMWare snapshot) and doing transparent NetApp level snapshot,
> then why do you even need SMVI installed? Can't we just do the regular
> filer level snap schedule? We just upgraded to 1.01 and noticed the
> checkbox and were wondering about its potential use. Any ideas?
>
> thanks
> -G
>
>
>
>
>
> To report this email as spam click
> https://www.mailcontrol.com/sr/H7sixEVl!03TndxI!oX7UuoY1VmXKYhKDpIkVl+IfrGcpP6
> aV5!Lv4tbBLjXYqeMVvstNucRnUJGp10b+rkp2Q== .

Darren.Sykes at csr

Jan 14, 2009, 4:25 AM

Post #9 of 15 (4462 views)
Permalink

RE: SMVI - Limitations? [In reply to]

SMVI uses snapshot 'normal' snapshot functionality of the filer so the
granularity is constrained by that.

At the current time, you cannot snapshot a file of files within a
volume/qtree so in your scenario, you'd consume more than the necessary
amount of storage space in creating a snapshot.

To get around that you could either:

1) Reorganise your Datastores (perhaps using Storage VMotion) so that
VMs with common snapshot/backup requirements live on the same Datastore

2) Hope that Netapp release additional functionality in OnTAP (and
corresponding features in SMVI) so that you can snapshot individual
files.

The only other thing to note is that SMVI does allow you select a subset
of VM's on a datastore for backup. The effect this has is that SMVI
doesn't waste time quiecing the VM's that you haven't included in the
backup job.

Darren

-----Original Message-----
From: Kumar, Rahul [mailto:kumarrahul [at] siemens]
Sent: 14 January 2009 10:07
To: Sto Rage(c) ; toasters [at] mathworks; Darren Sykes;
Adam.Fox [at] netapp
Subject: RE: SMVI - Limitations?

Hi Toasters

A general scene and a question related to it.

We have over 5TB of NFS datastore spread across various qtrees.

We were evaluating SMVI and came to know that it also requires
snaprestore to restore the VM's

Now my question is that if e.g there was a qtree with say 50 vms on it
and we'd like to snapshot only a few of them. Will this work ?

When a snap is created on the filer it will capture all the VM's thus
eating up valuable disk space from the snapreserve as time goes by.

Next when we do a restore of the individual machine, it does a snap
restore, however I am not sure if this only restores the individual
machine or the entire stuff

Any insight/help into this will be helpful

Thanks
Rahul

-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of Sto Rage(c)
Sent: Saturday, January 10, 2009 4:52 AM
To: toasters [at] mathworks
Subject: Re: SMVI - Limitations?

On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes [at] csr>
wrote:
> You can tell SMVI (v1.1) not to perform OS level disk quiecing on
those
> machines if that's any use to you?
> You'll then get a completely transparent Netapp level snapshot and
won't
> interfere with the VM itself.
>
> Darren
It is SMVI v1.01 BTW, not 1.1
Not sure I understand this correctly, but if you are bypassing OS
disk quiesce (VMWare snapshot) and doing transparent NetApp level
snapshot, then why do you even need SMVI installed? Can't we just do
the regular filer level snap schedule? We just upgraded to 1.01 and
noticed the checkbox and were wondering about its potential use. Any
ideas?

thanks
-G

To report this email as spam click
https://www.mailcontrol.com/sr/vp!1JnK84mHTndxI!oX7Ug+zP6wRoWawawux2rV25
mcJ4jEHfEKQsBBo5y31p0!L1slOaqyO5jedye7!a4hOmw== .

Adam.Fox at netapp

Jan 14, 2009, 8:20 AM

Post #10 of 15 (4431 views)
Permalink

RE: SMVI - Limitations? [In reply to]

WAFL Snapshots are always at the volume level. If you use the snap
restore software on the controller, you can restore either the entire
volume or an individual file level.

Hope this helps.

-- Adam Fox
Systems Engineer
adamfox [at] netapp

-----Original Message-----
From: Kumar, Rahul [mailto:kumarrahul [at] siemens]
Sent: Wednesday, January 14, 2009 5:07 AM
To: Sto Rage(c) ; toasters [at] mathworks; Darren.Sykes [at] csr; Fox,
Adam
Subject: RE: SMVI - Limitations?

Hi Toasters

A general scene and a question related to it.

We have over 5TB of NFS datastore spread across various qtrees.

We were evaluating SMVI and came to know that it also requires
snaprestore to restore the VM's

Now my question is that if e.g there was a qtree with say 50 vms on it
and we'd like to snapshot only a few of them. Will this work ?

When a snap is created on the filer it will capture all the VM's thus
eating up valuable disk space from the snapreserve as time goes by.

Next when we do a restore of the individual machine, it does a snap
restore, however I am not sure if this only restores the individual
machine or the entire stuff

Any insight/help into this will be helpful

Thanks
Rahul

-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of Sto Rage(c)
Sent: Saturday, January 10, 2009 4:52 AM
To: toasters [at] mathworks
Subject: Re: SMVI - Limitations?

On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes [at] csr>
wrote:
> You can tell SMVI (v1.1) not to perform OS level disk quiecing on
those
> machines if that's any use to you?
> You'll then get a completely transparent Netapp level snapshot and
won't
> interfere with the VM itself.
>
> Darren
It is SMVI v1.01 BTW, not 1.1
Not sure I understand this correctly, but if you are bypassing OS
disk quiesce (VMWare snapshot) and doing transparent NetApp level
snapshot, then why do you even need SMVI installed? Can't we just do
the regular filer level snap schedule? We just upgraded to 1.01 and
noticed the checkbox and were wondering about its potential use. Any
ideas?

thanks
-G

Adam.Fox at netapp

Jan 14, 2009, 9:37 AM

Post #11 of 15 (4440 views)
Permalink

RE: SMVI - Limitations? [In reply to]

I have to admit, I am not an SMVI expert, but I do know a thing or three
about WAFL so I was speaking specifically about how snapshots and
SnapRestore work at the ONTAP/WAFL level.

As far as dedup (SIS), I'm not sure if I understand how/if it would
"interfere" with a SnapRestore.
In the case of a volume-level SnapRestore, the volume reverts back to
the way it looked at the time of the snapshot used for the SnapRestore,
and dedup would be no different there since the block pointers as well
as the fingerprint file would be a part of the SnapRestore. I've
actually never tried to figure out how it would work with a single-file
SnapRestore. The good news is that with the release of the 7.3
simulator, which supports dedup, anyone can try it in their lab without
touching their production stuff (on a smaller scale, of course). At
most, you might have to re-run a full scan, but I'm honestly not sure.

-- Adam Fox
Systems Engineer
adamfox [at] netapp

-----Original Message-----
From: Kumar, Rahul [mailto:kumarrahul [at] siemens]
Sent: Wednesday, January 14, 2009 12:09 PM
To: Fox, Adam; Sto Rage(c) ; toasters [at] mathworks;
Darren.Sykes [at] csr
Subject: RE: SMVI - Limitations?

Adam

So in theory, the snaprestore via smvi does actually do an individual
file restores (talking about the a single vm restore) though there may
be 100 of vms on the volume.

So that does mean that we need to dedicate/separate volumes according to
the usage etc.
Also does SIS interfere when vm snaprestores are done by any chance ?

Thanks for making the issue clear.. I am not in grip of the scenario and
possible workarounds or new processes to b e followed

Rahul

-----Original Message-----
From: Fox, Adam [mailto:Adam.Fox [at] netapp]
Sent: Wednesday, January 14, 2009 9:51 PM
To: Kumar, Rahul; Sto Rage(c) ; toasters [at] mathworks;
Darren.Sykes [at] csr
Subject: RE: SMVI - Limitations?

WAFL Snapshots are always at the volume level. If you use the snap
restore software on the controller, you can restore either the entire
volume or an individual file level.

Hope this helps.

-- Adam Fox
Systems Engineer
adamfox [at] netapp

-----Original Message-----
From: Kumar, Rahul [mailto:kumarrahul [at] siemens]
Sent: Wednesday, January 14, 2009 5:07 AM
To: Sto Rage(c) ; toasters [at] mathworks; Darren.Sykes [at] csr; Fox,
Adam
Subject: RE: SMVI - Limitations?

Hi Toasters

A general scene and a question related to it.

We have over 5TB of NFS datastore spread across various qtrees.

We were evaluating SMVI and came to know that it also requires
snaprestore to restore the VM's

Now my question is that if e.g there was a qtree with say 50 vms on it
and we'd like to snapshot only a few of them. Will this work ?

When a snap is created on the filer it will capture all the VM's thus
eating up valuable disk space from the snapreserve as time goes by.

Next when we do a restore of the individual machine, it does a snap
restore, however I am not sure if this only restores the individual
machine or the entire stuff

Any insight/help into this will be helpful

Thanks
Rahul

-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of Sto Rage(c)
Sent: Saturday, January 10, 2009 4:52 AM
To: toasters [at] mathworks
Subject: Re: SMVI - Limitations?

On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes [at] csr>
wrote:
> You can tell SMVI (v1.1) not to perform OS level disk quiecing on
those
> machines if that's any use to you?
> You'll then get a completely transparent Netapp level snapshot and
won't
> interfere with the VM itself.
>
> Darren
It is SMVI v1.01 BTW, not 1.1
Not sure I understand this correctly, but if you are bypassing OS
disk quiesce (VMWare snapshot) and doing transparent NetApp level
snapshot, then why do you even need SMVI installed? Can't we just do
the regular filer level snap schedule? We just upgraded to 1.01 and
noticed the checkbox and were wondering about its potential use. Any
ideas?

thanks
-G

ggwalker at mindspring

Jan 14, 2009, 9:27 PM

Post #12 of 15 (4469 views)
Permalink

RE: SMVI - Limitations? [In reply to]

Single File Snap Restore (especially with ASIS) is a bit slow\painful.
7.3.1 code (maybe even 7.3) is supposed to make File Cloning a reality,
much like you can do with LUNs today - this should help a great deal.

Because of the slow SFSR, we've been using CP from the ESX CLI to get
the data back out of snapshots - unfortunately, this means that the
VMDKs are thick again and will have to be deduped during the next run.

I should probably preface the above with the fact we're running VMWare
storage over NFS. If you were using LUNs, you'd be using the LUN
Clone\Split functionality to recover data which is blazing fast - but it
also means you're recovering an entire LUN and everything within it
(similar to Snap Restore at the volume level)... NFS allows us to
recover single VMDKs, but we're suffering a bit due to the newness of
the solution set.

Looking forward to the improved functionality - there's no way I'd ever
consider ESX over anything other than NFS!

Glenn

-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of Fox, Adam
Sent: Wednesday, January 14, 2009 12:37 PM
To: Kumar, Rahul; Sto Rage(c) ; toasters [at] mathworks;
Darren.Sykes [at] csr
Subject: RE: SMVI - Limitations?

I have to admit, I am not an SMVI expert, but I do know a thing or three
about WAFL so I was speaking specifically about how snapshots and
SnapRestore work at the ONTAP/WAFL level.

As far as dedup (SIS), I'm not sure if I understand how/if it would
"interfere" with a SnapRestore.
In the case of a volume-level SnapRestore, the volume reverts back to
the way it looked at the time of the snapshot used for the SnapRestore,
and dedup would be no different there since the block pointers as well
as the fingerprint file would be a part of the SnapRestore. I've
actually never tried to figure out how it would work with a single-file
SnapRestore. The good news is that with the release of the 7.3
simulator, which supports dedup, anyone can try it in their lab without
touching their production stuff (on a smaller scale, of course). At
most, you might have to re-run a full scan, but I'm honestly not sure.

-- Adam Fox
Systems Engineer
adamfox [at] netapp

-----Original Message-----
From: Kumar, Rahul [mailto:kumarrahul [at] siemens]
Sent: Wednesday, January 14, 2009 12:09 PM
To: Fox, Adam; Sto Rage(c) ; toasters [at] mathworks;
Darren.Sykes [at] csr
Subject: RE: SMVI - Limitations?

Adam

So in theory, the snaprestore via smvi does actually do an individual
file restores (talking about the a single vm restore) though there may
be 100 of vms on the volume.

So that does mean that we need to dedicate/separate volumes according to
the usage etc.
Also does SIS interfere when vm snaprestores are done by any chance ?

Thanks for making the issue clear.. I am not in grip of the scenario and
possible workarounds or new processes to b e followed

Rahul

-----Original Message-----
From: Fox, Adam [mailto:Adam.Fox [at] netapp]
Sent: Wednesday, January 14, 2009 9:51 PM
To: Kumar, Rahul; Sto Rage(c) ; toasters [at] mathworks;
Darren.Sykes [at] csr
Subject: RE: SMVI - Limitations?

WAFL Snapshots are always at the volume level. If you use the snap
restore software on the controller, you can restore either the entire
volume or an individual file level.

Hope this helps.

-- Adam Fox
Systems Engineer
adamfox [at] netapp

-----Original Message-----
From: Kumar, Rahul [mailto:kumarrahul [at] siemens]
Sent: Wednesday, January 14, 2009 5:07 AM
To: Sto Rage(c) ; toasters [at] mathworks; Darren.Sykes [at] csr; Fox,
Adam
Subject: RE: SMVI - Limitations?

Hi Toasters

A general scene and a question related to it.

We have over 5TB of NFS datastore spread across various qtrees.

We were evaluating SMVI and came to know that it also requires
snaprestore to restore the VM's

Now my question is that if e.g there was a qtree with say 50 vms on it
and we'd like to snapshot only a few of them. Will this work ?

When a snap is created on the filer it will capture all the VM's thus
eating up valuable disk space from the snapreserve as time goes by.

Next when we do a restore of the individual machine, it does a snap
restore, however I am not sure if this only restores the individual
machine or the entire stuff

Any insight/help into this will be helpful

Thanks
Rahul

-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of Sto Rage(c)
Sent: Saturday, January 10, 2009 4:52 AM
To: toasters [at] mathworks
Subject: Re: SMVI - Limitations?

On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes [at] csr>
wrote:
> You can tell SMVI (v1.1) not to perform OS level disk quiecing on
those
> machines if that's any use to you?
> You'll then get a completely transparent Netapp level snapshot and
won't
> interfere with the VM itself.
>
> Darren
It is SMVI v1.01 BTW, not 1.1
Not sure I understand this correctly, but if you are bypassing OS
disk quiesce (VMWare snapshot) and doing transparent NetApp level
snapshot, then why do you even need SMVI installed? Can't we just do
the regular filer level snap schedule? We just upgraded to 1.01 and
noticed the checkbox and were wondering about its potential use. Any
ideas?

thanks
-G

Darren.Sykes at csr

Jan 15, 2009, 12:50 AM

Post #13 of 15 (4410 views)
Permalink

Re: SMVI - Limitations? [In reply to]

I thought individual file cloning was not a feature which Netapp had
publically announced (so tried to avoid mentioning it!). Maybe I'm behind
the times....

On 15/01/2009 05:27, "Glenn Walker" <ggwalker [at] mindspring> wrote:

> Single File Snap Restore (especially with ASIS) is a bit slow\painful.
> 7.3.1 code (maybe even 7.3) is supposed to make File Cloning a reality,
> much like you can do with LUNs today - this should help a great deal.
>
> Because of the slow SFSR, we've been using CP from the ESX CLI to get
> the data back out of snapshots - unfortunately, this means that the
> VMDKs are thick again and will have to be deduped during the next run.
>
> I should probably preface the above with the fact we're running VMWare
> storage over NFS. If you were using LUNs, you'd be using the LUN
> Clone\Split functionality to recover data which is blazing fast - but it
> also means you're recovering an entire LUN and everything within it
> (similar to Snap Restore at the volume level)... NFS allows us to
> recover single VMDKs, but we're suffering a bit due to the newness of
> the solution set.
>
> Looking forward to the improved functionality - there's no way I'd ever
> consider ESX over anything other than NFS!
>
> Glenn
>
> -----Original Message-----
> From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
> On Behalf Of Fox, Adam
> Sent: Wednesday, January 14, 2009 12:37 PM
> To: Kumar, Rahul; Sto Rage(c) ; toasters [at] mathworks;
> Darren.Sykes [at] csr
> Subject: RE: SMVI - Limitations?
>
> I have to admit, I am not an SMVI expert, but I do know a thing or three
> about WAFL so I was speaking specifically about how snapshots and
> SnapRestore work at the ONTAP/WAFL level.
>
> As far as dedup (SIS), I'm not sure if I understand how/if it would
> "interfere" with a SnapRestore.
> In the case of a volume-level SnapRestore, the volume reverts back to
> the way it looked at the time of the snapshot used for the SnapRestore,
> and dedup would be no different there since the block pointers as well
> as the fingerprint file would be a part of the SnapRestore. I've
> actually never tried to figure out how it would work with a single-file
> SnapRestore. The good news is that with the release of the 7.3
> simulator, which supports dedup, anyone can try it in their lab without
> touching their production stuff (on a smaller scale, of course). At
> most, you might have to re-run a full scan, but I'm honestly not sure.
>
> -- Adam Fox
> Systems Engineer
> adamfox [at] netapp
>
>
> -----Original Message-----
> From: Kumar, Rahul [mailto:kumarrahul [at] siemens]
> Sent: Wednesday, January 14, 2009 12:09 PM
> To: Fox, Adam; Sto Rage(c) ; toasters [at] mathworks;
> Darren.Sykes [at] csr
> Subject: RE: SMVI - Limitations?
>
> Adam
>
> So in theory, the snaprestore via smvi does actually do an individual
> file restores (talking about the a single vm restore) though there may
> be 100 of vms on the volume.
>
> So that does mean that we need to dedicate/separate volumes according to
> the usage etc.
> Also does SIS interfere when vm snaprestores are done by any chance ?
>
> Thanks for making the issue clear.. I am not in grip of the scenario and
> possible workarounds or new processes to b e followed
>
> Rahul
>
> -----Original Message-----
> From: Fox, Adam [mailto:Adam.Fox [at] netapp]
> Sent: Wednesday, January 14, 2009 9:51 PM
> To: Kumar, Rahul; Sto Rage(c) ; toasters [at] mathworks;
> Darren.Sykes [at] csr
> Subject: RE: SMVI - Limitations?
>
> WAFL Snapshots are always at the volume level. If you use the snap
> restore software on the controller, you can restore either the entire
> volume or an individual file level.
>
> Hope this helps.
>
> -- Adam Fox
> Systems Engineer
> adamfox [at] netapp
>
> -----Original Message-----
> From: Kumar, Rahul [mailto:kumarrahul [at] siemens]
> Sent: Wednesday, January 14, 2009 5:07 AM
> To: Sto Rage(c) ; toasters [at] mathworks; Darren.Sykes [at] csr; Fox,
> Adam
> Subject: RE: SMVI - Limitations?
>
> Hi Toasters
>
> A general scene and a question related to it.
>
> We have over 5TB of NFS datastore spread across various qtrees.
>
> We were evaluating SMVI and came to know that it also requires
> snaprestore to restore the VM's
>
> Now my question is that if e.g there was a qtree with say 50 vms on it
> and we'd like to snapshot only a few of them. Will this work ?
>
> When a snap is created on the filer it will capture all the VM's thus
> eating up valuable disk space from the snapreserve as time goes by.
>
> Next when we do a restore of the individual machine, it does a snap
> restore, however I am not sure if this only restores the individual
> machine or the entire stuff
>
> Any insight/help into this will be helpful
>
>
> Thanks
> Rahul
>
>
>
>
>
> -----Original Message-----
> From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
> On Behalf Of Sto Rage(c)
> Sent: Saturday, January 10, 2009 4:52 AM
> To: toasters [at] mathworks
> Subject: Re: SMVI - Limitations?
>
> On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes [at] csr>
> wrote:
>> You can tell SMVI (v1.1) not to perform OS level disk quiecing on
> those
>> machines if that's any use to you?
>> You'll then get a completely transparent Netapp level snapshot and
> won't
>> interfere with the VM itself.
>>
>> Darren
> It is SMVI v1.01 BTW, not 1.1
> Not sure I understand this correctly, but if you are bypassing OS
> disk quiesce (VMWare snapshot) and doing transparent NetApp level
> snapshot, then why do you even need SMVI installed? Can't we just do
> the regular filer level snap schedule? We just upgraded to 1.01 and
> noticed the checkbox and were wondering about its potential use. Any
> ideas?
>
> thanks
> -G
>
>
>
> To report this email as spam click
> https://www.mailcontrol.com/sr/ug0PLQWh+NDTndxI!oX7Us7PAc+Gwoki+tHufSOOive2d!w
> jVlrCgJRg5dmIWyzIG+CHg+eM4kfwq3xXRfv08Q== .

ggwalker at mindspring

Jan 15, 2009, 12:39 PM

Post #14 of 15 (4381 views)
Permalink

RE: SMVI - Limitations? [In reply to]

Well, crap:

"Users can't clone a file or a LUN that exists only in a Snapshot. The
file or LUN must exist in the active file system."

So much for 'recovery'... this is great for deployment, however. Wonder
if there is a caveat that the file must be cloned to the same flexvol.
I _know_ it will mean same aggregate (which kills our deployment from
templates already).

Bummer...

-----Original Message-----
From: Matt Hallmark [mailto:matt [at] cosmictoaster]
Sent: Thursday, January 15, 2009 11:15 AM
To: Darren Sykes
Cc: Glenn Walker; Fox, Adam; Kumar, Rahul; Sto Rage(c);
toasters [at] mathworks
Subject: Re: SMVI - Limitations?

http://blog.scottlowe.org/2008/12/03/2031-enhancements-to-netapp-cloning
-technology/

Looks like it's single-file flex clone, w/o having to have a snap
behind the clone.

I'd thought that I'd seen mention of it on NetApp's Storage Nuts 'n
Bolts Blog as well, but I didn't find it again in a few minutes of
searching.

We'll see once 7.3.1 is out, which is "Real Soon Now" according to my
sources. :)

Matt

On Jan 15, 2009, at 12:50 AM, Darren Sykes wrote:

> I thought individual file cloning was not a feature which Netapp had
> publically announced (so tried to avoid mentioning it!). Maybe I'm
> behind
> the times....
>
>
>
> On 15/01/2009 05:27, "Glenn Walker" <ggwalker [at] mindspring> wrote:
>
>> Single File Snap Restore (especially with ASIS) is a bit slow
>> \painful.
>> 7.3.1 code (maybe even 7.3) is supposed to make File Cloning a
>> reality,
>> much like you can do with LUNs today - this should help a great deal.
>>
>> Because of the slow SFSR, we've been using CP from the ESX CLI to get
>> the data back out of snapshots - unfortunately, this means that the
>> VMDKs are thick again and will have to be deduped during the next
>> run.
>>
>> I should probably preface the above with the fact we're running
>> VMWare
>> storage over NFS. If you were using LUNs, you'd be using the LUN
>> Clone\Split functionality to recover data which is blazing fast -
>> but it
>> also means you're recovering an entire LUN and everything within it
>> (similar to Snap Restore at the volume level)... NFS allows us to
>> recover single VMDKs, but we're suffering a bit due to the newness of
>> the solution set.
>>
>> Looking forward to the improved functionality - there's no way I'd
>> ever
>> consider ESX over anything other than NFS!
>>
>> Glenn
>>
>> -----Original Message-----
>> From: owner-toasters [at] mathworks
[mailto:owner-toasters [at] mathworks
>> ]
>> On Behalf Of Fox, Adam
>> Sent: Wednesday, January 14, 2009 12:37 PM
>> To: Kumar, Rahul; Sto Rage(c) ; toasters [at] mathworks;
>> Darren.Sykes [at] csr
>> Subject: RE: SMVI - Limitations?
>>
>> I have to admit, I am not an SMVI expert, but I do know a thing or
>> three
>> about WAFL so I was speaking specifically about how snapshots and
>> SnapRestore work at the ONTAP/WAFL level.
>>
>> As far as dedup (SIS), I'm not sure if I understand how/if it would
>> "interfere" with a SnapRestore.
>> In the case of a volume-level SnapRestore, the volume reverts back to
>> the way it looked at the time of the snapshot used for the
>> SnapRestore,
>> and dedup would be no different there since the block pointers as
>> well
>> as the fingerprint file would be a part of the SnapRestore. I've
>> actually never tried to figure out how it would work with a single-
>> file
>> SnapRestore. The good news is that with the release of the 7.3
>> simulator, which supports dedup, anyone can try it in their lab
>> without
>> touching their production stuff (on a smaller scale, of course). At
>> most, you might have to re-run a full scan, but I'm honestly not
>> sure.
>>
>> -- Adam Fox
>> Systems Engineer
>> adamfox [at] netapp
>>
>>
>> -----Original Message-----
>> From: Kumar, Rahul [mailto:kumarrahul [at] siemens]
>> Sent: Wednesday, January 14, 2009 12:09 PM
>> To: Fox, Adam; Sto Rage(c) ; toasters [at] mathworks;
>> Darren.Sykes [at] csr
>> Subject: RE: SMVI - Limitations?
>>
>> Adam
>>
>> So in theory, the snaprestore via smvi does actually do an individual
>> file restores (talking about the a single vm restore) though there
>> may
>> be 100 of vms on the volume.
>>
>> So that does mean that we need to dedicate/separate volumes
>> according to
>> the usage etc.
>> Also does SIS interfere when vm snaprestores are done by any chance ?
>>
>> Thanks for making the issue clear.. I am not in grip of the
>> scenario and
>> possible workarounds or new processes to b e followed
>>
>> Rahul
>>
>> -----Original Message-----
>> From: Fox, Adam [mailto:Adam.Fox [at] netapp]
>> Sent: Wednesday, January 14, 2009 9:51 PM
>> To: Kumar, Rahul; Sto Rage(c) ; toasters [at] mathworks;
>> Darren.Sykes [at] csr
>> Subject: RE: SMVI - Limitations?
>>
>> WAFL Snapshots are always at the volume level. If you use the snap
>> restore software on the controller, you can restore either the entire
>> volume or an individual file level.
>>
>> Hope this helps.
>>
>> -- Adam Fox
>> Systems Engineer
>> adamfox [at] netapp
>>
>> -----Original Message-----
>> From: Kumar, Rahul [mailto:kumarrahul [at] siemens]
>> Sent: Wednesday, January 14, 2009 5:07 AM
>> To: Sto Rage(c) ; toasters [at] mathworks; Darren.Sykes [at] csr; Fox,
>> Adam
>> Subject: RE: SMVI - Limitations?
>>
>> Hi Toasters
>>
>> A general scene and a question related to it.
>>
>> We have over 5TB of NFS datastore spread across various qtrees.
>>
>> We were evaluating SMVI and came to know that it also requires
>> snaprestore to restore the VM's
>>
>> Now my question is that if e.g there was a qtree with say 50 vms on
>> it
>> and we'd like to snapshot only a few of them. Will this work ?
>>
>> When a snap is created on the filer it will capture all the VM's thus
>> eating up valuable disk space from the snapreserve as time goes by.
>>
>> Next when we do a restore of the individual machine, it does a snap
>> restore, however I am not sure if this only restores the individual
>> machine or the entire stuff
>>
>> Any insight/help into this will be helpful
>>
>>
>> Thanks
>> Rahul
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: owner-toasters [at] mathworks
[mailto:owner-toasters [at] mathworks
>> ]
>> On Behalf Of Sto Rage(c)
>> Sent: Saturday, January 10, 2009 4:52 AM
>> To: toasters [at] mathworks
>> Subject: Re: SMVI - Limitations?
>>
>> On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes <Darren.Sykes [at] csr>
>> wrote:
>>> You can tell SMVI (v1.1) not to perform OS level disk quiecing on
>> those
>>> machines if that's any use to you?
>>> You'll then get a completely transparent Netapp level snapshot and
>> won't
>>> interfere with the VM itself.
>>>
>>> Darren
>> It is SMVI v1.01 BTW, not 1.1
>> Not sure I understand this correctly, but if you are bypassing OS
>> disk quiesce (VMWare snapshot) and doing transparent NetApp level
>> snapshot, then why do you even need SMVI installed? Can't we just do
>> the regular filer level snap schedule? We just upgraded to 1.01 and
>> noticed the checkbox and were wondering about its potential use. Any
>> ideas?
>>
>> thanks
>> -G
>>
>>
>>
>> To report this email as spam click
>>
https://www.mailcontrol.com/sr/ug0PLQWh+NDTndxI!oX7Us7PAc+Gwoki+tHufSOOi
ve2d!w
>> jVlrCgJRg5dmIWyzIG+CHg+eM4kfwq3xXRfv08Q== .
>

slowe at EPLUS

Jan 15, 2009, 1:00 PM

Post #15 of 15 (4390 views)
Permalink

Re: SMVI - Limitations? [In reply to]

Please read my responses inline below.

On Jan 15, 2009, at 3:39 PM, Glenn Walker wrote:

> Well, crap:
>
> "Users can't clone a file or a LUN that exists only in a Snapshot. The
> file or LUN must exist in the active file system."
>
> So much for 'recovery'... this is great for deployment, however.
> Wonder
> if there is a caveat that the file must be cloned to the same flexvol.
> I _know_ it will mean same aggregate (which kills our deployment from
> templates already).

You are correct--from everything I have seen, you will have to clone
to the same FlexVol.

--
Scott

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads