File locking with SAN and Linux + Windows nodes

Discussions about using Windows guests in VirtualBox.
Post Reply
Fidelity
Posts: 3
Joined: 3. Oct 2016, 16:21

File locking with SAN and Linux + Windows nodes

Post by Fidelity »

Hi,

This is a bit of an odd setup but I want to run a small cluster of: 2 Linux machines + 1 Windows Server Machine all sharing a SCSI SAN storage device. My idea was to install Redhat on all three and run cman, ricci, luci cluster services. Then install virtualbox on the 3rd with Windows under that. Install GFS2 on the SAN, mount the SAN on all 3 and finally get Virtualbox to share that mounted folder so the Windows machine can see it. Now all 3 can see the SAN

My question is, will the 3rd Redhat node still be handling the file locking underneath of what the Windows VM is doing or will Windows bypass the cluster services?
Should I just install Windows straight onto the 3rd node and use some multi platform file system (that's free) which handles file locking?
P.S. I don't care about High availability, it's just the file locking really to avoid data corruption.

Any help would be appreciated, thanks
scottgus1
Site Moderator
Posts: 20945
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Windows, Linux

Re: File locking with SAN and Linux + Windows nodes

Post by scottgus1 »

Woof! (passes over the head gesture)
I would roughly guess that not many folks here would know what you're talking about, let alone how to answer the question, unfortunately. (I may be wrong...)

But I would suggest pretending that Virtualbox isn't involved and try to figure out if Windows would cooperate with Red Hat file locking in a completely physical setup. As a rough guess you'd set up your Windows server with Bridged networking, meaning that the Windows server appears to be just another machine on your network, with all the access to other network services that the host has. So to the SAN the guest would be another machine accessing the SAN and cooperate or bungle as the guest is able to.

Fortunately Windows can be downloaded from Microsoft and used as an evaluation for some several months, and I think Red Hat might be downloaded free or on evaluation, too. So you could try it on scrapable data and see what happens.
Fidelity
Posts: 3
Joined: 3. Oct 2016, 16:21

Re: File locking with SAN and Linux + Windows nodes

Post by Fidelity »

Yer, I'm pretty sure not going down the VM route will work but it's good thing to know I think plus I don't have to install samba....
What I suppose I'm actually asking is : Do virtual machines talk to external file systems through the host kernel, if so then it should work (with file locking), if not then it won't. I guess that's more of a developer question really. I'll look for a more appropriate forum/feed.

Thank you for responding.

Regards

Pauil
scottgus1
Site Moderator
Posts: 20945
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Windows, Linux

Re: File locking with SAN and Linux + Windows nodes

Post by scottgus1 »

Fidelity wrote:Do virtual machines talk to external file systems through the host kernel
When using Virtualbox Bridged networking I don't believe they do. My reasoning:

If one has two network cards in a host PC one can dedicate one to the guest and one to the host by turning off all non-Virtualbox bindings on the card for the guest, and all Virtualbox bindings on the card for the host. No host network activity would go out on the guest card, and no guest activity on the host card.

From this I surmise that the guest's network activity does not go through the host's stack when bridged. I may be wrong.

Of course the host must process the guest's network activity in some fashion, if only to divert the packets to the guest. Would that interfere or intermesh with file locking? I don't know.

BTW I was not suggesting to not use a virtual machine for the Windows. I was suggesting to figure out if a physical Windows machine would cooperate with the Red Hats' file locking. If so, a Bridged Windows guest would also likely work.
Post Reply