VMware Cloud Community
christianpg
Enthusiast
Enthusiast
Jump to solution

Citrix PVS integration/confusion

Can anyone help me with my XenDesktop/Citrix PVS integration?

...Would like to mention that I'm no Citrix expert...which the rest of my text clearly indicates...

My EPI agent for Citrix PVS integration (CitrixProvisioning) is installed and configured with the powershell mclipssnapin from Citrix.

The snapin communicates just fine with my PVS and the agent seems happy enough.

A blueprint is created:

  Type: virtual/generic

  No reservation policy set (no resources must be defined for external provisioning, right?)

  Workflow: ExternalProvisioningWorkflow

  Custom properties: the relevant custom props for Citrix PVS

When I request a new machine from my blueprint, the VM is created within the only reservation defined for my provisioning group, which is from a vCenter endpoint.

After that, my EPI Agent triggers the PVS to attempt a deployment of it's vDisk to the VMware VM, which of course fails.

PVS is capable of deploying a vDisk to pre-created VMs (which is what I am trying to work with here)

How do I integrate with a Citrix XenDesktop environment when I only communicate with the Citrix PVS?

Isn't this kind of integration supported?

How is this supposed to work? Do I need to manage the XenServers as well?

Do I need to define resources and policies for external provisioning?

1 Solution

Accepted Solutions
admin
Immortal
Immortal
Jump to solution

Your assessment sounds correct to me.

Conceptually this would be more like a discovery/registration rather than the standard provisioning workflows.  I've seen/heard some more elaborate professional services projects where this is done...  Basically the request is for a set of resources and the provision workflow detects they're in a pool and register them in vCAC (i.e. assigns the machine to the users ownership, group, and template, etc.)  This would be a similar type of feature if integrating to VMware view as a provider of desktop as a service. 

The "workaround" sounds right, but it somewhat defeats some of the purpose, correct?? 

If we would design such a feature, I wonder if it would cover your use case by addressing it as some sort of "self service" registration which would simplify what is the "Discovery Wizard" to be front ended by the standard request forms, and resources would come from existing machines as defined in the blueprint.  This would probably require some sort of pooling or revised reservation logic to determine what "pools" of machines would be available for registration.  If this were in place, the PVS registration/unregistration would layer on top of this and most likely require little to no change... 

Not sure if this is the scenario you're attempting to address.

View solution in original post

3 Replies
christianpg
Enthusiast
Enthusiast
Jump to solution

Here's my conclusion (correct me if I'm wrong)

The integration with PVS is just for provisioning and will not do inventory of pre-populated XenServer VMs that it _could_ provision to.

It would break the SW architectures' consistency in resource management and main workflows intended for complete life cycle management.

The main workflows must handle all actions from creation to destroy of the VM...unless I go for the SDK...

The workaround/correct configuration would be to also integrate with the XenServers and create the VM as part of the workflow, and then let the PVS run deployment of it.

0 Kudos
admin
Immortal
Immortal
Jump to solution

Your assessment sounds correct to me.

Conceptually this would be more like a discovery/registration rather than the standard provisioning workflows.  I've seen/heard some more elaborate professional services projects where this is done...  Basically the request is for a set of resources and the provision workflow detects they're in a pool and register them in vCAC (i.e. assigns the machine to the users ownership, group, and template, etc.)  This would be a similar type of feature if integrating to VMware view as a provider of desktop as a service. 

The "workaround" sounds right, but it somewhat defeats some of the purpose, correct?? 

If we would design such a feature, I wonder if it would cover your use case by addressing it as some sort of "self service" registration which would simplify what is the "Discovery Wizard" to be front ended by the standard request forms, and resources would come from existing machines as defined in the blueprint.  This would probably require some sort of pooling or revised reservation logic to determine what "pools" of machines would be available for registration.  If this were in place, the PVS registration/unregistration would layer on top of this and most likely require little to no change... 

Not sure if this is the scenario you're attempting to address.

christianpg
Enthusiast
Enthusiast
Jump to solution

Thanks for your response on this, pfleischer.

I think your suggestion would cover my use case pretty good.

Conceptually, the pre-created XenServer VMs that PVS deploys xendesktops to, is just another pool of resources.

It would simplify the integration if vCAC only talked to the PVS without getting too involved in the underlying Citrix environment.

0 Kudos