A few days ago I was doing some testing with Hyper-V. As I can easily create a Windows Server using vSphere (6.5 in my case), I decided create my Hyper-V host on a VM.

In order to get this to work I created a VM running Windows Server 2019 and then I needed to do some customization to it.

VM CPU Settings

When creating the VM, change the CPU/MMU Virtualization settings to Hardware CPU and MMU.

After the VM is created, make sure it's Powered Off, and navigate to its folder under the Storage menu on vSphere.

Download the <VM Name>.vmx file to your PC and open it with a Text Editor.

In the end of the file, add those lines:

hypervisor.cpuid.v0 = "FALSE"

vhv.enable = "TRUE"

Save the VMX file and upload it back to the VMs folder. In my case, instead of overwriting the file in the datastore, I renamed it to <VM Name>.vmx.old.

Installing Hyper-V

Power on the VM, install Windows and VMware Tools if you haven't done so, and then go to Server Manager.

Click Add roles and features and follow the wizard to install Hyper-V.

Restart the Server as requested, then launch Hyper-V Manager.

As a quick test, create a new VM with the default values (click New > Virtual Machine and then follow the wizard). From my testing, you would get an error message when trying to Power On this VM if something is wrong with the Hyper-V VM.

Networking

After creating my test VM, I noticed that I could not ping anywhere in the network apart from itself and the Hyper-V Host. I checked the Virtual Switch Manager on Hyper-V and also the Networking settings on the VM, and all seemed to be configured as expected. The way I got it to work was by going to the ESXi Console and enabling Promiscuous mode and Forged transmits in the vSwitch that was connected to the Hyper-V Server VM.

--

This configuration was done on my testing environment and I cannot guarantee this is fit for production environments.

The postings on this site are my own and do not represent VMware’s positions, strategies or opinions.

Many promising start-ups fail abruptly due to poor quality applications. Software development companies face growing challenges in order to meet tough deadlines. Moreover, they have to maintain product quality as well. In the past, companies used to take months to deliver applications but with the advent of current technological advances, release times are shorter than ever before. IT companies invest time and money into setting up quality assurance teams. Whether it is a start-up or an organization, hiring an independent software testing company is the right choice to make.

Setting up a QA department is not a viable option for most companies. Let’s have a look at the top five reasons why organizations should invest in an independent service provider:

1. The Testing Skill Set

Let’s talk about first things first. As an entrepreneur or business executive, the first question that comes to mind is when to avail such services? Well, quality assurance is not an easy thing to do and neither do all IT companies have the skills and tools to perform these tests efficiently. They lack resources, time, and expertise as well. Thus, when new in business, a startup shouldn’t mind hiring software testing services.

2. The Effects of Business Processes on Quality

Due to product release deadlines, developers often fail to focus on other projects. Too often the business’ own processes are time taking that affect software quality adversely. But if companies hire an independent QA testing company, their services can fill this gap between quality and timely delivery of the project.

3. The Lack of Expertise

Market leaders in the IT industry leverage their own software testing mechanisms to achieve fast delivery of products. However, this is not possible for small and medium-sized companies. QA testers working for such businesses do not have their hands-on extensive testing tools and techniques which limits their expertise. So, looking for an external source for software testing is the only choice they are left with. Moreover, expert software testing companies use a broad range of tools to enhance software quality.

4. The Cut Down on Costs

An IT business should also choose to outsource testing to an independent company if the cost of testing is too high in their region. Outsourcing is a cost-effective solution, that doesn’t end up increasing the overall cost of the product.

5. The Guarantee from Quality Assurance

It is obvious that hiring an independent company means that testing services come with a guarantee. On the contrary, even if a business sets up their own QA teams, there is no guarantee that such an initiative will work. So, businesses consider hiring services of an independent testing company for better results.

With the growing digital world and number of devices, testing has become a vital part of the software development process. Businesses today must invest extensively and leverage testing efforts to earn profits and maintain their reputation in the industry.

The release of Workspace ONE 19.03 brought in a very seamless integration of Okta Applications.

If you have integrated the two solutions previously you will recall the number of steps required to create and entitle new applications in Workspace from Okta. This integrations you to create and entitle applications in Okta and have them seamless appear in Workspace ONE along with your Native and Virtual Applications.

Lets walk through the steps to integrate the two solutions.

In this blog we are going to assume that you have existing connectors for Workspace ONE UEM and Workspace ONE Identity. We are also assuming you have your Workspace ONE Identity access policies already configured for Mobile SSO, Certificate or Password (Cloud Deployment).

Part 1: Core Setup and Configuration

The objective of this section to configure Okta to delegate authentication to Workspace ONE Identity where Mobile SSO and Device Compliance are configured.

Step 1:  Exporting the Workspace ONE IdP Metadata

1. Log into Workspace ONE Identity Console -> Catalog -> Settings
2. Click on "Identity Provider (IdP) metadata" and save the file locally.
   
3. Scroll down to the Signing Certificate Section and Download.
   

Step 2: Add Identity Provider to Okta

1. Log into your Okta Admin Console
2. Click on Security -> Identity Providers -> SAML 2.0 Identity Provider
3. Click on Add Identity Provider
4. Provider a name: ie. Workspace ONE
5. For IdP Username, select "idpuser.subjectNameId"
6. For "If no match is found", select "Redirect to Okta sign-in page"
7. For your "IdP Issuer URI", retrieve and paste this value from your SAML Metadata you downloaded in step one.
   
8. For your "IdP Single Sign-On URL",retrieve and paste this value from your SAML Metadata you downloaded in step one.
   
9. For the "IdP Signature Certificate, upload the signing certificate you downloaded in Step 1.
10. Expand the newly created Identity Provider and download the metadata
    

Step 3: Create Okta Application Source in Workspace ONE Identity

1. In Workspace ONE Identity Console, click on Catalog -> Settings
2. Click on Application Sources
3. Click on Okta
   
4. On the Okta Application Source page, click next
   
5. Select "URL/XML" and paste the contents of the Okta metdata we downloaded in the previous step.
   
6. On the Access Policies page, click next (see note below):
   
   
   Note: For the purpose of this blog we are using the "default_access_policy_set". However, it is recommended that you create an access policy specific for the Okta Application Source.  The reason for this recommendation is that you'll likely not want any fallback mechanisms when performing Mobile SSO (so we can present a error message to enroll your device). However, when you enroll your device into Workspace ONE UEM you probably want a fallback mechanism.
   
   
7. Click Save on the summary page.

Step 4: Create Okta Routing Rules

1. Log into the Okta console.
2. Go to Security -> Identity Providers
3. Click on Routing Rules
   
4. Click Add Routing Rule
5. Provide a Rule Name
6. Select the platforms that you want to using Workspace ONE Identity (ie. IOS/Android)
7. Select the applications that you want to use Workspace ONE Identity
8. Select the Identity Provider we created previously
   
9. Click Create Rule

Step 5: Testing

1. Access your Salesforce development tenant
2. Select to Authenticate with Okta
3. Based on your Okta Rules, you should be redirected to Workspace ONE Identity.
4. Authenticate within WS1
5. You should return back to Okta and be redirected and successfully authenticated into SalesForce
   
   

Troubleshooting Tips

1. Ensure your user is entitled to Salesforce within Okta.
2. Verify the IdP Issuer in Okta is correct:
   
   https://aw-sdsatest.vidmpreview.com/SAAS/API/1.0/GET/metadata/idp.xml
3. Verify the username values we are sending from Workspace ONE to Okta will match:
     TO

The release of Workspace ONE 19.03 brought in a very seamless integration of Okta Applications.

If you have integrated the two solutions previously you will recall the number of steps required to create and entitle new applications in Workspace from Okta. This integrations you to create and entitle applications in Okta and have them seamless appear in Workspace ONE along with your Native and Virtual Applications.

