avarcher
Commander
Commander

Blue Lane VirtualShield

Jump to solution

Hi

This product seems to be getting a lot of interest and I'm being asked about it. From what I read on the VMware site it says ...

'As traffic flows through VirtualShield inside the hypervisor,' ... http://www.vmware.com/vmtn/appliances/directory/739

Does this mean that this product is a VMkernel component?

Or, is it a VM connected to an internal vSwitch and an external vSwitch and as such will not VMotion, or disallow VMs protected by it to VMotion?

Thanks, Andy.

0 Kudos
1 Solution

Accepted Solutions
Blue_Lane_Team
Contributor
Contributor

When deploying VirtualShield on an ESX server where VMotion is enabled the default configuration will prevent these virtual machines from VMotioning to another ESX server. The reason is that VMotion requires that a physical NIC is attached to the vSwitch where the VM exists, however, VirtualShield requires that the protected virtual machines exist on a vSwitch that has no physical NIC attached to it. VirtualShield then bridges the traffic to the "unprotected" network that is connected to a physical NIC.

To overcome this, VMware has implemented a solution to bypass this check which consists on editing the vpxd.cfg configuration file on the VirtualCenter server. By enabling VMotion and adding a few lines to the vpxd.cfg file, the default prevention is overridden. This enables a VM to be VMotioned and retain the continuous protection from VirtualShield.

Looking at it more closely, by default, VMs being protected by the VirtualShield will raise errors during migration by the operator or VMotion. The error will state that the server is connected to a virtual intranet: the network this server is connected to is on a vSwitch on the “protected” side of the VirtualShield, and which does not home a physical Ethernet interface. In this case, the VirtualShield is bridging traffic to the “unprotected” network that is connected to a physical NIC.

To configure VMotion to disable this virtual intranet check, follow this procedure (as recommended by VMware):

Step 1:Locate the file vpxd.cfg on the machine running the Virtual Center. It is typically installed at "C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter". This location may change based on your preferences during Virtual Center installation.

Step 2: Edit the text file vpxd.cfg. The file layout appears as follows:

Step 3: Save the vpxd.cfg file.

Step 4: Restart the "VMware VirtualCenter Server" service.

This and other technical details can be found in the Blue Lane Technical Network http://bluelane.com/community/ under Technical Forums.

View solution in original post

0 Kudos
17 Replies
VirtualNoitall
Virtuoso
Virtuoso

Hello,

"Or, is it a VM connected to an internal vSwitch and an external vSwitch and as such will not VMotion, or disallow VMs protected by it to VMotion? "

it is a vm that sits between 2 vswitches and then your virutal macines sit behind it. I don't believe it has any impact on Vmotion.

there is a good diagram here: http://www.bluelane.com/products/virtualshield/deployment.php

avarcher
Commander
Commander

From the web page ...

In this example deployment scenario, vSwitch0 and vSwitch1 each have a physical NIC and thus dedicated traffic flows. A third virtual switch (vSwitch2) is placed behind the VirtualShield and connected to all the virtual servers....

Thanks, that confirms it - the VMs will NOT VMotion if this is the way it is set up. If vSwitch2 has no outbound network connection so anything connected to it cannot VMotion.

Cheers, Andy.

0 Kudos
ChadAEG
Contributor
Contributor

Since they talk about putting some kind of shim in the hypervisor, I'm guessing they are modifying it to allow vMotion despite the internal vSwitch as long as certain criteria are met.

Of the few reviews on the product I've seen, I don't remember any mentioning it preventing vMotion from working.

They have a 15 day free trial, should be pretty easy to find out exactly what it does/doesn't do.

0 Kudos
avarcher
Commander
Commander

Thanks

I took your advice, the VMs to be protected are connected to a virtual switch with no outbound connection, this means that they will not vmotion. marketing materials tend to avoid mentioning limitations.

When you read the high level documents they sort-of suggest that this runs directly on the vmkernel but in fact it's a virtual appliance.

Can I add that I have no axe to grind here, I was simply asked by a student on a course for an appraisal of the product, I think that what it does is excellent and there are lots of good uses for it. I did say immediately that to protect VMs they would have to be behind an internal only switch and this would mean that vmotion would not be possible. I was not suggesting that this is a show stopper, I just wanted my student to be in the position of making an informed decision.

0 Kudos
VirtualNoitall
Virtuoso
Virtuoso

Hello,

Based on your description I am not able to figure out why Vmotion is an issue. Vmotion, from a network perspective, just cares about the port group label. Can't this simply be the same across servers?

Thanks!

0 Kudos
ChadAEG
Contributor
Contributor

I had this on my list of things to look into as soon as our migration to VI3 was complete. Thanks for testing it out. That would be a huge deal breaker for us. No way a 2nd level of patch vulnerability protection would be worth the loss of VMotion and DRS.

0 Kudos
v_dave
Contributor
Contributor

It works seamlessly with vmotion:

