Quantcast
Channel: Tomas Fojta – Tom Fojta's Blog
Viewing all 242 articles
Browse latest View live

vCloud Availability: Replication of Powered-off VM

$
0
0

Just a short post about a feature I recently learned.

In vSphere Replication when you are configuring replication of powered-off VM you will get the following message:

The virtual machine is not powered on. Replication will start when the virtual machine is powered on.

The replication is actually configured and its placeholder VM is created in the recovery location (cloud) but the VM will stay in Not Active state.

Why is this? Immediate start of replication locks VM disks which means such VM would not be able to power-on until the initial sync is finished. But what if you want to replicate powered-off VMs for example templates that are never meant to run?

You can in fact force start the replication by right clicking the VM and selecting Sync Now, which asks confirmation question if we really want to do so as the VM will not be able the be powered on until the operation completes.

Is there a use case for this? As I mentioned this could be used for catalog sync as replication is much faster and efficient that OVF export / import.


How to Configure Additional VM Metrics in vCloud Director

$
0
0

vCloud Director already for some time (since version 5.6) provides to tenants basic set of VM metrics. Until vCloud Director 9.0 they had to be retrieved with vCloud API, however now the users can easily access the metrics from the new HTML5 UI.

vCloud Director 9.0 besides adding the metric UI also simplifies the metric database backend configuration (no KairosDB needed anymore) and also provides the option to service provider to configure additional VM metrics.

Here follows the step by step description of the last point. I assume that Cassandra cluster – the VM metric database is already set up.

  • First you need to find the metric names VC Performance Manager uses. This PowerCLI script exports all VM metric names.
  • Now we will create text file (e.g. metrics.groovy) with the new metrics.

configuration {
metric("mem.granted.average")
metric("mem.granted.maximum")
}

The metrics in the file must not overlap with the already existing default metrics. Additional options about frequency, interval averages, etc. can be provided as well. See docs for the details.

  • On a vCloud Director cell with the cell-management-tool we will import the new metrics:
    $VCLOUD_HOME/bin/cell-management-tool configure-metrics –metrics-config /tmp/metrics.groovy 
  • Still on the cell we need to update Cassandra schema, again with the cell-management-tool (provide the correct nodes addresses, DB authentication details, port and metrics time to live in days):
    $VCLOUD_HOME/bin/cell-management-tool cassandra –configure –cluster-nodes 172.16.0.41 –username cassandra –password cassandra –port 9042 –ttl 31 –update-schema
  • Restart all cells

That is all. After while we can monitor the new metrics with the UI or API.

The metric definition is stored in vCloud Director table metric_configuration.

Missing Licensing Metrics in vCloud Director 9.0

$
0
0

You might have noticed that vCloud Director 9.0 no longer displays licensing metrics.

This was a conscious decision as already for some time the licensing is handled externally by vCloud Usage Meter and the metering in vCloud Director caused vCloud database bloat.

If for some reason you still need to have these metrics available in UI, vCloud API or vROps Management Pack you can enable license metering with this command on a cell. No need for reboot, just wait few minutes for the next data collection.

$VCLOUD_HOME/bin/cell-management-tool manage-config -n licensing.metrics.vm.enabled -v true

vSphere Replication Issue with ESXi 6.5U1

$
0
0

This is a quick post to highlight an issue vSphere Replication has with ESXi 6.5U1 for To-the-cloud replication.

Only customers that use vSphere Replication for DR or migrations to the cloud endpoints (e.g. vCloud Availability for vCloud Director) with ESXi 6.5U1 hosts are affected (ESXi 6.5 and older works fine). Also host-to-host replication is not affected.

The root cause is that ESXi 6.5U1 hosts are unable to retrieve from vSphere Replication Appliance vr2c-firewall.vib that is responsible for opening outgoing communication ports for replication traffic on the ESXi host firewall.

This results in inability to perform any to-the-cloud replications. To see the issue look into the host Firewall configuration in the Security Profile section. If you do not see Replication-to-Cloud Traffic section you are affected.

The picture below which traffic it is related to (red rectangle on the left):

If you would look into esxupdate.log on the host you will see error: [Errno 14] curl#56 – “Content-Length: in 200 response”.

Until a fix is going to be released here is a workaround:

  1. Download the vr2c-firewall.vib from the vSphere Replication Appliance: https://vSphere-Replication-Appliance-ip-or-fqdn:8043/vib/vr2c-firewall.vib.
  2. Upload the vib to a shared location (datastore)
  3. Install the vib to every host with the following command: esxcli software vib install -v /vmfs/volumes/<datastore>/vr2c-firewall.vib
  4. Verify the fix was installed properly with: esxcli software vib list | grep vr2c

vCloud Director vApp Runtime Lease Expiration Action

$
0
0

In vCloud Director it is possible to configure vApp leases. The maximums are set by system admin at Organization level (in Policies), which can be lowered by Org Admin (at org level) and set by vApp owner at the vApp level. A vApp has runtime lease (for how long it will be in running state) and storage lease (for how long it will consume storage once it is not running).