Lets walk through the steps to integrate the two solutions.

In this blog we are going to assume that you have existing connectors for Workspace ONE UEM and Workspace ONE Identity. We are also assuming you have your Workspace ONE Identity access policies already configured for Mobile SSO, Certificate or Password (Cloud Deployment).

Part 2: Unified Digital Workspace

The objective of this section to automatically sync all SAML enabled applications from Okta to Workspace ONE. This configuration will eliminate the manual steps required to both create and entitle Okta applications in Workspace ONE.

Step 1: Create an Okta API Key

1. Log into the Okta Admin Console
2. Go to Security -> API
3. Click on Tokens
   
   
4. Click Create Token
5. Provide a name for the token
   
6. Click Create Token
7. Click the Copy Token button
   
   Note:  Its very important you copy and save this token somewhere. Once you close this window you will not be able to retrieve this value again. You will have to delete the token and create a new one.

Step 2: Configure Workspace ONE with Okta API Information

1. Log into the Workspace ONE Admin Console
2. Click on Identity & Access Management -> Setup -> Okta
   
   Note: If you are using Chrome, please be aware of Chrome auto filling any fields.
   
   
3. Enter your Okta Cloud URL.
   Note: Do NOT use the Admin URL!!
   
   
   
4. Paste your Okta API Token
5. Select the username search parameter that will match in Okta.
6. Click Save

NOTE: Okta Applications will NOT appear in the Workspace ONE Admin Console

Step 3: Testing

1. Log into Workspace ONE with a directory account.
2. You should now see all your Okta Applications along with any other applications configured in Workspace ONE.

There are times during troubleshooting where you like to see a particular attribute in Workspace ONE Identity (VMware Identity Manager) and its not displayed in the web portal or times when you would like to update a particular attribute or delete a JIT user.

DISCLAIMER:  Please use the API with caution as this can potentially cause issues if not used appropriately. Please do NOT use in Production. Please use at your own risk.

In this blog we'll walk through a few useful API calls to help in your troubleshooting. For a complete list of API calls and documentation:

VMware Identity Manager API - VMware API Explorer - VMware {code}

Please download and install the latest version of Postman.

In this blog we'll go use the following API's:

• Get Specific User Details
• Update SCIM User
• Delete SCIM User
• Create SCIM User

Step 1: Getting your OAuth Token

In order do use the SCIM based API you need an OAuth token. I'm going to walk through two different ways of getting a token to use in your environment.

If you are going to access a particular environment quite often using postman I would suggest you go with Option 1. If its unlikely you will access a particular environment that often then you should go with Option 2.

Option 1: Creating an OAuth Application

1. Log into Workspace ONE Identity Admin Console
2. Click on the Catalog (down arrow) and select Settings
   
3. Click "Remote App Access"
4. Click Create Client
   
5. Select "Service Access Token" from the Drop down menu
6. Provide a Client ID ie. Postman
7. Expand Advanced
8. Click Generate Shared Secret (or provide one)
9. Click Add
   
10. We will configure Postman in the next section.

Option 2: Using your browser cookies

1. Make sure you have a way of accessing your browser cookies. I use a Chrome plugin called "Edit this cookie"
   
2. Log into your Workspace ONE Identity Admin Console
3. Click the Cookie Icon in the chrome address bar
4. Search for the "HZN" cookie
   
5. Copy the value for HZN.
6. We will configure Postman in the next section.

Step 2: Configure Postman to use your OAuth Token

Depending which option you chose in the previous step, follow the instructions below to add your OAuth Token

Option 1: Creating an OAuth Application

1. Open a new Tab in Postman
2. In the authorization section, select "OAuth 2.0" as the type:
   
3. Click Get New Access Token
   
4. Provide a Token Name (ie. Workspace ONE)
5. Under "Auth URL", enter https:[Tenant URL]/SAAS/auth/oauth2/authorize
   ie. https://dsas.vmwareidentity.com/SAAS/auth/oauth2/authorize
6. "Under Access Token URL", enter https:[Tenant URL]/SAAS/auth/oauthtoken
   ie. https://dsas.vmwareidentity.com/SAAS/auth/oauthtoken
7. Under Client ID, enter your Client ID from step 1.
8. Under Secret, enter your secret from step 1.
9. Under Scope, leave blank.
10. Under Grant Type, select "Client Credentials"
    
11. Click Request Token
12. Click on WorkspaceONE under Existing Tokens
13. Select Use Token
    
14. If you click on the headers tab you will see the "Authorization" header has been added with the correct token.

Option 2: Using your browser cookies

1. Open a new Tab in Postman
2. Click on the Headers Section
3. Add the Header Key "Authorization"
4. In the Value, type "Bearer" then paste the value of the HZN cookie.
   

Getting User Details

Now that you have your OAuth token, we can use this token to query Workspace ONE Identity.

1. For the HTTP Method, select "GET"
2. Enter the following for the URL: https://[TENANT URL]/SAAS/jersey/manager/api/scim/Users?filter=username%20eq%20%22MyUserID%22
3. Replace MyUserID with a username in your environment
   ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/scim/Users?filter=username%20eq%20%22sdsa%22
4. This will return a complete result set of attributes for the particular user.
   

Updating User Details

In order to update user details via the API, you will need to collect some information from the Get User Details.

In my example, I'm going to update the "userPrincipalName" in Workspace ONE Access for one of my users.

1. Perform a "Get" on the particular user and retrieve the schema information. Please note, this will be different for each tenant as the tenant name is part of the schema.
   
2. Copy this section to notepad.
3. Retrieve the section which contains the attribute(s) you want to update
   
4. Copy the ID of the User
   
5. Open a new Tab in Postman
6. Add the Authorization Header as per the previous section.
7. For the HTTP Method, select "PATCH"
8. For the URL, enter: https://[TENANT URL]/SAAS/jersey/manager/api/scim/Users/[ID]
   Replace the Tenant URL with your URL
   Replace the ID with the ID from the step 4 in this section.
   ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users/884b7e7d-6a7b-4985-b113-56235826e8a6
9. Select Body
10. Enter the JSON in raw text that we'll post to Workspace ONE
11. Select "JSON (application/json)" as the Content-Type
    
12. Click Send
13. You should receive a "204 No Content" response
    
14. If you perform a GET User again you should see the value has changed.

Delete Users

If you are using JIT to onboard users into Workspace ONE Identity you've probably noticed there is no way to delete users in the web portal. They only way to delete is with the API.

1. Perform a "Get" on the particular user and retrieve the ID
   
2. Open a new Tab in Postman
3. Add the Authorization Header as per the previous section.
4. For the HTTP Method, select "DELETE"
5. For the URL, enter: https://[TENANT URL]/SAAS/jersey/manager/api/scim/Users/[ID]
   Replace the Tenant URL with your URL
   Replace the ID with the ID from the step 4 in this section.
   ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users/f6f89782-0a2a-4cc8-84a8-057f1da6ecde
6. Click Send
   
7. You should receive a "204 No Content" response
   
8. If you perform a GET User again you should see no results found.
   

Create Users

Creating Users in Workspace ONE Identity require a lot more steps. I reluctantly decided to document the steps as this should really be done by the out of the box connectors. The process is slightly different between System Directory, Local Directory, and Other.  The "Other" directory is created automatically when setting up the UEM/WS1 Integration.

Creating Users in the System Directory

1. Open a new Tab in Postman
2. Add the Authorization Header as per the previous section.
3. For the HTTP Method, select "POST"
4. For the URL, enter: https://[TENANT URL]/SAAS/jersey/manager/api/scim/Users
   Replace the Tenant URL with your URL
   Replace the ID with the ID from the step 4 in this section.
   ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users
