Has anyone migrated from RDM to a standard VMFS or NFS Datastore? I was hoping Svmotion would handle the move without powering down the virtual machine but it looks like that may not be supported.
I'd like to accomplish this without outages (or extremely limited downtime for the hosts), any ideas?
__________________________________________________________ Ken Williams Storage Administrator, Business Technology Operations Sacramento Municipal Utility District E-Mail: kwillia@smud.org Phone: (916) 732-6744 Cell: (916) 240-4213
Snapmanager for Virtual Infrastructure, RDM to VMFS/NFS Migrations...I doubt SVMotion will handle it as VMware does not know what is inside an RDM LUN. ----- Original Message ----- From: Ken Williams To: toasters@mathworks.com Sent: Monday, January 05, 2009 4:21 PM Subject: Snapmanager for Virtual Infrastructure, RDM to VMFS/NFS Migrations...
Has anyone migrated from RDM to a standard VMFS or NFS Datastore? I was hoping Svmotion would handle the move without powering down the virtual machine but it looks like that may not be supported.
I'd like to accomplish this without outages (or extremely limited downtime for the hosts), any ideas?
__________________________________________________________ Ken Williams Storage Administrator, Business Technology Operations Sacramento Municipal Utility District E-Mail: kwillia@smud.org Phone: (916) 732-6744 Cell: (916) 240-4213
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@smud.org Phone: (916) 732-6744 Cell: (916) 240-4213
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@mathworks.com 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@smud.org Phone: (916) 732-6744 Cell: (916) 240-4213
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@gmail.com] Sent: Thursday, January 08, 2009 3:43 PM To: Ken Williams; toasters@mathworks.com 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@smud.org To: toasters@mathworks.com 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@smud.org Phone: (916) 732-6744 Cell: (916) 240-4213
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@mathworks.com on behalf of Ken Williams Sent: Thu 1/8/2009 23:50 To: Bill Holland; toasters@mathworks.com 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@gmail.com] Sent: Thursday, January 08, 2009 3:43 PM To: Ken Williams; toasters@mathworks.com 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@smud.org To: toasters@mathworks.com 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@smud.org 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== .
On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes Darren.Sykes@csr.com 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
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@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Sto Rage(c) Sent: Friday, January 09, 2009 3:22 PM To: toasters@mathworks.com Subject: Re: SMVI - Limitations?
On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes Darren.Sykes@csr.com 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
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@smud.org 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@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Sto Rage(c) Sent: Friday, January 09, 2009 3:22 PM To: toasters@mathworks.com Subject: Re: SMVI - Limitations?
On Fri, Jan 9, 2009 at 12:19 AM, Darren Sykes Darren.Sykes@csr.com 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+IfrGcp... aV5!Lv4tbBLjXYqeMVvstNucRnUJGp10b+rkp2Q== .
DOT version 7.2.5.1p6 FAS3070
I was testing splitting a PLEX to break an active mirror. When I split the PLEX the aggregates and volumes renamed fine but all the entries in the cifsconfig_share.cfg file were gone and all the shares disappeared as well (obviously).
The volume and cifs shares were all "online" when the split occurred.
Do I need to just make a backup of the cifsconfig_share.cfg and take the outage hit or is this not supposed to happen?
-
Bill Holland -
Darren Sykes -
Ken Williams -
Langdon, Laughlin T. (Lock) -
Sto Rage©