http://www.bluelane.com/products/virtualshield/features.php

Or just google: "blue lane" vmotion

You'll see plenty of references.

0 Kudos
SecurityJunkie
Contributor
Contributor

The Virtual Shield won Best of Interop a few weeks ago and was a feature cover story review in May 28 Network Computing.

Review: http://www.networkcomputing.com/showArticle.jhtml?articleID=199700939

You might be able to email the author of the review to find out if he used any VMotion during the tests.

0 Kudos
avarcher
Commander
Commander

If, and I repeat if, a virtual machine is connected to a virtual switch that has no physical network cards connected to it then it will not[/b] , that is not[/b], vmotion. Nothing to do with labels.

The download from Blue Lane instructs you to connect your vms to be protected to a virtual switch, that the blue lane server is connected to, that has no physical network cards connected.

0 Kudos
avarcher
Commander
Commander

I'm sorry but, while there is a reference in the doc to VMotion, it is in relation to dicovery and at no point says it works seamlessly with VMotion.

You're right about Google, none of the results had Blue lane and VMotion in the same paragraph.

0 Kudos
avarcher
Commander
Commander

Thanks, thats what I will do, I'm getting no response from Blue Lane support.

It may seem like I am going on about something unimportant, but if this is NOT an appliance then it is a component of the VMkernel, and as far as I know there are no 3rd party VMkernel components, if there were then this would be a very interesting development.

0 Kudos
Michelle_Laveri
Virtuoso
Virtuoso

Andy,

I did a web-ex session with the guys from Blue Lane yesterday... I have the contact details of the chaps there - I've emailed them to clarify this situation regarding VMotion...

Apparently, they have worked quite closely with VMware on this - in fact they claimed their move to create virtual shield was actually prompted by VMware which I think is interesting...

I didn't speak to anyone especially technical yesterday - so they weren't able to answer some of my questions - but hopeful I will get a response back...

Regards

Mike

Regards Michelle Laverick @m_laverick http://www.michellelaverick.com
Blue_Lane_Team
Contributor
Contributor

When deploying VirtualShield on an ESX server where VMotion is enabled the default configuration will prevent these virtual machines from VMotioning to another ESX server. The reason is that VMotion requires that a physical NIC is attached to the vSwitch where the VM exists, however, VirtualShield requires that the protected virtual machines exist on a vSwitch that has no physical NIC attached to it. VirtualShield then bridges the traffic to the "unprotected" network that is connected to a physical NIC.

To overcome this, VMware has implemented a solution to bypass this check which consists on editing the vpxd.cfg configuration file on the VirtualCenter server. By enabling VMotion and adding a few lines to the vpxd.cfg file, the default prevention is overridden. This enables a VM to be VMotioned and retain the continuous protection from VirtualShield.

Looking at it more closely, by default, VMs being protected by the VirtualShield will raise errors during migration by the operator or VMotion. The error will state that the server is connected to a virtual intranet: the network this server is connected to is on a vSwitch on the “protected” side of the VirtualShield, and which does not home a physical Ethernet interface. In this case, the VirtualShield is bridging traffic to the “unprotected” network that is connected to a physical NIC.

To configure VMotion to disable this virtual intranet check, follow this procedure (as recommended by VMware):

Step 1:Locate the file vpxd.cfg on the machine running the Virtual Center. It is typically installed at "C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter". This location may change based on your preferences during Virtual Center installation.

Step 2: Edit the text file vpxd.cfg. The file layout appears as follows:

Step 3: Save the vpxd.cfg file.

Step 4: Restart the "VMware VirtualCenter Server" service.

This and other technical details can be found in the Blue Lane Technical Network http://bluelane.com/community/ under Technical Forums.

View solution in original post

0 Kudos
avarcher
Commander
Commander

Thank you, this is a perfect answer to my question and I'm sure this will be enough for my student.

A couple of further questions from me, will VMware support customers who make this modification? Also, this is a VirtualCenter wide setting so is it possible to be selective about which virtual machines lose the protection that the intranet switch check provides?

Thanks, Andy.

0 Kudos
avarcher
Commander
Commander

I've dug further into this. So in the interest of clarity ...

The 'VMware recommended' needs to be treated carefully. If[/b] you want to stop the VMotion check then this is how it is done. BUT[/b] - if you make the modification you are out side of VMware support (at your own peril is a phrase that was used). And it is VC wide so applies to all VMs.

0 Kudos
dphowes
Enthusiast
Enthusiast

So essentially, if something goes awry, on your head be it ?

0 Kudos
CaryBarker
Contributor
Contributor

The change is a couple of lines on the VI server. If you have problems take the lines back out, restart the service and do your testing to eliminate that as a possibility.

Also realize - whenever you do an upgrade this file will likely get replaced - like when you go from 2.01 to 2.02. In that case you'll have to put the lines back in again.

This solution is working well enough for me.

-Cary

0 Kudos