5. Set the Content-Type to "application/json"
6. Use the following as a sample:

{  "schemas": [    "urn:scim:schemas:core:1.0",    "urn:scim:schemas:extension:workspace:tenant:sva:1.0",    "urn:scim:schemas:extension:workspace:1.0",    "urn:scim:schemas:extension:enterprise:1.0"  ],  "userName": "testing4@mydomain.com",  "name": {    "givenName": "first4",    "familyName": "last4"  },  "emails": [    {      "value": "testing4@mydomain.com"    }  ],  "password": "Password$!"
}

Creating Users in a Local Directory

1. Open a new Tab in Postman
2. Add the Authorization Header as per the previous section.
3. For the HTTP Method, select "POST"
4. For the URL, enter: https://[TENANT URL]/SAAS/jersey/manager/api/scim/Users
   Replace the Tenant URL with your URL
   Replace the ID with the ID from the step 4 in this section.
   ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users
5. Set the Content-Type to "application/json"
6. Use the following as a sample:

{  "schemas": [    "urn:scim:schemas:core:1.0",    "urn:scim:schemas:extension:workspace:tenant:sva:1.0",    "urn:scim:schemas:extension:workspace:1.0",    "urn:scim:schemas:extension:enterprise:1.0"  ],  "userName": "testing5@mydomain.com",  "name": {    "givenName": "first5",    "familyName": "last5"  },  "emails": [    {      "value": "testing5@mydomain.com"    }  ],  "password": "Password$!",   "urn:scim:schemas:extension:workspace:1.0": {        "internalUserType": "LOCAL",        "userStatus": "1",        "domain": "mydomain.com"      }


}

Creating Users in an Other Directory

The steps to create a user in an other directory is almost identity to the local directory except that we need to know the "userStoreUuid" of the directory and we need an ExternalID. The External ID should be a valid ObjectGUID. If you don't have a valid ObjectGUID you will have problems when enrolling devices from the Workspace ONE Intelligent Hub application. Ensure that you generate a proper guid. See Online UUID Generator Toolas a example of a proper guid.

1. Open a new Tab in Postman
2. Add the Authorization Header as per the previous section.
3. For the HTTP Method, select "GET"
4. For the URL, enter: https://[TENANT URL]/SAAS/jersey/manager/api/connectormanagement/directoryconfigs?includeJitDirectories=true
   Replace the Tenant URL with your URL
   Replace the ID with the ID from the step 4 in this section.
   ie. https://dsas.vmwareidentity.com/SAAS/jersey/manager/api/connectormanagement/directoryconfigs?includeJitDirectories=true
5. Click Send
6. In the response, search for your "Other Directory" and copy the userStoreID
8. Open a new Tab in Postman
9. Add the Authorization Header as per the previous section.
10. For the HTTP Method, select "POST"
11. For the URL, enter: https://[TENANT URL]/SAAS/jersey/manager/api/scim/Users
    Replace the Tenant URL with your URL
    Replace the ID with the ID from the step 4 in this section.
    ie. https://dsas.vmwareidentity.com//SAAS/jersey/manager/api/scim/Users
12. Set the Content-Type to "application/json"
13. Use the following as a sample and don't forget the External ID.

{  "schemas": [    "urn:scim:schemas:core:1.0",    "urn:scim:schemas:extension:workspace:tenant:sva:1.0",    "urn:scim:schemas:extension:workspace:1.0",    "urn:scim:schemas:extension:enterprise:1.0"  ],  "externalId": "c58085e6-c97a-4df3-8e4a-e376913fab17",  "userName": "testing6@oktatest.com",  "name": {    "givenName": "test6",    "familyName": "last6"  },  "emails": [    {      "value": "testing2@oktatest.com"    }  ],  "password": "Password$!",   "urn:scim:schemas:extension:workspace:1.0": {        "internalUserType": "PROVISIONED",        "userStatus": "1",        "domain": "1dsavm.com",        "userStoreUuid": "987dca12-22e3-4ec6-8958-110cca481c3d",        "externalUserDisabled": false,        "userPrincipalName": "testing6@mydomain.com"      }
}

Troubleshooting

It would be impossible to discuss every combination of errors that can be returned using the API. Here are a few common ones:

1. If you receive the error "User is not authorized to perform the task.".
   This error typically means that your Oauth Token has expired. Regenerate your OAuth Token.  If you have used the browser cookies method to get your token, ensure that your HZN cookie is from the administrative interface.
2. When doing an update user, you receive the error ""???UNSUPPORTED_MEDIA_TYPE???""
   This error means that you are sending a blank or incorrect Content-Type. Check to make sure the content-type is set to "application/json"

VMware Photon OS 3.0 の参照 DNS サーバの設定は、

これまでの Photon OS とは様子が変わっているようです。

今回は、Photon OS 3.0 の DNS サーバ アドレスの確認と、設定変更をしてみます。

Photon OS 3.0 は、GitHub の URL からダウンロードできる

「OVA with virtual hardware v13 (UEFI Secure Boot)」を利用しています。

Downloading Photon OS · vmware/photon Wiki · GitHub

root@photon-machine [ ~ ]# cat /etc/photon-release

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=26156e2

Photon 3.0 の /etc/resolv.conf は下記のように、

nameserver に「127.0.0.53」というアドレスが設定されています。

root@photon-machine [ ~ ]# cat /etc/resolv.conf

# This file is managed by man:systemd-resolved(8). Do not edit.

#

# This is a dynamic resolv.conf file for connecting local clients to the

# internal DNS stub resolver of systemd-resolved. This file lists all

# configured search domains.

#

# Run "resolvectl status" to see details about the uplink DNS servers

# currently in use.

#

# Third party programs must not access this file directly, but only through the

# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,

# replace this symlink by a static file or a different symlink.

#

# See man:systemd-resolved.service(8) for details about the supported modes of

# operation for /etc/resolv.conf.

 

nameserver 127.0.0.53

このアドレスは、DNS サーバ関連のようで、UDP 53 番ポートで待ち受けているようです。

root@photon-machine [ ~ ]# ss -an | grep 127.0.0.53

udp   UNCONN  0        0                              127.0.0.53%lo:53                                               0.0.0.0:*

そして 53番ポートのプロセスを確認してみると、

resolv.conf のコメントとも関係ありそうな systemd-resolve というものです。

root@photon-machine [ ~ ]# tdnf install -y lsof

root@photon-machine [ ~ ]# lsof -i:53 -P -n

COMMAND   PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

systemd-r 205 systemd-resolve   12u  IPv4   3644      0t0  UDP 127.0.0.53:53

root@photon-machine [ ~ ]# ps -p 205

  PID TTY          TIME CMD

  205 ?        00:00:00 systemd-resolve

これは、systemd 229 以降に導入された名前解決マネージャーの仕組みのようです。

https://www.freedesktop.org/wiki/Software/systemd/resolved/

ちなみに、Photon 3.0 は systemd 239 でした。

root@photon-machine [ ~ ]# rpm -q systemd

systemd-239-10.ph3.x86_64

