Misleading diagram in VSAManual.pdf
VSA Community Forum
LeftHand VSA Forum
Home       Members    Calendar    Who's On
Welcome Guest ( Login | Register )
        



Misleading diagram in VSAManual.pdf Expand / Collapse
Author
Message
Posted Wednesday, April 02, 2008 3:25 AM
Forum Member

Forum MemberForum MemberForum MemberForum MemberForum MemberForum MemberForum MemberForum Member

Group: Forum Members
Last Login: Wednesday, July 09, 2008 5:59 PM
Posts: 30, Visits: 47
Once I start thinking about an NSM I realized why I was having difficultly with ESX Networking and VSA. The diagram only shows one vNic on the VN Network vSwitch. Not real world. I need one vNic for access to the VM, and one vNic for the SAN.

So, back to my question. Can the second vNic for the Virtual Machine Network vSwitch be the same vNIC that the VSA NET is using? This would software-bridge/route the VSA to the VM? Or will that break ESX?


Regards, Rich

HP ML350 SATA with VSA
Post #200
Posted Wednesday, April 02, 2008 12:29 PM
Supreme Being

Supreme BeingSupreme BeingSupreme BeingSupreme BeingSupreme BeingSupreme BeingSupreme BeingSupreme Being

Group: Moderators
Last Login: Yesterday @ 3:37 PM
Posts: 108, Visits: 375
Sorry if that screen shot was misleading.
It is a real world configuration though for accessing VSA through VMware iSCSI. Its actually a screen shot of my networking configuration that I've used since VMworld 07. The VMkernel is what does iSCSI traffic for ESX, and it is on the same V switch as the VSA. Which is ideal. The guest OS does not need to directly route to the VSA. It can get its disk as an RDM or VMDK from ESX.

It sounds to me like what you are trying to do is use a guest OS software initiator to give direct iSCSI access to a VM. Which is fine.
If that is what you mean then you should still use the networking configuration best practices from the user manual. All you need to do is add another virtual nic to your guest OS that is on the same V switch as the VSA, the "VSA Net" in the diagram.

This is the virtual equivalent of what physical hosts typically do. They usually are dual networked with one network connected directly to the SAN network that they use for iSCSI traffic.

Hope that helps.


Adam C
Product Manager
LeftHand Networks
Post #201
Posted Wednesday, April 02, 2008 5:24 PM
Forum Member

Forum MemberForum MemberForum MemberForum MemberForum MemberForum MemberForum MemberForum Member

Group: Forum Members
Last Login: Wednesday, July 09, 2008 5:59 PM
Posts: 30, Visits: 47
I was in LHN training today and got certified. The trainor told me that the VM Network vSwitch should be able to internal route to the VSA NET vSwitch. He couldn't remember exactly how to do it, but said he did it in VMWare class. I need this. It just doesn't make sense for the VM to have to hit the external switch and then come back in.

Sorry to be beating this to death Adam. I am getting too many conflicting answers.


Regards, Rich

HP ML350 SATA with VSA
Post #202
Posted Friday, April 04, 2008 11:43 AM
Supreme Being

Supreme BeingSupreme BeingSupreme BeingSupreme BeingSupreme BeingSupreme BeingSupreme BeingSupreme Being

Group: Moderators
Last Login: Yesterday @ 3:37 PM
Posts: 108, Visits: 375
Hmm, delicate. But to be an arrogant prick. Whomever said that was just wrong.
VMware virtual switches do not route to each other on their own.
The only way within an ESX server I know is to use a virtual appliance router or a VM to bridge the virtual switches but that is only interesting if you are trying to learn about routing in a lab.

Why are you not just giving your VMs a second virtual nic on the VSA Net? That does exactly what you are asking and would be the best practice for using guest OS initiators (that is what you are trying to do right?).
This let's VMs access the SAN on that VSA Net without going out to a physical switch.


Adam C
Product Manager
LeftHand Networks
Post #204
« Prev Topic | Next Topic »


All times are GMT -6:00, Time now is 12:11am

Powered By InstantForum.NET v4.1.4 © 2008
Execution: 0.031. 13 queries. Compression Disabled.