Hi Neis

 

Brent and other were rights.

For which concern mixed environment where having VMFS LUNs by FC and guest running iSCSI to attach LUN by this last protocol is not a problem. We use them since VMware 2.5 and they work with no suffering or performances penalty on guests. This is the only way toh ave Snapdrive and Snapmanager products working inside a guest for the FC HBA aren’t virtualized and exposed from ESX to the guests. So you have to mix FC for VMFS and iSCSI from guest if you want, I repeat, to use Snapdrive a/o Snapmanager.

But there’s another way to expose to guests parts of the FC SAN storage: the raw device and its mapping on guest. This is the way i.e., the only one, to create a MS cluster formed by to VMs or a mixed physical/virtual. But, here, you can not use SD/SM.

But reading you it seems you have other kind of doubts.

 

If you already have LUNs containing db data you can easily mount on the guests once you have i.e. virtualized the old physical server. Or maybe you can start from scratch installing new guests, the Exchange software and the reattaching to them the iSCSI LUN…more jobs to do to restore Exchange on another server anyway!

 

 

Da: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] Per conto di Neis, Mark
Inviato: martedì 20 maggio 2008 18.04
A: toasters@mathworks.com
Oggetto: Re: Another Snapmanager Question (MS Exchange, VMware ESX)

 

Hi Nils,

 

you wrote:

> For every customer a different scenario offcourse, but you can install MS iSCSI Initiator in

> a VM, stack SnapDrive on top of that, and in this way run SnapManager for Exchange.

> Basically, you connect a dedicated LUN from within the VM directly to a NetApp, and not

> use any VMWare functionality (except for OS disks) to run Exchange.

> 

> This way you have your snapshotted LUNs and you can back them up any way you like.

 

 

I'm afraid I wasn't fully clear. We just replaced a FAS940c by a 3070c which is attached to the

(already existing) FC fabric. The FAS940c wasn't. That's why we used iSCSI for our other

customers in the past. But now we would like to get the storage from the FC fabric.

The problem, as I see it, is that afaik there is no way to attach the fabric to the guest OS directly,

as you'd need a FC HBA inside the VM.

 

From the point of view of the guest OS, the storage that is attached to the ESX looks just like an

ordinary hard drive. And I suppose SnapDrive won't work if there is no LUNs for it to see.

However, to keep the Exchange storage groups consistent when doing back up, you need to start

the backup from within the guest OS. We might use the NT backup mechanism, though - but I'm

not yet sure if that's our best bet.

 

 

> There are many variation to this theme, and I heard rumours that NetApp is working on

> expanding possibilities of SnapManager for VI and SnapDrive, but I'm sure your SE will

> have more information on that ;)

 

I hope so - but I figured I had better try to check the possibilities there are so I'd be able to

ask the right questions ;)

 


Kind regards,
Mark Neis

--

Mark Neis
System Administrator

GISA GmbH
Chemnitztalstr. 13
09114 Chemnitz
Tel. +49.(0)371.482.6737
Fax  +49.(0)345.585.100.6737

GISA GmbH - Geschäftsführer: Michael Krüger; Sitz der Gesellschaft: Halle (Saale); Registergericht: Amtsgericht Stendal; Handelsregister-Nr. HRB 208414; UST-IdNr: DE 158253683

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Empfänger sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail oder des Inhalts dieser Mail sind nicht gestattet. Diese Kommunikation per E-Mail ist nicht gegen den Zugriff durch Dritte geschützt. Die GISA GmbH haftet ausdrücklich nicht für den Inhalt und die Vollständigkeit von E-Mails und den gegebenenfalls daraus entsehenden Schaden. Sollte trotz der bestehenden Viren-Schutzprogramme durch diese E-Mail ein Virus in Ihr System gelangen, so haftet die GISA GmbH - soweit gesetzlich zulässig - nicht für die hieraus entstehenden Schäden.