vApp leases are very useful in test & dev or lab environments to make sure abandoned, unused VMs are not running and taking resources.

When vApp lease is coming to an end, its owner gets a reminder via email (how many days before expiration can be configured in User Preferences) and can optionally reset vApp lease to avoid its stopping or deletion.

By default expired running vApp is put into suspended state which means its memory content is saved to datastores. This ensures fully consistent state upon consequent power on of the vApp. This however make not be always needed especially in dev/lab situations – the memory content could take lots of storage space and for example saving 16 GB RAM VM to datastore could also create IO performance impact. As of vCloud Director 8.20 the Organization Administrator can instead change the default runtime expiry action to power off. The setting is done at Org level and must be done via API by setting the element <PowerOffOnRuntimeLeaseExpiration> of OrgLeaseSettingsType to true. The API version must be at least 25.0.

PUT /api/admin/org/eea1f10c-3fee-43d7-bd8e-be63453d6e34/settings/vAppLeaseSettings

Accept:application/*+xml;version=29.0
x-vcloud-authorization:{{x-vcloud-authorization}}
Content-Type:application/vnd.vmware.admin.vAppLeaseSettings+xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VAppLeaseSettings xmlns="http://www.vmware.com/vcloud/v1.5">
    <DeleteOnStorageLeaseExpiration>true</DeleteOnStorageLeaseExpiration>
    <DeploymentLeaseSeconds>1209600</DeploymentLeaseSeconds>
    <StorageLeaseSeconds>15552000</StorageLeaseSeconds>
    <PowerOffOnRuntimeLeaseExpiration>true</PowerOffOnRuntimeLeaseExpiration>
</VAppLeaseSettings>

Note:

When the vApp expiry action is set to power off, the actual VM stop action power off (hard) vs shutdown (gracefull) procedure depends on the vApp’s config for each VM (tab Starting and Stopping VMs).

Also note that subsequent edit of Org policies in UI will reset the Org PowerOffOnRuntimeLeaseExpiration setting back to default (false).

Layer 2 VPN to the Cloud – Part II

$
0
0

Almost 3 years ago I have published an article how to set up layer 2 VPN between on-prem vSphere environment and vCloud Director Org VDC.

As both vCloud Director and NSX evolved quite a bit since to simplify the whole set up, here comes the part II.

Let me first summarize the use case:

The tenant has an application that resides on 3 different VLAN based networks running in its own (vSphere) datacenter. The networks are routed with existing physical router. The tenant wants to extend 2 of these networks to cloud for cloud bursting or DR purposes, but not the 3rd one (for example because there runs a physical database server).

The following diagram shows the setup.

The main advancements are:

  • vCloud Director natively supports NSX L2 VPN (VCD 8.20 or newer needed).
  • NSX now (since 6.2) supports configuration of unstretched networks directly (no static routes are necessary anymore)
  • This means the full setup can be done by the tenant in self-service fashion

Here are the steps:

  • The tenant will deploy freely available NSX Standalone Edge in its datacenter connected to trunk port with 2 VLANs mapped (10 and 11). Additional network configuration is necessary (forged transmits and promiscuous mode or sink port creation – see the link)
  • In the cloud Org VDC tenant deploys two routed Org VDC networks with identical subnets and gateways as networks A and B. These networks must be connected to the Org VDC Edge GW via subinterface (there can be up to 200 such networks on single Edge). The Org VDC Edge must have advanced networking enabled.
  • Tenant enables and configures L2VPN server on its Org VDC Edge GW. Note that this is a premium feature that the service provider must enable in Organization first (see this blog post).
  • Before the L2VPN tunnel is established the following must be taken into account:
    • The Org VDC Edge GW IP addresses are identical with the on-prem existing physical router. Therefore Egress Optimization Gateway addresses must be entered in the Peer Site configuration. That will prevent the Org VDC Edge GW from sending ARP replies over the tunnel.
    • The same must be performed on the Standalone NSX Edge via CLI (see egress-optimize command here).
    • The non-stretched network (subnet C) must be configured on the Org VDC Edge GW so it knows that the subnet is reachable through the tunnel and not via its upstream interface(s). This option however is not in vCloud UI, instead vCloud networking API must be used.
      Alternatively the provider could configure non-stretched network directly in the NSX UI:
    • Finally, the tunnel can be established by configuring L2VPN server details on the on-prem Standalone NSX Edge L2VPN client (endpoint IP, port, credentials, encryption) and providing VLAN to tunnel mappings.
    • Note to find the Org VDC network subinterface tunnel mapping vCloud API must be used again:

vRealize Orchestrator Client with 4K Screen

$
0
0

This is a quick tip for those that want to run vRealize Orchestrator client on 4K screen in Windows 10 and cannot see anything because the font is so tiny and does not scale. The full credit goes to @joerglew who published in on our internal Socialcast but I have not seen it on public internet.

Download the client.jnlp file from the https://vro-address:8281/vco/client/client.jnlp (the Start Orchestrator Client link).

Edit the file in notepad and add line <property name=”sun.java2d.dpiaware” value=”false”/> into the resources section of the xml.

That’s it. Enjoy nice large font on your 4K screen.

What’s New in vCloud Availability 2.0.1

$
0
0

Minor patch of vCloud Availability 2.0.1 was released last week. Besides many bug fixes, improved documentation and support for Cassandra version 3.x I want to highlight two undocumented features and add upgrade comment.

Provider vSphere Web Client Plugin

This is a return from 1.0 version of an  experimental feature, where the provider can monitor state of vSphere Replication Manager Server, vSphere Replication Servers and all incoming and outgoing replications from inside the vSphere Web Client plugin in the particular (provider side) vCenter Server. This is especially useful for quick troubleshooting.

vRMS Status
vRS Status
Replication Status

Complex vSphere SSO Domain Support

Although it is not recommended to have multiple vCloud Director / vCloud Availability instances sharing the same vSphere SSO domain, it is now possible to accommodate such scenario. The reason why it is not recommended is, that it creates unnecessary dependency between the instances, limits upgradability and scale of each instance.

Upon startup vSphere Replication Cloud Service (vRCS) is querying SSO Lookup Service for Cassandra nodes and resource vCenter Servers. In order to limit the scope of such query to only those that belong to the particular vCloud Availability instance, create text file /opt/vmware/hms/conf/sites on all vRCS nodes with SSO site names that should be queried (one line per site).

Upgrade Options

You can upgrade to vCloud Availability 2.0.1 both from version 1.0.x and 2.0, however you need to use different upgrade ISO images for upgrading of the replication components (vRMS, vRCS and vRS). The installer and UI appliances are redeployed fresh as they are all stateless.

 


What’s New in vCloud Director 9.1

$
0
0

vCloud Director version 9.1 has been released. It has been just 6 months since the previous release (9.0) so VMware is delivering on its promise of multiple yearly releases in 6 months cadence.

In this whitepaper you can find  high level overview of some of the new features. Let me summarize them and also provide additional ones here below.

H5 UI Enhancements

In iterative process the HTML 5 UI is slowly replacing legacy Flex UI. The tenant portion now includes vApp, Catalog and Networking management functionality, OVF/ISO download/uploads without the need for Client Integration Plugin (hooray!) and support for standalone VMware Remote Console.

Associated organizations from multiple or single (new in 9.1) vCloud Director instances now have aggregated view of all Org VDCs with seamless UI redirections between instances.

SDK for UI Extensibility has been released which means the service provider can extend the UI with additional sections to provide access to new services. The SDK includes very simple example of a static page extension (e.g. terms of service, links to other services or price lists) and upcoming vCAT-SP whitepaper will show how to do more complex ones.

The H5 UI is now also used in provider context but only for new features related to vRealize Orchestrator extensibility configuration.

Both legacy UIs (provider and tenants) are still available until the full feature parity is achieved.

vRealize Orchestrator Integration

Updated vRealize Orchestrator plugin has been released. This means both providers and tenants can automate and orchestrate repeating tasks in vCloud Director.

What is completely new is the ability to integrate any vRealize Orchestrator workflows into vCloud Director UI and essential provide XaaS (anything as a service). Similar to vRealize Automation XaaS.

External Tools

Not specifically tied with vCloud Director 9.1 but fully supported now are:

  • vcd-cli Linux command line tool to easily trigger or script common vCloud Director tasks (both for provider and tenant).
  • Container Service Extension Ability to extend vCloud Director to be target for deployment of Kubernetes clusters for tenants and simple management through CLI.
  • Object Extensibility SDK
  • Security Hardening Guide (long overdue update): PDF HTML

Other Features and Changes

  • Org VDC network disconnection and connection from Org VDC Edge Gateway. This allows movements of network between Edges without impact on the connected VMs.
  • NFV features (SR-IOV, Large Page VMs, and guaranteed sensitivity support).
  • FIPS mode can be enabled on Org VDC Edge Gateways
  • vCloud Director 9.1 maximums now include support for 150 ms RTT latency between management components (vCloud cells, vSphere, NSX) and 2000 Edges in single vCloud Director instance
  • VM monitoring metrics now via API provide also roll up metrics for vApp, Org VDC and Org objects.
  • Multisite enhancements: associations of orgs within the same vCloud Director instance, multisited API queries and rollup calls
  • Removed support for old vCloud API versions (1.5, 5.1): make sure you update your scripts or applications to use at least version 5.5 APIs (e.g. Usage Meter).
  • vCloud Director no longer registers itself as an extension to resource vCenter Servers (upgraded instances will not delete the extension registration).

Limit Maximum vCPU/RAM Configuration of vCloud Director VM

$
0
0

Some times ago I wrote about an undocumented feature that allows to limit maximum disk size for VM in vCloud Director. I was asked numerous times if there is similar setting for vCPU and RAM maximums. Today I discovered there is, however it should be considered an experimental feature. I still find it useful as misconfigured VM with extremely large number of vCPUs or huge RAM will impact the host it is running on and cause excessive swapping or high CPU ready times so it is in best interest of the vCloud Director system administrator to prevent it. The other option is to use blocking tasks as described here: CPU and Memory Limit enforcement for vCloud Director and in a blog here.

The limit is set with cell-management-tool command on any cell. Restart of the cell is not necessary.

$VCLOUD_HOME/bin/cell-management-tool manage-config -n vmlimits.memory.limit -v 65536
$VCLOUD_HOME/bin/cell-management-tool manage-config -n vmlimits.cpu.numcpus -v 16

The settings in the example above will limit maximum size of a VM to 16 vCPUs and 64 GB RAM.

Some observations:

  • The limit is vCloud Director instance wide and also applies to system administrators
  • VM with resources set above the limit will fail to be powered on with an error:
    The operation could not be performed, because there are no more CPU resources
    or
    The operation could not be performed, because there are no more Memory resources
  • It can be cheated by using CPU or memory hot add and adding resource beyond the limits to an already powered on VM

Again, consider it an experimental feature and use at your own risk.

vCloud Director on AWS

$
0
0

My colleague Lyubomir Lyubenov from VMware OneCloud team (OneCloud is internal huge vCloud Director based cloud for field enablement) recently published VCDonAWS CloudFormation templates with which you can deploy vCloud Director management components under 30 minutes on AWS.

I have seen customer (Service Providers) asking what is it for and what it means for the vCloud Director future. Let me give you my own view.

What is it?

vCloud Director is one of a few VMware products that is not provided in form of virtual appliances. The vCloud Director binaries can be installed on any compatible Linux virtual or physical machine and that means it can be installed anywhere – even on EC2 instances running on AWS. The VCDonAWS project in a clever way uses AWS resources (not VMC on AWS!) to deploy vCloud Director management stack from a single CloudFormation template. It leverages VPC (optionally stretched across 2 availability zones) for the networking, EC2 instances for jumphosts and vCloud Director cells, PostgreSQL RDS for vCloud Director database, S3 (S3FS) for vCloud Director transfer share (although this will be in the future replaced with Elastic File System for better performance), Elastic Load Balancers (for UI/API and ConsoleProxy cells) and even Auto Scaling Groups to automatically deploy additional VCD cells. The certificates are provided with AWS Certificate Manager.

The following picture taken from the VCDonAWS website shows the overall architecture.

What is it not?

As you can see above it only deploys the vCloud Director management components. You will still need to attach resource vCenter Servers/NSX Manager pairs and these obviously cannot be running on (native) AWS. You cannot even use VMC on AWS instances (at least not yet) as they have RBAC and VC/NSX inventory access limitations which prevent vCloud Director from working properly.

Cassandra VM metric datastore and RabbitMQ messaging bus optional components are not deployed either although I see no reason why they should not run on AWS.

Is it supported?

No. The deployment uses unsupported OS – Amazon Linux (the CentOS deployment option is not working at the time of writing).

Why?

Beside the OneCloud team use case which I cannot speak here about I see it as a very nice proof of concept of how VCD deployment can be automated. How simply it can be done with infrastructure as code approach. And obviously once VMC on AWS restrictions will be resolved these two can be used together to provide multitenant VMware platform IaaS.

Try it yourself!

If you have AWS account try it yourself and really in about an hour you can have a deployed vCloud Director instance.

Here are some tips:

  • Use only US regions as the provided templates do not have AMI mappings for other regions
  • Use Amazon Linux HVM as base operating system for Bastion and cell hosts (CentOS option is not working)
  • For VCD installation ID do not use 7-9 due to bug in verification regex.
  • You will need VCD binary uploaded in an S3 bucket. I used VCD 9.1 GA bits. You will also need working license key.
  • You will need certificate (even self signed) uploaded to Certification Manager.
  • And lastly generate key pair  for accessing bastion hosts and cells.
Cloud Formation Input Dialog

 

 

Stack Deployment

 

vCloud Director Cells

vCloud Director Federation with VMware Identity Manager

$
0
0

Although in the past I have already blogged about vCloud Director federation with VMware Workspace and Microsoft AD FS I still have not wrote a guide how to achieve organization federation with VMware Identity Manager.

VMware Identity Manager (VIDM) is Single Sign-On solution that integrates with multiple identity providers (such as Active Directory) and offers App Store like access to multiple subscribed services with adaptive access (including multi factor authentication such as VMware Verify, DUO or RSA SecurID).

Users can easily log in into multiple different cloud services from a single page thanks to SSO. One such service can be vCloud Director and this article describes how to achieve this.

VIDM is provided as virtual appliance that can be deployed in  a load balanced distributed or simple configuration with external Microsoft SQL database or for evaluation purposes with embedded PostgreSQL. It is also provided as a cloud service.

I have deployed in my lab VIDM 3.2 in a single embedded database configuration and connected it to my lab Active Directory. VIDM also provides its own internal IdP (System Domain) so can be used also without an external AD/LDAP.

  1. In vCloud Director Organization enable Federation by setting Entity ID to Org Name (or any other unique string), generate fresh certificate and download Metadata from the link provided (file spring_saml_metadata.xml). This can be done as system or Organization Administrator.
  2. In VIDM go to Catalog and create new web application. You have to be logged in as VIDM Administrator. Write application name, description and upload nice icon and choose category. 
  3. In the next screen keep Authentication Type SAML 2.0 and paste the xml metadata from step #1 into the URL/XML window. Scroll down to Advanced Properties. 
  4. In Advanced Properties we will keep the defaults but add Custom Attribute Mappings which describe how VIDM user attributes will translate to VCD user attributes. Here is the list:
Name                                                               Value
-------------------------------------------------------------------------------------
UserName                                                           ${user.userName}
EmailAddress                                                       ${user.email}
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname      ${user.lastName}
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname    ${user.firstName}
Groups                                                             CokeAdmins
Roles                                                              ${user.employeeID}

Format is always basic and namespace is blank. Let me explain what is going on here. The first two mappings should be clear. UserName specify how will the user be recognized by vCloud Director and EmailAddress will be his/her email address for notifications. The next two parameters contain given name and surname which VCD will combine into full name. Not sure why the assertion name needs to be specified in such long format but only this way it worked for me. In theory you could also pass ‘fullname’ if you have field in your directory that contains full name (my Active Director does not).

Next we have Groups. I do not know how to pass AD groups in a dynamic way, so this is a hardcoded example – all users who use this SaaS definition will belong to CokeAdmins group. You can obviously omit this if you will only import users by name.

The last property is Role – again this is optional and should be used only if we want to manage roles in IdPs and not in VCD, where we would import the user with Defer to Identity Provider role – see here for more details. I am using here unused AD Employee ID field. 

  1. Now we can finish the wizard by clicking next, select access policy (keep default) and reviewing the Summary on the next screen. As last step we can click Save & Assign, where we are presented to select users that should have this newly created App in their catalog.
  2. Next we need to retrieve metadata configuration of VIDM – this is by going back to Catalog (all the way up) and clicking Settings. From SAML Metadata download Identity Provider (IdP) metadata. 
  3. Now we can finalize SAML configuration in vCloud Director. Still on Federation page click Use SAML Identity Provider checkbox and import the downloaded metadata (idp.xml) with Browse and Upload buttons and click Apply. 
  4. From now on, login screen will default to SAML authentication, but you can always revert to local authentication with: https://<vcloud_fqdn>/cloud/org/<org-name>/login.jsp
    However, we first need to import some users/groups to be able to use SAML. You might need to re-login to see the option to add SAML users and groups. You can import VIDM users by their user name or group (the hardcoded name CokeAdmins). We can assign role or optionally leverage Defer to IdP (if you have role field populated in AD). 
  5. Login to VIDM and click on the application tile to be logged straight into VCD Organization (the Flex legacy UI). 

You can also directly enter the Flex or HTML 5 URL and you will be redirected to VIDM login screen.

As mentioned in step 4, I am managing user roles from Active Directory so I just need to import one group into VCD with Defer to IdP role and I am done with user management in VCD. The role field that VIDM uses is EmployeeID, however that field in AD can have only numerical value and VCD expects role as text string. The workaround I am using is that in AD I actually use User Description field and then in VIDM I have changed the mapping. So lets first have a look how it looks in AD:

Here is my VIDM custom AD IdP mapping:

 

vRealize Business for Cloud API Authentication

$
0
0

vRealize Business for Cloud (vRBC) can be used to meter vSphere, NSX and vCloud Director endpoints. I have struggled a bit to obtain necessary metering data via API due to very brief documentation, so let me describe step by step how to do so.

Although vRBC supports local accounts, this is only for testing purposes. In production you should always use VMware Identity Manager (VIDM) authentication. VIDM appliance deployment is not hard and the integration with vRBC is quite simple through vRBC VAMI UI.

Now to use vRBC API you first need to obtain authentication token from VIDM. Go to vRBC appliance and from /usr/local/tomcat/itbm-server/conf/itfm-oauth.properties  retrieve client.id and client.secret values.

These values are used to retrieve the authentication token from VIDM. You will get it with:

POST https:// <vidm-IP> /SAAS/API/1.0/oauth2/token?grant_type=client_credentials

and provide the BASE64 encoded credentials in Authorization header.

Now copy the access_token from the response and use it in your API call to retrieve metering reports from vRBC:

vCloud Availability – Cloud Proxy with Multiple NICs

$
0
0

Cloud Proxy is important component of vCloud Availability solution that sits in DMZ and tunnels replicated traffic in and out of the provider’s environment. For deep dive on the traffic flows see this older article. Cloud Proxy is very similar to vCloud Director cell, it runs on Linux VM, can be multihomed with internet and management facing interfaces.

By default, Cloud Proxy uses its primary network interface both for to-the-cloud (port 443) and from-the-cloud (port 31031) traffic. When multihoming is used, it might be beneficial to move the listener of the from-the-cloud traffic to the internal interface. This can be accomplished by adding the following line to the $VCLOUD_HOME/etc/global.properties file, with the IP address of the internal interface.

cloudproxy.fromcloudtunnel.host = 192.168.250.110

After restarting the cell, the listener will be moved the the new IP address.

Here is example from my lab:

Cloud Proxy with two NICs:

[root@vcd-01a ~]# ifconfig
eno16780032: flags=4163&lt;UP,BROADCAST,RUNNING,MULTICAST&gt; mtu 1500
inet 192.168.110.40 netmask 255.255.255.0 broadcast 192.168.110.255
inet6 fe80::250:56ff:fe3f:969 prefixlen 64 scopeid 0x20&lt;link&gt;
inet6 fdba:dd06:f00d:a400:250:56ff:fe3f:969 prefixlen 64 scopeid 0x0&lt;global&gt;
ether 00:50:56:3f:09:69 txqueuelen 1000 (Ethernet)
RX packets 45153159 bytes 11625785984 (10.8 GiB)
RX errors 0 dropped 1118 overruns 0 frame 0
TX packets 52432329 bytes 14266764397 (13.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens224: flags=4163&lt;UP,BROADCAST,RUNNING,MULTICAST&gt; mtu 1500
inet 192.168.250.110 netmask 255.255.255.0 broadcast 192.168.250.255
inet6 fe80::570a:1196:4322:521f prefixlen 64 scopeid 0x20&lt;link&gt;
inet6 fdba:dd06:f00d:a400:3495:c013:e72:cc58 prefixlen 64 scopeid 0x0&lt;global&gt;
ether 00:50:56:37:03:81 txqueuelen 1000 (Ethernet)
RX packets 4409 bytes 279816 (273.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 26 bytes 2691 (2.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Before the edit:

[root@vcd-01a ~]# netstat -an|grep 31031
tcp6 0 0 192.168.110.40:31031 :::* LISTEN

After the edit and cell restart:

[root@vcd-01a ~]# netstat -an|grep 31031
tcp6 0 0 192.168.250.110:31031 :::* LISTEN

vCloud Availability – Updated Whitepaper

$
0
0

I have updated my vCAT-SP vCloud Availability whitepaper to reflect changes that came with vCloud Availability 2.0 and vSphere 6.5/6.7.

It can be downloaded from the vCAT-SP site from the Storage and Availability section. The direct link to PDF is here. You will know you have the latest document if you see June 2018 date on the title page.

Edit highlights:

  • Installer Appliance section
  • Tenant and Provider portal sections
  • PSC section update
  • Supported Org VDC Topologies
  • Application Network Design
  • Network Bandwidth Requirements
  • Monitoring updates
  • Updates and Upgrades section
  • Monitoring with vRealize Operations

Embedding vCloud Availability Portal into vCloud Director UI

$
0
0

Some time ago I blogged about the possibility to link to vCloud Availability Portal directly from vCloud Director UI (here and here). This was done by inserting custom links into the vCloud Director Flex UI.

vCloud Director 9.x tenant HTML5 UI provides much richer possibilities to embed additional links, pages and full websites. My colleague Kelby Valenti wrote two whitepapers and one blog post how to do so.

Extending VMware vCloud Director User Interface Using Portal

ExtensibilityExtending VMware vCloud Director User Interface Using Portal Extensibility – Ticketing Example

Publishing vCloud Director User Interface Extensions

VMware also already released one service that integrates its UI into vCloud Director – vRealize Operations Tenant App.

In the below screenshot you can see VCD UI extended with five new sections that appear as additional menu options next to Datacenters, Libraries and Administration:

Stub Module – default example included in the UI Extensibility SDK providing static page example (Terms of Service, etc.).

Operations Manager – above mentioned vRealize Operations Tenant App

Blog – this blog embedded as iframe.

Documentation – Static page with links to vCloud Director documentation.

The last module is the vCloud Availability 2.0 portal – the subject of this article:

It is also embedded using iframe.

I am attaching the source files so you can download and adapt them for your purposes. You will also need the SDK and I recommend deployment automation created by Kelby as described in his blog post listed above.

Some notes:

  • The actual link to the portal is in the src/main/vcav.component.ts file. In my case it is https://portal.proxy.cpsbu.local so replace it with the correct link for your environment.
  • For security reasons the vCloud Availability portal prohibits being rendered in browser frame by setting  X-Frame-Options header to DENY. To work around this limitation I am replacing the header with X-Frame-Options: ALLOW-FROM <VCD-url> on the existing load balancer that is load balancing my two vCloud Availability Portal nodes as well as redirecting external port 443 to appliances’ port 8443. This is done with NSX Edge Gateway, SSL termination and the following application rule:
  • The link to the portal is also passing the vCloud Director session authentication token for Single Sign-On. Note that however in the current release (2.0.1) this functionality is broken.

 

vCloud Director Service Library – Change AD Password

$
0
0

vCloud Director version 9.1 introduced the ability to easily create custom services and display them in the new user interface as tiles under Service Library. The services are created in vRealize Orchestrator as workflows and then presented to tenants or system administrators with simple categorization.

The screenshot below shows the Service Library with Backup and User Management categories and some services that I created for demonstration.

The actual feature is not very well documented so I will show on one simple (but useful) example how to implement it.

I am going to create Change LDAP Password service tile. While vCloud Director UI allows changing passwords for local users, users that are imported from integrated LDAP cannot change their password via vCloud Director UI so adding such service actually makes sense.

  • Set up vRealize Orchestrator: as system admin log in into the provider H5 UI (https://<vcd-UI>/provider) and set up connection to external vRealize Orchestrator server (that obviously must be installed and configured first). Note that for this example we will not need any custom plugins. Content Libraries > Library Administration > Service Management > vRO Servers
  • Set up Service Categories in the next menu.
  • Make sure that users have access to the Service Library. This is controlled with new rights under section Additional Services. I have added all three rights to the global Organization Administrator role and also to all existing organizations. You can obviously add them to also less privileged roles. This must be done via vCloud API.
  • Prepare the workflow in the vRealize Orchestrator (vRO). I assume the reader already knows how to create generic vRO workflows so I will not go into too much detail. You must configure the built in Microsoft Active Directory plugin with the Add an Active Directory server configuration workflow.
  • In very high level, the workflow execution will consist of the following steps:
  1. Presentation window to collect Password and confirmPassword values and compare them for validation. Note that I did not succeed using SecureString variables (vCloud Director seems to not support them) and had to use simple string type which results in password being visible on the screen.
  2. Next we will get some custom properties from vCloud Director. You can use four of them: _vcd_orgName, _vcd_orgId, _vdc_userName (sic!) and _vcd_isAdmin. In my Active Director I have the following OU structure for each org:
    Each vCloud Director organization has its own OU under VCD organization unit. The OU name matches the Organization name.
    To get the custom properties you need to create custom action (in my case Load VCD Inputs with the following script):
    As can be see from above screenshot, I only need _vcd_orgName to find the OU and _vdc_userName to find the user account in AD.
  3. The next step is built in getOrganizationUnitFromOrganizationUnit action that can be found under com.vmware.library.microsoft.activeDirectory.  As inputs I am supplying value equal to the container of my parent (VCD) OU and the org name as string. The output is the organization OU.
  4. Now we can find the user object based on org OU and username string. This is done with getUserFromContainer action (again from com.vmware.library.microsoft.activeDirectory).
  5. As mentioned in the beginning I was forced to use String type variable for the password, but the change password action requires Secure String. This simple action will provide the conversion.
  6. The last step is to change the password with setUserPassword action (found in com.vmware.library.microsoft.activeDirectory).
  • Now we can save the workflow and give it a proper description that will be visible to tenants.
  • Back in vCloud Director we can now in the provider UI import the workflow into Service Library. This is done at: Content Libraries > Services > Service Library > Import. Simple wizard will ask for target library (category), source vRO and the workflow.
  • Once a workflow is imported it can be Published to system admins, all or subset of tenants. Find the workflow tile and select Manage.

That is all. Test as tenant logged in with LDAP account in the new H5 UI.

Observe and troubleshoot the workflow execution in vRO.

vCloud Availability – Resizing Disk of Protected VM

$
0
0

A customer asked how to resize a disk of very large VM (file server) which is protected with vCloud Availability and thus replicated to the cloud.

It is not straight forward as the underlying replication engine relies on tracking changed blocks and both the source and target disks must have the same size. In short the replication must be stopped for a moment and then re-established after the necessary disk resizing. Here is step by step process:

  1. Fail over VM via vCloud Availability UI/API without powering on the VM (leave on-prem running).
  2. Consolidate the VM in the cloud (this must be done by SP or use workarounds with copy to catalog and deploy back).
  3. Stop replication of on-prem VM (via vSphere UI plugin).
  4. Resize disk of on-prem VM (including partition and file system).
  5. Resize disk of cloud VM from step #2 (only hardware).
  6. Setup replication from scratch by using ‘Use replication seeds’ option while selecting the seed of failed over cloud VM from step #5

 

What’s New in vCloud Director 9.5

$
0
0

After vCloud Director 9.1 release in March we have new version 9.5 out!

Here are links to release notes and a whitepaper describing its new features.

Let me also go through the new features here so I can link additional blogs that will dive deeper into each one.

New UI

  • The tenant HTML 5 UI (accessible via /tenant link) has been further enhanced and has now almost full feature parity with the legacy Flex UI. There might be some corner cases or small features missing, but in general tenants do not really have a reason to not use it all the time. Also new features (e.g. multi-site networking) are available only in the new UI
  • Some highlights:
    • VDC dashboard working across all associated Org VDCs (across one or many vCloud Director instances)
    • Task pane
    • Ribbon
    • Multisite networking
    • Independent disk support
    • Networking services improvements
  • The UI can now be customized with custom themes (at system level) with this css theme generator.
  • Provider UI (accessible via /provider link) has been also enhanced, although the legacy Flex UI is still needed and system administrators will probably spent most time there.
  • Some highlights:
    • User management, IdP
    • Roles and rights management

Networking

  • IPv6 support.
    Both external and Org VDC networks (including vApp networks) can be assigned with IPv6 subnet. Note that you cannot use distributed Org VDC networks with IPv6 as NSX Logical Distributed Router supports only IPv4.
  • Cross VDC networking.
    In multi vCenter Server, single NSX domain architecture, it is now possible to create universal logical switches spanning multiple VDCs across VCs connected to universal distributed router with multiple egress Org VDC Edge Gateways. There is also a new concept of VDC groups to create (site) grouping.
  • Limited NSX-T support.
    NSX-T is a new network virtualization platform that is in many aspects differs from NSX-V. NSX-T architecture is not tied with vCenter Servers, has different concept of routing – ESGs vs T0 and T1 routers and also uses Geneve instead of VXLAN as encapsulation protocol. Due to the huge differences between NSX-T and V, vCloud Director 9.5 currently only allows the import of existing logical switches as Org VDC networks and distributed firewalling (API only).
  • Related to the above, it is now in vCloud Director possible to register vCenter Server without NSX-V associated manager (API only).

Compute

  • Org VDC compute policies
    User with Edit VM CPU and Memory reservation settings right can configure VM reservation, limit and shares in any Org VDC allocation model. Org VDC maximums (quotas) are still enforced.  vCloud Director will also not override reservation configurations done at vCenter Server level. This is groundwork for future enhancement.
  • It is no longer needed to prepare ESXi hosts to be used by vCloud Director. No agents nor custom attributes need to be installed or set. Provisioning or decommissioning of ESXi host is much simplified.

    Storage

  • VM moves across VDCs (Move to … action) or clusters no longer use cloning method, but instead use more efficient relocate VC function.

Other

  • New role based access control with right bundles, global roles (published/delegated to one or more tenants). Also system admins imported from LDAP group can have a role assigned.
  • New /cloudapi APIs are now autodocumented with Swagger and can be viewed and executed directly from vCloud Director API Explorer web point at /api-explorer. Note that /cloudapi does not replace /api. Those APIs are different and only some new features are available via the /cloudapi endpoint (H5 UI branding, vRealize Orchestrator services, UI plugins, etc.).
  • Oracle database can no longer be used as vCloud Director database. MS SQL database is now announced as deprecated.
  • The creation of legacy Edge Gateways is now in deprecated mode and will be removed in future releases.
  • vCloud API version is now at 31.0. Some older ones were removed (notably 5.6, 9.0) so make sure your scripts are updated. As always check /api/versions for the supported and deprecated list.
  • vCloud Director cell is now available as Photon appliance. This can simplify greenfield deployments, although NFS transfer share, RabbitMQ and vCloud databases (PostgreSQL or Cassandra) are not available in appliance format yet. You can still download vCloud Director binaries to be used in CentOS/RHEL VM as before.
  • At the release day vSphere 6.0U3, 6.5U1/U2 and 6.7.0, NSX-V 6.3.5, 6.3.6, 6.4.0-6.4.3, NSX-T 2.2 are supported. Always check for updates here.
  • VCD-CLI (CLI command tool to manage VCD both for tenants and sys admins) and pyvcloud (Python SDK) have been updated as well.
  • vCloud Availability 2.0.1 and vCloud Availability for Cloud-to-Cloud DR 1.0 are not supported with vCloud Director 9.5. Both will require updates, which are coming soon.

 

How to Change vCloud Director Installation ID

$
0
0

During installation of vCloud Director you must supply installation ID from range 1-63. Its purpose is very similar to vCenter Server ID, it is used for generation of unique MAC addresses for VMs running in the vCloud Director instance. The MAC address format is 00:50:56:ID:xx:xx. vCloud Director overrides MAC vCenter Server assignments.

Obviously on the same layer 2 network MAC addresses must always be unique so when using L2 VPN or similar network extension mechanisms a care should be given that each vCloud Director instance participating in such network extension has a different installation ID to guarantee non-overlapping MAC addresses of deployed VMs.

Until vCloud Director 9.5 it was not possible to change its installation ID. The reason was, that during the installation vCloud Director actually generates all possible MAC addresses in its database, so that table would have to be regenerated with the ID change.

This can now be accomplished with cell-management-tool mac-address-management CLI command that takes care of the MAC address table regeneration and also informs how many MAC addresses still exist that are based on the old ID. Those existing VMs will keep its old MAC unless it is manually reset/regenerated from vCloud Director UI or via vCloud API.

The CMT command can either regenerate MAC addresses with a specific ID that can differ from the installation ID (option –regenerate-with-seed), or you can change the installation ID in the database first (GSS alert!) and just use –regenerate option.

The pgAdmin screenshot below shows the ID location in the vCloud DB. For production setups this should be done with help from GSS.

Finally, here is a screenshot showing the –show-seed option listing the actual MAC usage based on the seed IDs.

Viewing all 242 articles
Browse latest View live