-
Understanding the Citrix Virtual Apps and Desktops Administration Model
-
-
-
-
-
-
-
-
-
-
-
about_Prov_MachineProfile
-
-
-
-
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
about_Prov_MachineProfile
Topic
Citrix Machine Creation Service SDK - Machine Profile
Short Description
Overview of Machine Profile and how to use it to provision machines across different hypervisors
Long Description
Machine Profile provides a way to specify a template that will be used for provisioning machines in a provisioning scheme. Depending on the hypervisor, the template can provide hardware details (CPU/memory, disk tier), networking settings (subnets, security groups) and hypervisor-specific features (disk encryption, accelerated networking, availability zones) that will be carried through to created machines.
Machine Profile allows for having one place to specify all virtual machine settings, instead of having to pass the settings individually when creating or updating a catalog. For instance, the ServiceOffering for a catalog will be automatically set to whatever Machine Profile is using if it’s not provided explicitly via the -ServiceOffering PowerShell parameter. There’s also the added benefit of knowing all settings will be compatible with each other if the hypervisor supports using an already created virtual machine as Machine Profile.
Another key benefit is when new features are implemented by the hypervisor, they have the potential to be supported on day zero. A recent example was Azure adding in support for placing created machines in a proximity group. Right after the feature was released by Azure, if a Machine Profile was configured to use a proximity group, machines provisioned based on that Machine Profile would use the same proximity group.
Property Processing Order
Some properties present in Machine Profile were given explicitly prior to Machine Profile being supported, either via hypervisor specific CustomProperties or through other more general parameters shared across hypervisors like ServiceOffering, NetworkMapping.
Methods of giving parameters explicitly will override any values given in Machine Profile. For instance, if ServiceOffering is given to be Standard_D2s_v3 and Machine Profile specifies a machine size of Standard_D4s_v5, machines will be provisioned with Standard_D2s_v3.
Additionally, some properties will be inferred from the chosen master image if not defined explicitly or via Machine Profile.
To summarize the order in which properties are taken for New-ProvScheme follows:
- PowerShell parameters (CustomProperties, ServiceOffering, etc) > MachineProfile values > Master image values > Default values
Consider the below example that illustrates the order in which properties are used:
- PowerShell parameters provided: ServiceOffering, CustomProperties (containing one property: CustomA)
- MachineProfile defines: ServiceOffering, NetworkMapping, CustomProperties (containing two properties: CustomA, CustomB)
- Master image defines: CustomProperties (containing two properties: CustomB, CustomC)
- The end result is that the catalog will use ServiceOffering and custom property CustomA from the provided PowerShell parameters, NetworkMapping and custom property CustomB from MachineProfile, custom property CustomC from the master image.
It’s also important to note the behavior of commands that update existing provisioning schemes/virtual machines: Set-ProvScheme and Set-ProvVM. If a property was set explicitly previously, it will be overridden when the property can be read from a provided Machine Profile and the property is not separately provided. Take the following example:
- Catalog is created using a MachineProfile and a ServiceOffering provided explicitly of Standard_D2s_v3 and CustomProperties providing a StorageType of Premium_LRS
- Catalog is updated providing only a MachineProfile that has a ServiceOffering defined as Standard_D4s_v5
- The end result is that the catalog’s MachineProfile is updated to the new value, the ServiceOffering is updated to Standard_D4s_v5, and StorageType remains as Premium_LRS
In short, for Set-ProvScheme / Set-ProvVM, the order in which properties are used is the following:
- PowerShell parameters (CustomProperties, ServiceOffering, etc) > MachineProfile values > Previously configured values
Azure Specific Information
When using Azure, there are two types of resources that can be used as a Machine Profile:
- Virtual Machine: An ARM template will be generated from the virtual machine selected and related resources that are attached (NICs, OS disk, virtual machine extensions, Azure Monitor data collection rules and diagnostic settings) which will be used to create machines in a provisioning scheme.
- Template Spec Version: An ARM template given explicitly which will be used to create machines in a provisioning scheme. It must contain a definition for a virtual machine resource and at least one network interface. And may include one definition for a disk and any number of virtual machine extensions, Azure Monitor data collection rules and diagnostic settings. A template spec version can be checked for any validation errors prior to use with the cmdlet Test-ProvInventoryItem. A good starting point when building an ARM template to use as Machine Profile is to export the ARM templates for an existing virtual machine and its NIC and make changes from there.
Both types of Machine Profile fully support the same features so whichever is more convenient can be used.
The following are example properties that can be captured from the resource provided as Machine Profile input:
- Trusted launch (vTPM)
- Disk Encryption Set
- Disk storage type
- Machine size
- Tags
- NIC accelerated networking
When the Machine Profile provides virtual machine extensions, only extension types on the allowed list of extensions are carried through, the rest are stripped out. The following extension types are allowed by default:
- AADLoginForWindows
- AzureMonitorWindowsAgent
- AzureMonitorLinuxAgent
Other extension types can be added to the allowed list of extension types with Add-ProvMetadataConfiguration.
Azure has the following properties that can be provided explicitly or through Machine Profile:
- ServiceOffering (via properties/hardwareProfile/vmSize from the VM resource)
- NetworkMapping (via properties/ipConfigurations/subnet/id from the NIC resources)
- SecurityGroups (via properties/ipConfigurations/networkSecurityGroup/id from the NIC resources)
-
CustomProperties
- DiskEncryptionSetId (via properties/storageProfile/osDisk/managedDisk/diskEncryptionSet/id from the VM resource or properties/encryption/diskEncryptionSetId from the disk resource)
- StorageType (via properties/storageProfile/osDisk/managedDisk/storageAccountType from the VM resource or sku/name from the disk resource)
- OsType (via properties/storageProfile/osDisk/osType from the VM resource or properties/osType from the disk resource)
- Zones (via zones on either the VM or disk resource. Note: This property sets the availability zones)
- LicenseType (via properties/licenseType from the VM resource)
- DedicatedHostGroupId (via host/id or hostgroup/id from the VM resource)
Additionally, the following CustomProperties will be read from the master image if not provided explicitly or through Machine Profile:
- OsType
- DiskEncryptionSetId
Aws Specific Information
When using AWS, there are two types of resources that can be used as a Machine Profile:
- EC2 instance: An AWS VM and resources attached to it (e.g., ENIs, root volume, EBS volume properties) will be used to create machines in a provisioning scheme.
- Launch Template Version: An AWS Launch Template Version given explicitly which will be used to create machines in a provisioning scheme.
The following are example properties that can be captured from the resource provided as Machine Profile input:
- Instance type
- EBS optimization
- Hibernation
- Elastic Graphics
- Tags
- Security Groups
- IAM profile
AWS also has the following properties that can be provided explicitly or through Machine Profile:
- ServiceOffering
- NetworkMapping
- TenancyType
- SecurityGroups
Gcp Specific Information
When using Google Cloud Platform, there are two types of resources that can be used as a Machine Profile:
- VM Instance: Virtual Machines within GCP
- Instance Template: Serialized Hardware Properties of a GCP Instance
Both types of Machine Profile fully support the same features so whichever is more convenient can be used.
The following are example properties that can be captured from the resource provided as Machine Profile input:
- Service accounts (via properties/serviceAccounts from the resource)
- Accelerators (via properties/GuestAccelerators from the resource)
- Availability policies (via Properties/AvailabilityPolicies from the resource)
- Shielded VM policies (via Properties/AvailabilityPolicies from the resource)
- Tags (coming soon)
GCP has the following properties that can be provided explicitly or through Machine Profile:
- ServiceOffering (via properties/MachineType from the machine profile resource)
-
CustomProperties
- CatalogZones (via properties/zone. Not applicable if Machine profile is an instance template since instance templates are global resources. All zones in the region will be used in this case.)
- StorageType (via properties/type from OS disk attached to resource)
- CryptoKeyId (via properties/Encryption/KeyId from OS disk attached to resource)
Scvmm Specific Information
When using SCVMM, the following resource can be used as a Machine Profile input:
- Virtual Machine: The properties of the Virtual Machine will be used to create machines in a provisioning scheme.
Note: In SCVMM, we do not support template for Machine Profile.
The following are all the properties that can be captured from the resource provided as Machine Profile input:
- CPU count
- CPU Type
- LimitCPUForMigration
- TPM (Trusted Platform Module)
- NetworkInterfaceDetails (through network adapters)
- Memory
- Nested Virtualization
- Secure Boot
- Operating System
- VM Generation
Note: Tags are not captured from the virtual machine as machine profile input in SCVMM
SCVMM has the following properties that can be provided explicitly or through Machine Profile:
- VMCpuCount
- VMMemoryMB
- NetworkMapping
Note: Machine Profile cannot be added/updated on existing machines as SCVMM does not currently support either Set-ProvVMUpdateTimeWindow or Set-ProvVM
Xenserver Specific Information
When using XenServer, the following resource can be used as a Machine Profile input:
- Virtual Machine: Snapshot of a Virtual Machine
The following are example properties that can be captured from the resource provided as Machine Profile input:
- CPU count
- Memory
- Network Mapping
- Tags
- Generation
- VGPU
XenServer has the following properties that can be provided explicitly or through Machine Profile:
- VMCpuCount
- VMMemoryMB
- NetworkMapping
Note: Machine Profile cannot be added/updated on existing machines as SCVMM does not currently support either Set-ProvVMUpdateTimeWindow or Set-ProvVM
Vmware Specific Information
When using VMware, the following resource can be used as machine profile input:
- VM Template: Can be created in two ways - Converting an existing VM into a VM Template, or cloning an existing VM to a VM Template.
All hardware properties are captured from the machine profile template. Here are some relevant examples:
- Folder ID
- vTPM Data
- Memory
- CPU Count
- Storage Policy
- Guest OS
- NIC Count
- VM Tags
VMWare has the following properties that can be provided explicitly or through Machine Profile:
- VMCpuCount
- VMMemoryMB
- NetworkMapping
-
CustomProperties
Note the following information around specific properties:
- vTPM: If the master image VM is vTPM enabled, the VM template must come from the same master image VM.
-
CPU and Cores per Socket: For VMware, CPU Count must be an integral multiple of Cores per Socket. For example, 6 CPU count can have 1,2,3, or 6 Cores per Socket. 4 CPU count can have 1,2, or 4 Cores per Socket.
- For a new Catalog, both CPU Count and Cores per Socket value are picked up from the machine profile. Unless CPU count is also provided as a parameter, in which case that value is used.
- For an existing catalog, CPU Count by itself can be updated using the “VmCpuCount” parameter of Set-ProvScheme, but this does not change the value of Cores per Socket. To update both values, provide a new VM Template with the required changes as the Machine Profile parameter in Set-ProvScheme.
- Storage Policy: Only captured in a vSAN Datastore.
-
NICs: Only the NIC count from the Machine Profile is used. Network mappings from the Machine Profile are not used.
- NIC count cannot be 0 or higher than what the hosting unit can support.
- If NIC count is 1, and no mapping is provided, default network/subnet from the Hosting Unit is used.
- If NIC count is greater than 1, network mapping needs to be provided for each NIC.
- Mapping has to be 1:1, that is, only one NIC can be mapped to one subnet on the Hosting Unit.
See Also
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.