vCloud Director vShield Egde device not listed when using Get-CIVApp PowerCLI cmdlet

[GOsinski]

Hello Folks,

Could you please be so kind and help me in one issue I have with vCloud Director…??

This is related to my recent case with vCloud Director vApp with VCDNI running on HP Blades:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=204099...

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02684783&lang=en&cc=us&taskI...

We will try to mitigate this issue by placing all VMs from the same vApp on the same blade so we don’t have to send VCDNI packages across HP Virtual Connect domains.

Unfortunately, we cannot alter our VC Domain to Mapped Mode.

I have an automated way to create a DRS Affinity Rule for all VMs which are part of the vApp and it works great for all vApp without vShield Edge Device…

Whenever vApp has a vse device I cannot find any way to automatically map vse to its vApp….

Most obvious cmdlet doesn’t work as expected.

Here is an example.

Very simple vApp: 2xVMs, NAT’ed vApp Network.

Once powered on vCD spawns 3 VMs: Attachement no.1

PowerCLI Get-CIVApp shows us: Attachement no.2

Then Get-CIVM lists VMs: Attachement no.3

But it doesn’t show linked vse device no matter how deep it dig into all properties…

The portgroup approach works but we need to scan all PGs and all VMs to get a list so this is really, really slow…

$PGs = Get-VDPortgroup| ? {$_.Name -like "dvs.VCDVS*"}

Foreach ($PG in $PGs) {

      $VMs = Get-VM | where { ($_ | Get-NetworkAdapter | where {$_.networkname -match $PG.Name})}

      $PG.Name

      $VMs.Name

}

On the other hand vApp approach is lighting quick but does not list vse devices for vApps: (Credits: http://vniklas.djungeln.se/2012/05/03/vmware-vcloud-director-vapp-and-drs-cluster-affinity-with-powe...)

And with this method we can also have multiple vApps deployed from Catalog (same Network Name/different PortGroup UUID tho) and we cannot mess UUIDs for same VMs.

      $pod = Get-CIVapp

      $CIVApp

      if ($pod){

            $PodVMs = Get-CIVM -VApp $pod

            $VMs = @()

            $Cluster = Get-Cluster $Cluster

            Foreach ($PodVM in $PodVMs) {

$VMname = $PodVM.Name + "*"

$VM =  Get-VM $VMname | where {$_.ExtensionData.MoRef.Value -eq $PodVM.ExtensionData.VCloudExtension[0].Any[0].VmVimObjectRef.MoRef}

$VMs +=$VM

}

$VMs

As for the Get-CIVM or Get-CIView – for this approach we have to use Get-CIVM as we need to use this later to create DRS affinity rules - please correct me if I am wrong here.

New-DrsRule -Name $pod.Name -Cluster $Cluster -KeepTogether $true -VM $VMs

All hints are more than welcome…:)

Could you please let me know if there is any way to link vse to a vApp with PowerCLI…??

Thanks,

Greg

[IamTHEvilONE]

the vSE gets placed in any available System vDC.  It's also not considered part of the vApp for the purposes of the API (from what I recall) ... more like a feature of a network.  But I don't know if the vApp Network instance even provides you the data.

what you could do.

locate the VMs in question invCenter, then find the isolated port group.

once you have the isolated port group, find the vm with the vse-.... name attached to it (if it exists)

vmotion the vse- to the other System vDC resource pool in the other cluster.

Maybe something like that could work?

[cfor]

Another option would be to use VxLan, if in a single L2 domain multicast can be set to local multicast scope and no major changes are needed.  VxLan is faster than VCNI, and should get rid of some of these issues.

[GOsinski]

Sure, that would work but we are looking for a bit more automated way. Our goal is to create a DRS Affinity rule for all VMs including vse device automatically after new vApp is deployed.

We can script everything except for link vse to vApp with PowerCLI...:(

This should work for hundreds of vApps and a few more deployed/deleted every week for a development and code testing purposes.

~Greg

[GOsinski]

We were thinking to move VCDNI to VXLAN but we get statement from HP that support for VXLAN on HP Blades will be introduced in G9 hardware and currently we have G8.(same as VCDNI on Tunnel Mode so we can try even without HP Support this time)

What is more I was looking for a VCDNI to VXLAN migration guide mentioned here: https://communities.vmware.com/thread/423467 post no. 13 and cannot find any.

If you can post some quick migration guide I would be more than grateful - I can use it to create a quick PoC to check how it works in our situation.

Thanks,

Greg

[cfor]

I am not an expert of the HP blades, however for VXLan you should need nothing special from your hardware.  It should work on any network that can do, IPv4, Multicast, and JumboFrames. 

The migration to VxLan is to install it, and then start using a VxLan network pool for deployments instead of a VCNI.  (You can have both in the same cloud just fine)

Basic Setup:

vCloud Director 5.1 VXLAN Configuration | VMware vCloud Blog - VMware Blogs

A few things I want to point out, when doing the cluster configuration in vCNS, get it right   You have to remove it to change, you can't just change type of MTU size.  (If possible run 9000 MTU, but you need at least 1600) -- Also I would suggest run in "FailOver" mode unless you really want to add the complexity of the other modes (and some hardware will only work in FailOver mode)

---

Changing pace a bit, back to VCNI - I played with using orchestration on vApp instantiate (VCO could be good choice for this) little and making a DRS affinity group; and it does appear to work.  Just seems like a lot of a hack that removes the ablity to use vMotion and limits other HA features.

To get the edge device I had to look at the port groups that each VM where part of, and build a list of all the VMs also in those groups.  Then create a rule containing all these VMs.

(also for a final solution would need to make sure to remove this on vApp delete)

[GOsinski]

Hey,

vCO plan should work. Do you have some exemplary workflow I can use...??

Frankly speaking I am much more familiar with PowerCLI that vCO...:)

Thanks,

Greg