DNS サーバのアドレスは、/etc/systemd/network/*.network ファイルの

「DNS=」で設定したものが反映されます。

Photon OS 3.0 では、デフォルトでは DHCP 設定のファイルが配置されています。

root@photon-machine [ ~ ]# cat /etc/systemd/network/99-dhcp-en.network

[Match]

Name=e*

 

[Network]

DHCP=yes

IPv6AcceptRA=no

現時点では、DHCP 設定により自宅ラボの  DNS サーバ 2台が設定されています。

root@photon-machine [ ~ ]# resolvectl dns

Global:

Link 2 (eth0): 192.168.1.101 192.168.1.102

resolvectl では、より詳細な情報も確認できます。

（デフォルトだとページャが作用しますが、とりあえず cat で全体表示しています）

root@photon-machine [ ~ ]# resolvectl | cat

Global

       LLMNR setting: no

MulticastDNS setting: yes

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

Fallback DNS Servers: 8.8.8.8

                      8.8.4.4

                      2001:4860:4860::8888

                      2001:4860:4860::8844

          DNSSEC NTA: 10.in-addr.arpa

                      16.172.in-addr.arpa

                      168.192.in-addr.arpa

                      17.172.in-addr.arpa

                      18.172.in-addr.arpa

                      19.172.in-addr.arpa

                      20.172.in-addr.arpa

                      21.172.in-addr.arpa

                      22.172.in-addr.arpa

                      23.172.in-addr.arpa

                      24.172.in-addr.arpa

                      25.172.in-addr.arpa

                      26.172.in-addr.arpa

                      27.172.in-addr.arpa

                      28.172.in-addr.arpa

                      29.172.in-addr.arpa

                      30.172.in-addr.arpa

                      31.172.in-addr.arpa

                      corp

                      d.f.ip6.arpa

                      home

                      internal

                      intranet

                      lan

                      local

                      private

                      test

 

Link 2 (eth0)

      Current Scopes: DNS

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 192.168.1.101

         DNS Servers: 192.168.1.101

                      192.168.1.102

ためしに、DNS サーバのアドレスを変更してみます。

設定ファイルを vi エディタで編集します。

root@photon-machine [ ~ ]# vi /etc/systemd/network/99-dhcp-en.network

今回は、下記の赤字部分を追記します。

[Match]

Name=e*

 

[Network]

DHCP=yes

IPv6AcceptRA=no

Domains=go-lab.jp

DNS=192.168.1.1

DNS=192.168.1.2

ネットワークを再起動します。

root@photon-machine [ ~ ]# systemctl restart systemd-networkd

DNS サーバアドレスが追加登録されました。

DHCP サーバによる DNS サーバのアドレスよりも高優先度で

ファイルに追記した DNS サーバが追加されました。

root@photon-machine [ ~ ]# resolvectl dns

Global:

Link 2 (eth0): 192.168.1.1 192.168.1.2 192.168.1.101 192.168.1.102

resolvectl コマンドの末尾 10行だけ表示してみると、

「Domains」のドメインも追加されています。

root@photon-machine [ ~ ]# resolvectl | tail -n 10

       LLMNR setting: yes

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

         DNS Servers: 192.168.1.1

                      192.168.1.2

                      192.168.1.101

                      192.168.1.102

          DNS Domain: go-lab.jp

実際に名前解決が発生すると、利用されている DNS サーバ（Current DNS Server）がわかります。

root@photon-machine [ ~ ]# resolvectl | tail -n 10

MulticastDNS setting: no

  DNSOverTLS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

  Current DNS Server: 192.168.1.1

         DNS Servers: 192.168.1.1

                      192.168.1.2

                      192.168.1.101

                      192.168.1.102

          DNS Domain: go-lab.jp

DNS サーバ のアドレスが変更されても、/etc/resolv.conf のアドレスは

127.0.0.53 のままですが、サーチドメインは追加されます。

root@photon-machine [ ~ ]# grep -v '#' /etc/resolv.conf

 

nameserver 127.0.0.53

search go-lab.jp

以上。Photon OS 3.0 の DNS サーバ アドレス設定の様子でした。

Just like any other business, real estate is also tricky. With the passage of time, real estate is evolving. There are certain factors which are giving a boost to this business. Technology is the major contributor to the transformation of real estate. There are different apps and gadgets which are facilitating both the buyer and seller in real estate. However, in this blog, we will specifically focus on how blockchain is changing the face of real estate as we see it. Before we take a deep dive in the details of blockchain and real estate connection, if you are looking for an apartment, then buy apartment in Palm Jumeirah. If you are looking for a decent and comfortable place, then you should definitely check these apartments out.

How does Blockchain work in Real Estate?

As we all know that blockchain is a growing list of records and each record is called a block. These blocks build upon each other. The beauty of blockchain is that it doesn’t hold all the information at the same server and instead it uses many servers at the same time. This mechanism has a lot of benefits which we will discuss in a while. Before that, let’s understand how it will work in the real estate business.

Since real estate is all about the huge database and records, blockchain makes the storage and handling of this data a lot easier. Different blockchain apps and software are made specifically made for the real estate businesses to gain the following mentioned benefits.

Benefits That Blockchain Has to Offer for Real Estate

1. Incorporation Transparency

Transparency in any business is the key to get the ultimate customer experience. The blockchain applications and software provides maximum security to the database of the clients and the company. Therefore, it prevents data leaks which can cause great troubles for both the customers and the company. This brings us to the second major benefit of blockchain which is trust building among the clients.

2. Building Trust

Since your clients will know that their information is in secure hands, they will tend to trust your company more than the others. Therefore, if you want to build an unbreakable trust relationship with your clients then blockchain is your solution.

3. Temper Resistant Database

As we have mentioned before that database in the blockchain is stored in different servers at different locations, therefore, it is practically impossible to reach to the database for a hacker. We have seen that in the past few years, data leakages cost millions to the companies. Therefore, blockchain is very significant for real estate business because in this business deals with very sensitive information of the clients and company.

4. Efficient Transactions

Money transactions are risky in any form but blockchain promises to make them as secure as possible. In real estate business, these transactions can be very huge and thus the loss can be big too. With blockchain, the whole process becomes secure and transparent and you are safe from all the frauds since nobody can temper the record of the transactions.

5. Limited Intermediaries

This is perhaps the most important benefit of blockchain. There are a lot of intermediaries and all of them charge separately for their services. Blockchain works in a way that everything from selecting the house to buying it is automated. This eliminates all the intermediaries from the process hence you are saved from both frauds and extra expenditures.

Now, with the help of blockchain, you can buy apartments, houses, and property more securely than ever.

There is no software that is free of defects and bugs. We know that defect management is a process that identifies and tracks bugs in software. Developers utilize defect tracking tools for easy detection at an earlier software development stage. These tools have become an important ingredient for developers and testers. Whether it is a small or medium enterprise, investing in these management tools improves the quality of products and helps in rolling out efficient software. Software testing companies have defect management systems that managers and executives utilize to view defects in systems for future references.

There is no short cut to achieving quality products when it comes to software testing. Software tools assist in tracking technical and non-technical issues that development teams use to track defects. Testers and developers use emails, spreadsheets, etc. to track defects, but defect tracking tools are a safe alternative to manage these defects efficiently. These automated tools notify testers when a bug pops-up and also provides them with metrics and insights. The type of tools provide insights to testers that enable them to change the codes, tests, and other data that helps them in improving the quality of the software.

Modules of a Defect Management Process

Identify Bugs – Mostly, there are bugs popping-up during the earlier stages of software development. Testers believe that if they fix these errors immediately they can save a lot of time, reduce errors, and help to cut down on costs.

Divide into Different Categories – After detecting bugs, the teams categorize bugs into different types. Development teams then mark each error’s priority and assign bugs to each other for correction.

Set Priorities – This is one of the important modules where developers resolve defects according to their priorities. Teams collaborate to manage these defects efficiently.

Assign Tasks – Too many bugs appearing in a system can be overwhelming for the teams. Thus, a manager assigns tasks categorically to various developers to ensure smooth management.

Resolve & Verify Bugs – It is obvious that developers need to devise a proper strategy to meet these goals and achieve a bug-free software. Thus, they verify defects and provide solutions to resolve these problems.

Report – Management requires reports from time to time once reporting purposes later on.

  A management tool spots and notifies respective developers when a bug requires a fix. The system works as a repository for the documentation of test cases and bugs and adds value for support departments. The system provides a platform to the development team to help them in testing effectively based on the critical insights from the system.

Estas son las nuevas certificaciones en base al VMware vSphere 6.7

ESXi は、PXE でインストーラからブートしてインストールすることができます。

PXE 環境を用意するには、DHCP や TFTP といったサービスが必要です。

ESXi インストーラの PXE ブート

今回は、PXE 環境を Linux と dnsmasq を利用して構築してみます。

dnsmasq は簡易的な DNS サーバとして利用されることが多いですが、

PXE に必要な DHCP サービスと TFTP サービスも提供できます。

今回の環境。

使用するソフトウェアは下記です。

• OS： Oracle Linux 7
• DHCP / TFTP サーバ： OS 標準提供の dnsmasq RPM
• syslinux ブートローダ： OS 標準提供の syslinux-tftpboot RPM

ちなみに、今回の PXE サーバとインストール対象サーバは

VMware Workstation Pro 15 に VM で作成しています。

PXE サーバにする OS の準備。

Linux は、Oracle Linux 7.6 を利用しています。

※ちなみに RHEL や CentOS でも同様の手順で構築可能なはずです。

[root@pxe01 ~]# cat /etc/oracle-release

Oracle Linux Server release 7.6

わかりやすく、ホスト名を変更しておきます。

そして OS にログインしなおしてプロンプトの文字列を変更しておきます。

[root@localhost ~]# hostnamectl set-hostname pxe01

手順を簡略化するため、firewalld は停止しています。

[root@pxe01 ~]# systemctl stop firewalld

[root@pxe01 ~]# systemctl disable firewalld

DHCP / TFTP サーバの構築。

dnsmasq をインストールします。

[root@pxe01 ~]# yum install -y dnsmasq

[root@pxe01 ~]# yum list dnsmasq

読み込んだプラグイン:ulninfo

インストール済みパッケージ

dnsmasq.x86_64                      2.76-7.el7                       @ol7_latest

あわせて、TFTP Boot むけ syslinux ブートローダの RPM（syslinux-tftpboot）も

インストールしておきます。

[root@pxe01 ~]# yum install -y syslinux-tftpboot

[root@pxe01 ~]# yum list syslinux-tftpboot

読み込んだプラグイン:ulninfo

インストール済みパッケージ

syslinux-tftpboot.noarch                 4.05-15.el7                 @ol7_latest

ちなみに、syslinux-tftpboot をインストールすると、下記のように

/var/lib/tftpboot/ ディレクトリ配下にブートローダ関連のファイルが配置されます。

[root@pxe01 ~]# rpm -ql syslinux-tftpboot

/var/lib/tftpboot

/var/lib/tftpboot/cat.c32

/var/lib/tftpboot/chain.c32

/var/lib/tftpboot/cmd.c32

/var/lib/tftpboot/config.c32

/var/lib/tftpboot/cpuid.c32

/var/lib/tftpboot/cpuidtest.c32

/var/lib/tftpboot/disk.c32

/var/lib/tftpboot/dmitest.c32

/var/lib/tftpboot/elf.c32

/var/lib/tftpboot/ethersel.c32

/var/lib/tftpboot/gfxboot.c32

/var/lib/tftpboot/gpxecmd.c32

/var/lib/tftpboot/gpxelinux.0

/var/lib/tftpboot/hdt.c32

/var/lib/tftpboot/host.c32

/var/lib/tftpboot/ifcpu.c32

/var/lib/tftpboot/ifcpu64.c32

/var/lib/tftpboot/ifplop.c32

/var/lib/tftpboot/int18.com

/var/lib/tftpboot/kbdmap.c32

/var/lib/tftpboot/linux.c32

/var/lib/tftpboot/ls.c32

/var/lib/tftpboot/lua.c32

/var/lib/tftpboot/mboot.c32

/var/lib/tftpboot/memdisk

/var/lib/tftpboot/memdump.com

/var/lib/tftpboot/meminfo.c32

/var/lib/tftpboot/menu.c32

/var/lib/tftpboot/pcitest.c32

/var/lib/tftpboot/pmload.c32

/var/lib/tftpboot/poweroff.com

/var/lib/tftpboot/pwd.c32

/var/lib/tftpboot/pxechain.com

/var/lib/tftpboot/pxelinux.0

/var/lib/tftpboot/reboot.c32

/var/lib/tftpboot/rosh.c32

/var/lib/tftpboot/sanboot.c32

/var/lib/tftpboot/sdi.c32

/var/lib/tftpboot/sysdump.c32

/var/lib/tftpboot/ver.com

/var/lib/tftpboot/vesainfo.c32

/var/lib/tftpboot/vesamenu.c32

/var/lib/tftpboot/vpdtest.c32

/var/lib/tftpboot/whichsys.c32

/var/lib/tftpboot/zzjson.c32

dnsmasq に DHCP / TFTP サービス関連の設定をします。vi エディタなどで、

/etc/dnsmasq.conf ファイルの末尾に下記を追記します。

• interface は ens33 としていますが、環境によって eth0 や ens192 といった名前になります。
• dhcp-range は、ESXi インストール対象のマシンが PXE サーバにアクセスする際に利用する IP アドレス レンジを指定します。

interface=ens33

dhcp-range=192.168.163.200,192.168.163.209,6h

dhcp-boot=pxelinux.0

enable-tftp

tftp-root=/var/lib/tftpboot

dnsmasq のサービスを起動しておきます。

[root@pxe01 ~]# systemctl start dnsmasq

[root@pxe01 ~]# systemctl enable dnsmasq

syslinux での PXE 設定ファイルの用意。

pxelinux.cfg ディレクトリを作成します。

[root@pxe01 ~]# mkdir /var/lib/tftpboot/pxelinux.cfg

/var/lib/tftpboot/pxelinux.cfg/default ファイルを、下記のような内容で作成します。

• 「LABEL ESXi67u2」以降には、今回インストールで利用する ESXi 6.7 U2 のメニューを追加しています。
• （必須ではありませんが）メニュー画面の見栄えをよくするために「MENU INCLUDE pxelinux.cfg/pxe.conf」といった設定をしています。

DEFAULT vesamenu.c32

TIMEOUT 800

ONTIMEOUT 1

PROMPT 0

MENU INCLUDE pxelinux.cfg/pxe.conf

NOESCAPE 1

LABEL 1

  MENU LABEL Local Boot

  localboot 0

  TEXT HELP

  Boot to local hard disk

  ENDTEXT

 

LABEL ESXi67u2

  KERNEL /ESXi67u2/mboot.c32

  APPEND -c /ESXi67u2/boot.cfg

  MENU LABEL ESXi67 Update 2 ^Installer

MENU INCLUDE で指定している pxe.conf ファイルは、下記の内容で作成しています。

/var/lib/tftpboot/pxelinux.cfg/pxe.conf

MENU TITLE  PXE Server pxe01

NOESCAPE 1

ALLOWOPTIONS 1

PROMPT 0

menu width 80

menu rows 14

MENU TABMSGROW 24

MENU MARGIN 10

menu color title 1;36;44 #ff008080 #00000000 std

PXE サーバへの ESXi インストーラの配置。

今回は、ESXi 6.7 U2 のインストーラを利用します。

My VMware サイトから、下記のファイルを入手しておきます。

VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso

PXE サーバに ISO ファイルを転送ずみです。

[root@pxe01 ~]# ls -1

VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso

anaconda-ks.cfg

インストーラを /mnt ディレクトリにマウントします。

[root@pxe01 ~]# mount -o loop ./VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso /mnt

mount: /dev/loop0 is write-protected, mounting read-only

TFTP サーバが公開しているディレクトリの配下にディレクトリを作成して、

ISOファイルからファイルをコピーします。

[root@pxe01 ~]# mkdir /var/lib/tftpboot/ESXi67u2

[root@pxe01 ~]# cp -pr /mnt/* /var/lib/tftpboot/ESXi67u2/

通常の CD ブートから PXE ブートに変更するため、boot.cfg ファイルを編集します。

• boot.cfg で指定されているファイル名から、先頭の「/」を削除。
• それらのファイル名の先頭に、TFTP のディレクトリ名をつける。（prefix=ESXi67u2）

編集箇所が多いため、sed コマンドで置換をしています。

[root@pxe02 ~]# sed -i 's|/||g' /var/lib/tftpboot/ESXi67u2/boot.cfg

[root@pxe02 ~]# sed -i 's|prefix=|prefix=ESXi67u2|' /var/lib/tftpboot/ESXi67u2/boot.cfg

インストール対象マシンのパワーオン。

インストール対象となるマシン（VM でも可）をパワーオンすると、

ここまでで設定した PXE Boot のメニューが表示されます。

メニューを選択してブートすると、

通常の ISO ブートとはファイルのパスが変更されていることがわかります。

これで、PXE Boot で ESXi のインストールが開始できるようになり、

このあとは通常どおりインストールを進めることになります。

以上、ESXi を PXE Boot してみる話でした。

前回の投稿では、ESXi のインストールメディアの転送に TFTP を利用しました。

ESXi を PXE Boot でインストールしてみる。（dnsmasq）

https://communities.vmware.com/people/gowatana/blog/2019/05/30/esxi-pxe-tftp

今回は、ESXi のインストーラの転送を HTTP に変更してみます。

ドキュメントでは、下記のあたりです。

Web サーバを使用した ESXi インストーラの PXE ブート

今回の環境。

今回は、前回の投稿で作成した環境を構成変更します。

おもな差分は、赤字の部分です。

• OS： Oracle Linux 7
• DHCP / TFTP サーバ： OS 標準提供の dnsmasq RPM
• syslinux ブートローダ： OS 標準提供の syslinux-tftpboot RPM
• PXE Boot 対象マシンのファームウェア： BIOS
• ESXi インストール メディア： HTTP サーバに配置。Apache HTTP Server（httpd）を利用

PXE 環境の構成変更。

前回の構成では、ブートローダファイル pxelinux.0 を使用していました。

一方 HTTP でのインストールイメージ転送では、HTTP に対応している gpxelinux.0 を利用します。

そこで、DHCP オプションで指定してるファイル名を変更します。

ちなみに、前回利用した  pxelinux.0 のままだと、

下記のように URL を指定した HTTP によるファイルの読み込みができないようです。

今回は dnsmasq の DHCP 機能を利用しているので、/etc/dnsmasq.conf ファイルを編集します。

• 赤字部分が前回からの差分です。
• gpxelinux.0 は、syslinux-tftpboot RPM に含まれています。
• PXE のプロセスでは TFTP を利用するので、TFTP 関連の設定はそのまま残します。

（省略）

interface=ens33

dhcp-range=192.168.163.200,192.168.163.209,6h

dhcp-boot=gpxelinux.0

enable-tftp

tftp-root=/var/lib/tftpboot

dnsmasq のサービスを再起動しておきます。

[root@pxe01 ~]# systemctl restart dnsmasq

前回 ESXi の ISO イメージ ファイルの内容をコピーした

TFTP サーバの公開ディレクトリ /var/lib/tftpboot/ESXi67u2/ には、

ブートで必要な下記のファイル（boot.cfg と mboot.c32）を残します。

[root@pxe01 ~]# ls -l /var/lib/tftpboot/ESXi67u2/

合計 96

-r-xr-xr-x. 1 root root  2713  5月 31 07:34 boot.cfg

-r-xr-xr-x. 1 root root 93288  3月 27 13:47 mboot.c32

そして boot.cfg の prefix を編集します。

編集前（前回のファイル）

[root@pxe01 ~]# cat /var/lib/tftpboot/ESXi67u2/boot.cfg | head -n 4

bootstate=0

title=Loading ESXi installer

timeout=5

prefix=ESXi67u2

編集後

※「192.168.163.149」はESXi のインストーラを配置する HTTP サーバのアドレスです。

[root@pxe01 ~]# cat /var/lib/tftpboot/ESXi67u2/boot.cfg | head -n 4

bootstate=0

title=Loading ESXi installer

timeout=5

prefix=http://192.168.163.149/ESXi67u2

HTTP サーバの用意。

OS 標準提供の Apache HTTP Server の RPM をインストールして、起動します。

[root@pxe01 ~]# yum install -y httpd

[root@pxe01 ~]# systemctl start httpd

[root@pxe01 ~]# systemctl enable httpd

HTTP サーバが起動して、Test Page が参照（HTTP でダウンロード）できるようになります。

※Test Page は Web ブラウザからでも確認できます。

[root@pxe01 ~]# curl -s http://192.168.163.149/ | head -n 3

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

        <head>

                <title>Apache HTTP Server Test Page powered by Linux</title>

ESXi インストールメディアの配置。

HTTP サーバの公開ディレクトリ（デフォルトの /var/www/html）配下に

「ESXi67u2」というディレクトリを作成して、そこに ESXi の ISO ファイルの内容をコピーします。

[root@pxe01 ~]# mkdir /var/www/html/ESXi67u2

[root@pxe01 ~]# mount -o loop VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso /mnt

[root@pxe01 ~]# cp -pr /mnt/* /var/www/html/ESXi67u2/

配置したファイルに HTTP 経由でアクセスできることを確認しておきます。

※Web ブラウザからでも確認できます。

[root@pxe01 ~]# curl -s http://192.168.163.149/ESXi67u2/ | head -n 5

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<html>

<head>

  <title>Index of /ESXi67u2</title>

</head>

PXE Boot での ESXi インストーラ起動の様子。

PXE Boot のメニューで、ESXi インストーラを選択すると・・・

boot.cfg の prefix で指定したアドレスの HTTP サーバから

ファイルが読み込まれていることがわかります。

PXE Boot を利用するような環境では、RPM などの OS パッケージを配置したリポジトリ

（YUM サーバなど）を用意しているケースがあるかなと思います。

ESXi インストーラも HTTP サーバに配置することで、

PXE 環境と、OS & ESXi のリポジトリを分離して管理できそうです。

以上、ESXi インストーラを HTTP サーバに配置してみる話でした。

vCenter upgradation failed 6.0 u3 g to 6.5

Error :-

error vpxd[7F9037595800] [Originator@6876 sub=Main] Init failed. VdbError: Error[VdbODBCError] (-1) "ODBC error: (23503) - ERROR: insert or update on table "vpx_entity" violates foreign key constraint "fk_vpx_ent_ref_vpx_ent_type";

--> Error while executing the query" is returned when executing SQL statement "INSERT INTO VPX_ENTITY (ID, NAME, TYPE_ID, PARENT_ID) VALUES (?, ?, ?, ?)"

--> Backtrace:

This is a known issue affecting upgrades and migration paths from vCenter Server 6.0 Update 3g deployed with embedded Postgres DB to vCenter Server 6.5 and 6.7.

This issue is resolved in vSphere 6.5 Update 2d and 6.7 Update 1

https://kb.vmware.com/s/article/57738

Error:  Import entity task did not return the switch reference

In the vpxd log file see below entry.

2019-01-03T19:05:36.189+02:00 info vpxd[7F4728A3E700] [Originator@6876 sub=vpxLro opID=DvsImportWizard-apply-185-ngc-f0] [VpxLRO] -- BEGIN task-184 -- DVSManager -- vim.dvs.DistributedVirtualSwitchManager.importEntity -- 52aa04b5-47f2-2b57-e603-910e41762f6b(52663238-2c79-fb9d-3c0a-c251cba13f4b)

2019-01-03T19:05:36.190+02:00 error vpxd[7F4728A3E700] [Originator@6876 sub=Default opID=DvsImportWizard-apply-185-ngc-f0]

--> Cannot find version for urn:vpxd3/dev

-->

--> while parsing serialized object of type anyType

--> at line 1, column 0

2019-01-03T19:05:36.194+02:00 warning vpxd[7F4728A3E700] [Originator@6876 sub=UtilEx opID=DvsImportWizard-apply-185-ngc-f0] Failed to load XMLStringConfig N7Vmacore19FileFormatExceptionE(File Format Exception: Duplicate child: uplinkPortName)

--> [context]zKq7AVECAAAAAD8GTwAZdnB4ZAAADJQrbGlidm1hY29yZS5zbwAABE8bAGqXGABP7BcAif4XAHxeGAC8XhgAvF4YAEFkGAEUK3J2c

HhkAAHW5t8Bq0PgAYHd1gEW6NaCk9s/AWxpYnZpbS10eXBlcy5zbwABRJd0AZOPcwEIhXMBl6hzAcj7cwAv4iMAFuUjAPfrKwNUdABsaWJwdGhyZWFkLnNvLjAABC2ODmxpYmMuc28uNgA=[/context];

2019-01-03T19:05:36.196+02:00 error vpxd[7F4728A3E700] [Originator@6876 sub=DvsUtils opID=DvsImportWizard-apply-185-ngc-f0] [DvsUtils::UncompressAndDeserialize]Deserialize failed. backupString corrupted

2019-01-03T19:05:36.198+02:00 error vpxd[7F4728A3E700] [Originator@6876 sub=MoDvsManager opID=DvsImportWizard-apply-185-ngc-f0] [MoDvsManager] Import Failed while creating DVS from Backup with key[19 ca 2b 50 e0 6b a0 3b-cd bf 8c 6e 63 33 6f 52]. Fault:[vim.fault.BackupBlobReadFailure]

2019-01-03T19:05:36.198+02:00 info vpxd[7F4728A3E700] [Originator@6876 sub=vpxLro opID=DvsImportWizard-apply-185-ngc-f0] [VpxLRO] -- FINISH task-184

This is known issue affecting vCenter Server 6.5.

Currently, there is no resolution.

To work around this issue, deploy a temporary vCenter Server 6.0 to import and export the vDS:

1. Create a vCenter Server 6.0 for temporary use.
2. Export existing vDS from vCenter 5.5.
3. Import the vDS to the new temporary vCenter Server 6.0.
4. Export the vDS from vCenter Server 6.0.
5. Import the vDS exported from vCenter Server 6.0 to vCenter Server 6.5.

Refer VMware KB https://kb.vmware.com/s/article/2149769https://kb.vmware.com/s/article/2149769

Problem: Remove EMC PowerPath/VE from ESXi host

Resolution:

1. Login to VMware ESXi host via SSH (Putty)

2. First Check the EMC powerpath/VE is install or not with this command# esxcli software vib list | grep "PowerPath" or esxcli software vib list | grep "EMC"

3.  Now you put the ESXi host in Maintenance mode. # esxcli system maintenanceMode set –enabled=true

4. Make sure ESXI in MM mode before run the below command to remove the PowerPath.

     # esxcli software vib remove --vibname=powerpath.plugin.esx --vibname=powerpath.cim.esx --vibname=powerpath.lib.esx

5.  Now reboot the host to remove completely.

6.  Exit Maintenance Mode on completion of reboot.

    # esxcli system maintenanceMode set –enabled=false

========================================================================================================

Problem: Install EMC PowerPath on ESXi host with below step.

Resolution:

1. Download the latest PowerPath software from EMC portal.

2. Upload the PowerPath software to either ESXi host or any VMware datastore for access the path to install

3. Put ESXi in Maintenance Mode. # esxcli system maintenanceMode set –enabled=true

4. login to ESXi host via SSH (Putty) and run the below command to install PowerPath.

    #esxcli software vib install -d " /vmfs/volumes/datastore/EMCPower.VMWARE...zip"

5. Once installation completed need to reboot to take effect.

6. Exit Maintenance Mode on completion of reboot.

     # esxcli system maintenanceMode set –enabled=false

NSX-T の機能を確認できるように、ネステッド ESXi 環境を利用したラボ環境を構築してみます。

今回は、構築する NSX-T 環境の概要を紹介します。

今回のラボ構成の方針。

現時点で NSX-T に取り組む場合は、新技術のキャッチアップを目的とすることが多いかなと思います。

そこで、ソフトウェアはできるだけ新しいものを利用します。

• NSX-T 2.4.1
• vCenter Server 6.7 U2 / ESXi 6.7 U2

私の自宅ラボには高スペックなマシンがないので、VM 配置／リソース設定に工夫をしています。

• 本当は手軽に物理マシン 1台でネスト環境を構成したいが、スペック不足のため複数台の物理 ESXi ホストを使用。
• VCSA と NSX-T Manager などはリソース割り当てが大きいので、あえてネスト環境よりも外（NSX-T 環境の vCenter より外）に配置。
  • ただし実環境では、これらは NSX-T 環境の vCenter で管理することになるはずです。
• 各 VM の構成／リソース割り当ては、推奨値以下のものもあり。
  • NSX Manager は VM のリソース予約を解除。そしてクラスタ構成ではなくシングル構成にする。
  • NSX Edge は最小のサイズ。
• ネステッド ESXi でのメモリ節約のため、共有データストアは vSAN ではなく NFS にする。

ネットワークまわりの構成は、ラボ目的での環境構築として意図的に下記のような構成としています。

作成するラボでは、主に操作感（GUI / API）、オーバーレイ ネットワーク、ファイアウォール機能を確認するつもりです。

• NSX Edge は、あえてオーバーレイ ネットワークを構成するクラスタとは別のクラスタに配置。
  • これは、NSX Edge 専用のクラスタが必要、というわけではありません。
  • ESXi のトランスポート ノードと、Edge トランスポート ノードとで、搭載する側の ESXi の構成差異を見やすくするため。
• Tier-0 ルータのアップリンク（オーバーレイ ネットワークへの入り口）は管理ネットワークと兼用。
  • NSX 特有のネットワークに入るまでの部分はシンプルにしたかったため。
• Tier-0 ルータではルーティング プロトコルを利用せず、たんにスタティックルートで NSX のネットワークへ。
• オーバーレイの TEP（VTEP）には VLAN ID を付与。
• オーバーレイ ネットワークの、元 / 先 / それ以外、として 3ノードの ESXi を用意。
• NFS データストアの接続は、NSX が構成するネットワークとは直接的に関係しないので、vmk0 の管理ネットワークを兼用。
• オーバーレイ ネットワークで利用する pNIC ポート（ESXi VM の vNIC）はあえて複数構成。
  • アップリンク プロファイルを理解しやすいように複数本（vmnic1 ＋ vmnic2 のような）で冗長化。

※そのうち物理 / 論理構成を分けて、アドレス例も入れてあらためて・・・

実際に構築する NSX-T ラボの様子。

まず、ラボ全体を管理する vCenter の vSphere Client（HTML5 Client）です。

vCenter 6.7 では、基本的にこの vSphere Client を利用します。

物理 ESXi ホストには、vCenter（VCSA）、NSX Manger、NFS サーバ、ESXi VM といったものが配置されます。

それぞれ、役割の想像がしやすそうな VM 名にしてみました。

ここでの「ESXi VM」とは VM に ESXi をインストールしたもの（ネステッド ESXi）で、

通常の ESXi と同様に VM を起動したり、vCenter から管理したりできます。

そして次は、「ネステッド ESXi ＋ NSX-T」環境を管理する vCenter の、vSphere Client です。

上記のスクリーンショットにある lab-esxi-～ という VM は、この vCenter に ESXi として登録してあります。

この環境では、すでに NSX-T との連携がされており、ESXi に「N-VDS」という

NSX-T ならではの特別な仮想スイッチが構成されています。

最後に、NSX Manager の画面です。

これは、上記のスクリーンショットと同じ環境を NSX Manager から見たところです。

NSX for vSphere（NSX-V）では、vSphere Client から NSX の設定をしていましたが、

NSX-T では、NSX Manager が提供する別の UI から、NSX の設定をすることになります。

では、これから下記のような流れでポイントを紹介していこうと思います。

• 土台になる、外側の物理 ESXi ホスト（の vCenter）での設定。
• NSX-T と連携する vCenter（ネステッド ESXi を利用した環境）での設定。
• NSX-T 環境のセットアップ。

つづく。

自宅ラボで NSX-T 2.4 環境を構築する。Part.2

I have attached my written VMware V2V Migration Plan which is attached as reference to help VMware architect/Infrastructure Architect and solution architect to build plan as per their company and customer requirement..

Following are the PowerCLi script to create bulk dvSwitch port groups in vCenter 5.5/6.0/6.5/6.7

1. First create dvswitch in vCenter with any name as per your convenient. For example I created dvswitch with the name of "dvs_Internal" as showed below.

2. Copy the below script in notepad and pest it

3. Modify the vCenter name , dvswitch name where mentioned dvswitch name as "dvs_Internal". Also, change the port group name and VLAN number as per your requirement.

4. save the notepad as example dvPortGroupCreation.ps1

5. Now you can open the VMware vSphere PowerCLI and run the script.

6. it will show the progress of creation the dvport groups in the powercli screen.

7. once script completed you can login to vCenter server via webclient and you can see the new port groups.

Note: This script tested in test/dev/prod environment and working without any issue. 

===========================================================================================================================

    <#

.SYNOPSIS

       Network Configuration

    .DESCRIPTION

          This script Create VM DVPort groups

    .NOTES

        Author: Nawal Singh

    #>

#Connection to vCenter

$mycred = Get-Credential

Connect-VIServer "VCS01.domain.local" -Credential $mycred

Write-Progress -Activity "Creating DvPort Groups" -Status "Working" ;

#This section configures the dvport Groups

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_101" -NumPorts 128 -VLanId 101

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_102" -NumPorts 128 -VLanId 102

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_103" -NumPorts 128 -VLanId 103

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_104" -NumPorts 128 -VLanId 104

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_105" -NumPorts 128 -VLanId 105

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_106" -NumPorts 128 -VLanId 106

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_107" -NumPorts 128 -VLanId 107

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_108" -NumPorts 128 -VLanId 108

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_109" -NumPorts 128 -VLanId 109

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_110" -NumPorts 128 -VLanId 110

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_111" -NumPorts 128 -VLanId 111

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_112" -NumPorts 128 -VLanId 112

Get-VDSwitch -Name "dvs_Internal" | New-VDPortgroup -Name "dPG_VLAN_113" -NumPorts 128 -VLanId 113

Disconnect-VIServer -Server *  -Force -Confirm:$false

===========================================================================================================================

I have attached the procedure the change the VM NIC E1000 to VMXNET3 in VMware environment. If help please comment it.

Note: Downtime is required for this change.

NSX-T の機能を確認できるように、ネステッド ESXi 環境を利用したラボ環境を構築してみます。

ネスト環境として土台になる、外側の vCenter での設定について紹介します。

ここでは、VM の配置と、リソース割り当てについて紹介します。

前回はこちら。

自宅ラボで NSX-T 2.4 環境を構築する。Part.1

前提となるサーバの準備。

まずは、DNS / NTP / NTP / vCenter（VCSA）を用意しておきます。

これらのサーバは、vSphere にとっては、NSX-T を利用するか、ネスト環境であるかどうか

にかかわらず必要であり、特にネスト特有ではない一般的な手順で構築します。

ポイントは、下記のあたりかなと思います。

• DNS サーバには、NSX Manager の 正引き／逆引きの設定（A / PTR レコード）も登録しておきます。
• 共有データストアにする NFS サーバを VM として用意する場合も、ここに配置しておきます。
• VCSA は、最小（tiny）サイズでのデプロイでも NSX-T の動作確認は可能です。

NSX Manager デプロイのポイント。

NSX Manager をデプロイして、起動しておきます。

NSX-T 2.4 の NSX Manager には、従来の NSX Manager と Controller 機能が統合されました。

NSX Unified Appliance という OVA ファイル（ファイル名は nsx-unified-appliance-2.4.1.0.0.13716579.ova）をデプロイします。

NSX Manager および利用可能なアプライアンスのインストール

デプロイ時のポイントは下記かなと思います。

• 「nsx-manager nsx-controller」というロールを選択しておきます。
• 最小サイズは「Cloud Service Manager」むけのもので、NSX Manger のサービスが起動できなくなるので、16GB メモリ / 4 vCPU以上のサイズを選択しておきます。

また、NSX Manager の VM は vCPU / メモリ（vRAM）の割り当てが大きいので、

小規模のラボむけに、リソース予約をあえて解除してから VM を起動します。

ESXi VM 設定のポイント。

ネステッド ESXi にする、ESXi VM の設定についてです。

ESXi VM では、ネステッド ハイパーバイザ上で VM を起動するため、

vCPU で「ハードウェア仮想化」を有効化しておきます。

仮想スイッチとポートグループの設定には工夫が必要です。※次回紹介する予定です。

そして、ESXi は、普通のインストーラ ISO ファイルからインストールします。

次は、土台になる外側の vCenter での、ネットワーク設定における工夫について紹介します。

つづく！

Hello All,

Below are the powercli script to help to deploy bulk blank virtual machines quickly instead of create manually.

=====================================================================================================================

<#

.SYNOPSIS

        Citrix VMs Shell Creation

    .DESCRIPTION

        This script is for Deploy Multiples Blank Virtual Machines Shells for Citrx VMs which are streaming from Gold Image

    .NOTES

        Author: Nawal Singh

  Date: 03/05/2019

    #>

#Connection to vCenter

$mycred = Get-Credential

Connect-VIServer "vcs01.domain.local" -Credential $mycred

Write-Progress -Activity "Deploying VM's" -Status "Working" ;

New-VM -VMHost "vSphere_ESX_01.domain.local" -Name VMCTX01 -Datastore VMFS_DS_01 -NumCpu 6 -MemoryGB 16 -DiskGB 20 -DiskStorageFormat Thin -PortGroup PG_VLAN_101  -Floppy -CD -location Citrix -GuestId windows7Server64Guest

New-VM -VMHost "vSphere_ESX_02.domain.local" -Name VMCTX02 -Datastore VMFS_DS_01 -NumCpu 6 -MemoryGB 16 -DiskGB 20 -DiskStorageFormat Thin -PortGroup PG_VLAN_101  -Floppy -CD -location Citrix -GuestId windows7Server64Guest

New-VM -VMHost "vSphere_ESX_03.domain.local" -Name VMCTX03 -Datastore VMFS_DS_02 -NumCpu 6 -MemoryGB 16 -DiskGB 20 -DiskStorageFormat Thin -PortGroup PG_VLAN_101  -Floppy -CD -location Citrix -GuestId windows7Server64Guest

New-VM -VMHost "vSphere_ESX_04.domain.local" -Name VMCTX04 -Datastore VMFS_DS_02 -NumCpu 6 -MemoryGB 16 -DiskGB 20 -DiskStorageFormat Thin -PortGroup PG_VLAN_101  -Floppy -CD -location Citrix -GuestId windows7Server64Guest

Disconnect-VIServer -Server *  -Force -Confirm:$false

==========================================================================================================================