Quantcast
Channel: VMware Communities : Blog List - All Communities
Viewing all 5007 articles
Browse latest View live

Time differentiate between ESXi host & NTP Server

$
0
0

  Yes exactly, another post about NTP service and important role of time synchronization between virtual infrastructure components. In another post i described about a problem with ESXi v6.7 time setting and also talk about some of useful CLIs for the time configuration, manually ways or automated. But in a lab scenario with many versions of ESXi hypervisors (because of servers type we cannot upgrade some of them to higher version of ESXi) we planned to configure a NTP server as the "Time Source" of whole virtual environment (PSC/VC/ESXi hosts & so on).

   But our first deployed NTP server was a Microsoft Windows Server 2012 and there was a deceptive issue. Although time configuration has been done correctly and time synchronization has occurred successfully, but when i was monitoring the NTP packets with tcpdump, suddenly i saw time shifting has been happened to another timestamp.

   ntp-problem .PNGntpconf.PNG

At the first step of T-shoot, i think it's maybe happened because of time zone of vCenter server (but it worked correctly) or not being same version of NTP client and NTP Server. (to check NTP version on ESXi, use NTP query utility: n

tpq --version) and also change ntp.conf file to set exact version of NTP. (vi /etc/ntp.conf and add "version #" to end of server line) But NTP is a backward compatible s

ervice as and i thought it's not reason of this matter.

So after more and more investigation about cause of the problem, we decided to change our NTP server, for example a Mikrotik router Appliance. and after initial setup and NTP config on the

Mikrotik OVF, we changed our time source. So after setting again the time manually with "esxcli hardware clock" and "esxcli system time" configure host time synchronization with NTP. Initial manual settings must be done because your time delta with NTP server must be less than 1min.

  ntpdsvc.PNG

Then after restart NTP service on the host ( /etc/init.d/ntpd restart) i checked it again to make sure the problem has been resolved.

ntp-check2.PNG

link of post in my personal blog: Undercity of Virtualization: Time differentiate between ESXi host & NTP Server


Using the Okta RADIUS Agent for VMware Horizon

$
0
0

In this blog we are going to discuss adding Multi-Factor Authentication using Okta Verify with VMware Horizon by leveraging the Okta Radius Agent.

For more information on this integration, please see https://www.okta.com/integrations/mfa-for-virtual-desktops/vmware/

 

We are going to walk through 3 separate deployment options to leverage the Okta Radius Client:

 

  1. Using Workspace ONE Access (formerly known as VMware Identity Manager)
  2. Using Unified Access Gateway (UAG)
  3. Using Horizon Connection Servers

 

Let's start with installing and configuring the Okta Radius Agent.

 

Installing the Okta Radius Agent

For detailed instructions please see: https://help.okta.com/en/prod/Content/Topics/Directory/Agent_Installing_the_Okta_Radius_Agent.htm

 

  1. Download the Okta RADIUS Agent from the Okta Admin Portal by going to Settings -> Downloads
    Screen Shot 09-06-19 at 03.11 PM.PNG
  2. Once downloaded, launch the installer.
  3. On the intro screen, click next
  4. Click Next accept the license agreement:
  5. Select the correct installation patch and click Install.
  6. Create a Secret that will be used when configuring the radius clients.
    Screen Shot 09-06-19 at 03.13 PM 003b.png
  7. If you require a proxy complete this section otherwise click next
  8. Click Next
  9. Enter your tenant name (Note: Do not enter the full URL) with the appropriate instance
    Screen Shot 09-06-19 at 03.19 PM 001.PNG
  10. You will be redirected to your Okta tenant to Authenticate
    Screen Shot 09-06-19 at 03.19 PM.PNG
  11. Click Allow Access
    Screen Shot 09-06-19 at 03.20 PM.PNG
  12. You can then complete the installation.

 

Configure the Okta Radius Agent

 

The configuration for the Okta Radius Agent will be done within the Okta Admin Portal

 

  1. Click on Applications -> Applications
  2. Click New Application
  3. Search for "VMware Horizon View (RADIUS)" and Click Add
  4. Click Next
  5. Enter the UDP Port (1812)
  6. Enter the radius secret you used previously
  7. Select the correct username to match your environment.
    This is a very important step. For an optimal user experience, this should match your horizon credentials. If you have multiple AD domains in your horizon environment this should include the domain (ie. UPN or EMAIL).
  8. Click Done
  9. Click on the VMware Horizon View (RADIUS) application.
  10. Click Edit for the Advanced Radius Settings
  11. If you want to enable PUSH Notification, make sure the top two boxes are checked

 

Using Workspace ONE Access (formerly known as VMware Identity Manager)

 

  1. In the Workspace ONE Access Admin Console, go to Identity & Access Management -> Setup -> Connectors
  2. Click on your Worker to edit your connector configuration
  3. Click on Auth Adapters
  4. Click on the Radius Auth Adapter
  5. This will launch a configuration page running on your connector server.
    You will need connectivity to your connector server to complete this step.
    If you are presented an access denied page you might need to temporary change your policy to Password.
  6. Add your Radius Server Host name, Port and Shared Secret. (Leave the Authentication Type as PAP)
    Screen Shot 09-10-19 at 10.08 AM.PNG

  7. Click Save
  8. Return to the WS1 Access Admin Console and verify the Radius Auth Method is enabled. (You might need to refresh)
  9. Go to Identity & Access Management
  10. Click on Identity Providers
  11. Click on your Built-In Identity Provider
  12. Under Connector Authentication Methods, select Radius (Cloud Deployment)
  13. Click Save
  14. Click on Policies
  15. Edit your appropriate policy to include "Radius (cloud deployment)". In my example, I'm modifying the Win10 rule in the Default Policy.
    Screen Shot 09-10-19 at 10.15 AM.PNG
  16. Click Save, Next and Save.
  17. Open an Incognito Window and we'll test the configuration
    Note: If you ever lock yourself out, you can always go to: https://[TENANT].vmwareidentity.com/SAAS/auth/0 to login using your System Domain Account.
  18. You will be prompted to enter your Okta Credentials
  19. You should be prompted to approve the authentication on your Okta Verify Application
    Apowersoft_Screenshot_2019_09_10_13_30_12.jpg

Using Unified Access Gateway (UAG)

 

In environments where a Unified Access Gateway is deployed, most customers will typically want to configure MFA here as this appliance typically sits on the network edge. We can configure UAG to prompt for MFA using Okta Verify and then pass the credentials to Horizon to complete the authentication into the view client.

 

Note: If you have multiple AD domains, you will need to ensure your login through Okta contains the domain name (ie. UPN/Email).

 

  1. Log into your UAG Admin Console
  2. Under Authentication Settings, click the gear icon for RADIUS
  3. Enable RADIUS, Select PAP and enter the host name and port for the Okta Radius Agent.
  4. Click Save
  5. Expand Edge Service Settings and edit the Horizon Settings
  6. Click on "More" (at the bottom)
  7. Under Auth Methods, select radius-auth
  8. You will also need to enable "Enable Windows SSO" to prevent a subsequent login into the horizon client.
  9. Click Save
  10. Test your configuration by logging into the Horizon Portal. You will be prompted for your Okta username and password
    Screen Shot 09-10-19 at 02.09 PM.PNG
  11. You will then be prompted to approve the Okta Verify request on your device.

 

 

Using Horizon Connection Servers

 

Radius can be configured directly on the Horizon Connection Servers. This allows for MFA to be configured for both internal and external users (assuming internal users are not going through UAG).

 

Note: If you have multiple AD domains, you will need to ensure your login through Okta contains the domain name (ie. UPN/Email).

 

  1. Log into your Horizon Admin console
  2. Edit your Connection Server Settings
  3. Under Advanced Authentication, select Radius
  4. Select "Use the same username and password for RADIUS and Windows Authentication
  5. On the Authenticator drop down, select Create New Authenticator
  6. Enter your host name, port and secret for the Okta Radius Agent
    Screen Shot 09-10-19 at 01.41 PM.PNG
  7. Click OK
  8. Click OK.
  9. Test your configuration by logging into the Horizon Portal. You will be prompted for your Okta username and password
  10. You will then be prompted to approve the Okta Verify request on your device.

Migrate External PSC Deployment to Embedded PSC deployment Using Converge Tool

$
0
0

Here is the brief description of how Convergence tool works.

 

Converge Tool can migrate an External Deployment PSC to an Embedded deployment PSC,  it also has the ability to decommission the external PSCs after the migration.

 

Note: Your vCenter components must be upgraded to 6.7 Update1 appliance.

 

diagram.png

 

 

Prerequisites

 

1.Disable VCHA if its enabled on 6.5.

2.Reduce\disable DRS automation level.

3.Take the VMware snapshots for all vCenter components, if possible go for VCSA backup also

4.remove the secondary nic if its assigned before the upgrade

 

 

Using Tool:

 

Step 1-VCSA 6.7 Update 1 ISO will have the vcsa-convergence-cli tool so mount the ISO any windows/Linux machine.

 

   diagram1.png

Here converge folder will have converge JSON file and decommission folder will have decommission JSON file.

 

Step 2- Expand the vcsa-converge-cli directory and go to templates. Open the converge directory and copy the converge.json file to your local machine.

 

Step 3– open the converge JSON file in your fav editor and looks as below

  diagram2.png

 

Step 4 - Fill out the fields as below and save the file .

  1. Information about the Managing vCenter or ESXi Host.
  2. Information about the vCenter Server you wish to Converge to Embedded.
  3. (Optional) Active Directory Information if you wish to join the Embedded vCenter to AD.
  4. (Optional) please mention the other external PSC if you have .

  Step 5 :from CMD prompt run vcsa-converge-cli\win32>vcsa-util.exe converge –no-ssl-certificate –verbose C:location of your .json file and run

diagram3.png

 

Step 6: VCSA converged to  embedded PSC successfully .

diagram4.png

Verify the vCenter with Embedded platform service control from the VAMI page.

Note:   Before we head on to decommission please make sure there are no VCSA associated with external PCSs that you are going to decommission .

Decommissioning Steps:

Step 1: copy the decommission JSON file to the local machine and fill out the required field

  1. fill Information about the Managing vCenter or ESXi Host of the External PSC.
  2. Information about the Platform Services Controller you wish to Decommission.
  3. Information about the Managing vCenter or ESXi Host of an Embedded vCenter in the SSO Domain.
  4. Information about the Embedded vCenter in the SSO Domain.

 

Here is the screen shot reference .

diagram5.png

 

Repeat the above steps for second PSC if you have.

 

This completes the VCSA convergence .

VMware KNOWLEDGE SKILLS ASSESSMENT

$
0
0

1.png

Fill in the form to get this free assessment to help you determine the level of your organization's staff and provide you with a course plan to develop their skills.

Knowledge Skills Assessment

vSphere Distributed Switch Design & Configuration - Part I: Create & Basic Setup

Duo security integration with vCloud director 9.5.0

$
0
0

We used the following ones,

 

Summary:-

 

Identity provider:- AD only. ADFS is not required. We just need to create users in AD with email I’d.

 

Service provider;- vcloud director 9.5.0

 

DAG;- This is linux Duo access gateway enables two factor authentication. Here authentication source has been set as AD.By default, it will provide xml file, we just need to download this xml file and need import in vcloud director saml federation. Also you need to import JSON file here(This will be taken from duo admin console)

 

Duo admin console;-we need to create a new service provider in which service provider name,SAML entity name,ACS, SSO login, logout should be defined. Here  in the DUO admin console,the saml response mentioned as "Email  Address". After providing this information, you need to save the service provider configuration also you can get JSON file.

 

Note:-

vCloud director provider portal and tenant portal customization:-

As you are aware,there are two portals available for both provider and tenant(flash and HTML).

 

VCD provider portal:- No much options customized yet(for VCD 9.5.0 SP) from provider portal(HTML)"https://VCD url/provider" but still can able to change the SAML entity id using HTML.At the same time,there is no option available to change the SAML entity id using Flash.

 

In AD user properties, we need to set the email I’d and also in vcloud director user section(import SAML users), we need to import user with the given email id(Saml) as “rr@example.com”.

 

This setup will work very well.

 

Happy learning!

 

Cheers,

Manivel RR

ESXi server integration issue with vCenter server 6.5.0.

$
0
0

ESXi server integration issue with  vCenter server 6.5.0.

 

vCenter-->It has NAT IP address and located in one country(US1)

ESXi---> It also has NAT IP address and located in another country(TOR)

 

Issue 1:-

 

Error in vCenter while connecting the ESXi host:- A general system error has occurred: Timed out waiting for vpxa to start".

ESXi host error:- VPXA service got stopped after 19 seconds(whenever we restart).There was no VPXA log recorded in VPXA.log.

In addition,we found this error in cat /var/log/syslog.log  error  "/etc/vmware/vpxa' exited after 19 seconds (quick failure 1) 134"

 

 

Reference :-  https://communities.vmware.com/thread/602035

 

 

We removed the / from <serverIP> & <serverPort> in the beginning of VPXA configuration and taken vpxa start.It resolved this VPXA service start issue without ESXi reboot.

Note:- Previoulsy it was  <serverIP/> & <serverPort> in the VPXA configuration,

 

 

Issue 2 :-

 

 

After VPXA service fix,we had connectivity issue again with vCenter server(frequent ESXi disconnect with vCenter).We increased the VPXD timeouts in vCenter server web client "config.vpxd.heartbeat.notRespondingTimeout" to 120 seconds as per the below given article.

 

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

 

 

Issue 3:-

 

 

After timout increase to 120 seconds in VPXD configuration,we had connectivity issue again with vCenter server(frequent ESXi disconnect with vCenter every 120 seconds.I.e, 2 minutes)...

At the same time,in the VPXA config "<serverIp>209.x.x.x</serverIp>"it started changed automatically to vCenter private address even though we add in vpxa.cfg.

 

 

This happened because of all the ESXi servers are behind NAT public IP address.

 

 

Fix:-

1) We added this line in vpxa.cfg "<preserveServerIp>true</preserveServerIp>"

2) We added the vCenter  NAT public IP address in vpxa.cfg "<serverIp>209.x.x.x</serverIp>"

3) And we created a new vmkernel port group(with new vSwitch and no VLAN,no nic binding needed) with ESXi NAT public IP address.

 

This fixed the issue.

 

Reference articles:-

http://austit.com/faq/306-vsphere-esxi-behind-nat-vcenter-connection

https://communities.vmware.com/thread/567799

 

 

VPXA error in all the three ESXi servers:-

 

 

Failed to bind heartbeat socket for host address  Cannot assign requested address

Failed to bind heartbeat socket for host address 207.x.x.x: Cannot assign requested address

 

 

Modified VPXA configuration in ESXi servers.

 

 

<vpxa>

    <bundleVersion>1000000</bundleVersion>

    <datastorePrincipal>root</datastorePrincipal>

    <hostIp>207.x.x.x</hostIp>

    <hostKey>52a8daca-2271-6aa9-9f25-debb1f910e05</hostKey>

    <hostPort>443</hostPort>

    <licenseExpiryNotificationThreshold>15</licenseExpiryNotificationThreshold>

    <memoryCheckerTimeInSecs>30</memoryCheckerTimeInSecs>

    <preserveServerIp>true</preserveServerIp>

    <serverIp>209.x.x.x</serverIp>

    <serverPort>902</serverPort>

 

Happy learning

 

Cheers,

Manivel R

Could not integrate the ESXi host in to vCenter server.

$
0
0

Issue:-Could not integrate the esxi host in to vCenter server.

vCenter version :- 6.5 and ESXi version:- 5.5.0 U3

 

 

Error in vCenter while connecting the ESXi host:- A general system error has occurred: Timed out waiting for vpxa to start".

ESXi host error:- VPXA service got stopped after 19 seconds(whenever we restart the VPXA service).There was no VPXA log recorded in VPXA.log.All were the year 2018 logs only.

In addition,we found this error in cat /var/log/syslog.log  error  "/etc/vmware/vpxa' exited after 19 seconds (quick failure 1) 134"

 

 

2019-08-25T08:58:01Z watchdog-vpxa: [626526] Begin '/usr/lib/vmware/vpxa/bin/vpxa ++min=0,swapscope=system,group=vpxa -D /etc/vmware/vpxa', min-uptime = 60, max-quick-failures = 1, max-total-failures = 1000000, bg_pid_file = ''

2019-08-25T08:58:20Z watchdog-vpxa: '/usr/lib/vmware/vpxa/bin/vpxa ++min=0,swapscope=system,group=host/vim/vmvisor/vpxa -D /etc/vmware/vpxa'

exited after 19 seconds (quick failure 1) 134

2019-08-25T08:58:20Z watchdog-vpxa: Executing '/usr/lib/vmware/vpxa/bin/vpxa ++min=0,swapscope=system,group=host/vim/vmvisor/vpxa -D /etc/vmware/vpxa'

2019-08-25T08:58:40Z watchdog-vpxa: '/usr/lib/vmware/vpxa/bin/vpxa ++min=0,swapscope=system,group=host/vim/vmvisor/vpxa -D /etc/vmware/vpxa' exited after 20 seconds (quick failure 2) 134

2019-08-25T08:58:40Z watchdog-vpxa: End '/usr/lib/vmware/vpxa/bin/vpxa ++min=0,swapscope=system,group=vpxa -D /etc/vmware/vpxa', failure limit reached

 

 

VPXA.cfg <IoMax>9</IoMax>

      <TaskMax>4</TaskMax>

      <ThreadStackSizeKb>512</ThreadStackSizeKb>

      <threadNamePrefix>vpxa</threadNamePrefix>

    </threadPool>  </vmacore>

   <vpxa>

   <bundleVersion>1000000</bundleVersion>

    <datastorePrincipal>root</datastorePrincipal>

    <hostIp>ESXi private IP address</hostIp>

    <hostKey>52f0fc0c-3058-bc0d-4338-40dd3a1abea2</hostKey>

    <hostPort>443</hostPort>

    <licenseExpiryNotificationThreshold>15</licenseExpiryNotificationThreshold>

    <memoryCheckerTimeInSecs>30</memoryCheckerTimeInSecs>

    <serverIp>VC private IP address</serverIp>

    <serverPort>902</serverPort>

  </vpxa>  

Steps followed to resolve this issue:-

1st step:-Taken ESXi reboot but not resolved this issue.

2nd step:- We removed the / from <serverIP> & <serverPort> in the beginning and taken vpxa start.It resolved the issue without ESXi reboot.

Note:- Previoulsy it was  <serverIP/> & <serverPort>

 

 

Now the ESXi server got integrated in to vCenter server and vpxa service is stable.

 

Happy learning!

 

Cheers,

Manivel R


VMware VDI (Horizon View) Troubleshooting - Part I

$
0
0

Usually we think it's so easy to change most of the server's name! Just a little configuration changes like editing FQDN value maybe destroy all of your configuration and setting. It's going to sounds like a disaster if you change computer name/account of a server without any consideration or checklist about how to do it. But sometimes you may be wrong in initial server name configuration and after service setup and startup, then you will understand what's happened (forget to change the default name or choose a suitable name based on your design worksheets). Now let's check this matter about a VMware Horizon View Connection Server. First of all you should answer some of questions like:

    1. What should we do if we need to change computer account?

   2. What will happen if we change computer account?

   3. What should we do as the post-execution after renaming the server?

As the first step, you have to review the service documentary specially troubleshooting documents. Then investigate side effects in your virtual desktop infrastructure objects like desktop pools or provided and in-used virtual desktops. Naturally none of them cannot connect to the server anymore, especially if you change the primary connection server nor any of replica servers. As the best and safest way to configure server after renaming it, you can uninstall VMware Horizon 7 Connection Server component (and also HTML Access) and install it again without any concern about losing VDI data and structure. Because there is another important application on provisioned connection server: AD LDS Instance VMware VDMDS that as it's name demonstrate, it's the directory service for VMware VDI suite and is a separated component from Horizon View Connection Server

So let me explain about structure of Horizon View. It's fundamental is based on Lightweight Directory Access Protocol (So you cannot install this service on a domain controller). View LDAP is a data repository and consists of all of it's configuration information and it will be created when you install the first View connection server. This repository will be replicated to other View replica servers. Like other LDAP service it has some partitions, objects and attributes of objects and can be edited by ADSIEdit, just remember if you want to do it, type the Distinguished Name like :

dc=vdi, dc=vmware, dc=int

And then you can find connection server object on these Sub OUs: 'Properties\Server' and 'Properties\LVM\Server'.

The second way to check and change VDI configurations on connection servers is doing by windows registry editor. You can see related path (HKLM\ Software\ VMware, Inc.\VMware VDM) about Horizon View on second picture:

  But regardless of these two rough and dangerous methods, VMware recommended vdmadmin CLI for troubleshooting of Horizon View (note using regedit is not a suitable way). If you refer to following path you can also see other useful CLI like vdmexport and vdmimport:

%ProgramFiles%\ VMware\ VMware View\ Server\ tools\ bin\

Absolutely we know all of gathered information from each of these troubleshooting methods must be same, for example if you check the system GUID , all ways must return the same value:

  Reinstalling the connection server component is the fastest and easiest way, but if risks assessment and information security policies of your organization prevents you from that, now what method you will Choose to reconfigure your virtual desktop infrastructure servers? We will review more about Horizon View troubleshooting on another parts of this series.

  Source of content on my personal blog: https://virtualundercity.blogspot.com/2019/02/vmware-vdi-horizon-view-troubleshooting.html

【VxRail】既存環境からvSAN 環境へのMigration:その① 【イントロダクション】

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

 

 

Dell EMCではVxRailというHCI製品のサポートを初めて1年以上が経ちますが、ずっと疑問だったことがあります。

本記事のタイトルにもなっている、

 

 

 

どうやって既存のVMware環境からVxRailにVMを移行しているのか?

 

 

 

ということです。

 

 

常識的に考えればvMotionをすればいいだけなのですが、VxRailのお客様は、多くの場合VxRailに同梱される無償の内部vCenterを利用しており、それに起因する2つの制限のため簡単に既存環境からvMotionをすることができません。

 

 

 

その制限とは、

1.拡張リンクモードを使用できない  (= Cross vCenter vMotion不可)

2.当該VxRail Cluster外のESXi ホストを管理できない  (= 通常のvMotionによる移行も不可

というものです。

※制限事項にはコチラのガイドから参照いただけます。

 

 

 

要するに無償の内部vCenterを利用した構成の場合は、管理の面でほかのVMware仮想環境から独立していなくてはならず(一元管理不可)、vSphereの機能を用いたvMotionはできないということになります。

 

 

 

外部ストレージ(NFS or iSCSI)を用いたCold Migration(仮想マシンのダウンタイムを伴う)であれば可能ですが、大規模なVMの停止を調整するのは難しいと思われますし、仮想マシンのネットワークアダプタの付け替えなども必要になるので作業としても負荷が高くなります。

 

 

 

別途Replication Solution (RP4VMやvSphere Replication/SRM)を利用した移行も可能ですが、こちらの場合でもやはり一時的な仮想マシンの停止が発生してしまいます。

 

 

 

もちろん(お客様提供の)外部vCenterを利用すればこの制限はないのですが、コストと管理不可を最小限に抑えたいというお客様であれば、多くの場合は内部vCenterをご利用されると思います。

 

※ちなみにですが、内部vCenterから外部vCenter構成に移行することは可能なので、VMの移行の時だけ外部vCenter構成にしてしまえばよい、と考えられるかもしれませんが、残念ながら現状では外部vCenterから内部vCenterへの移行はサポートされていません。

 

 

一応Dell EMCの有償サービスリストの中には、既存環境からのVM 移行に相当するサービスがあるのですが、購入されたという話は聞きません。

 

※どうやって移行するのか詳細を調べてみましたが、Onlineで実施可能なサポートされた手法についての有力な情報は得られませんでした。

 

 

過去にはコチラの記事で、非公式ながらも実現可能な移行方法が説明されていましたが、トラブルの際はサポートを受けられないため、実施に踏み切る例は少ないのではないでしょうか。

 

 

VxRailはこのような背景があるため、既存環境からの移行はかなり厳しい状況だと思っていたのですが、つい先日以下の公式文書を発見しました。

 

・Migrating to vSAN

https://storagehub.vmware.com/export_to_pdf/migrating-to-vsan

 

こちらの文書によると、なんとVxRailと同じ制限がある環境であってもサポートされた手法にて移行が可能になっていました。

以下のブログによると、PowerCLI 6.5 R1よりMove-VM コマンドレットの機能が強化されたことにより可能になったようです。

 

https://blogs.vmware.com/PowerCLI/2017/01/spotlight-move-vm-cmdlet.html

 

 

 

実際のところコマンドレットの強化は1年以上前で、文書の初版公開も昨年の10月なので ”いまさら”感の濃い内容にはなりますが、

VxRail環境へのVM移行についてPowerCLIのInstall(その②)から実際の移行手順(その③)まで検証環境での実施内容を紹介します。

 

 

次回と次々回のリンクは以下です。

 

既存環境からvSAN 環境へのMigration:その②  【PowerCLIのInstall】

既存環境からvSAN 環境へのMigration:その③ 【既存環境からのvMotion】

続・既存環境からvSAN 環境へのMigration【実環境向けのコマンド考察】

【VxRail】既存環境からvSAN 環境へのMigration:その② 【PowerCLIのInstall】

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

 

前回のイントロに続いて、本記事では既存環境からVxRailへのVM移行に必要となるVMware PowerCLIをInstall手順を説明します。

現行のvSphere Web Clientでは共通のSSOドメインを持たない(拡張リンクモードでない)他のvCenterへのCross vCenter vMotionを実施することはできません。

そのため、VMware PowerCLIで実施する必要があります。

 

前回および次回のリンク

既存環境からvSAN 環境へのMigration:その① 【イントロダクション】

既存環境からvSAN 環境へのMigration:その③ 【既存環境からのvMotion】

続・既存環境からvSAN 環境へのMigration【実環境向けのコマンド考察】

 

 

=========  Install 前提条件 ===========

VMware PowerCLIのVersionは6.5 R1以上である必要があります。本手順では投稿時の最新であるVMware PowerCLI 10.1.1のInstallを想定しています。

Windows OS環境に最新のVMware PowerCLIをインストールするためにはWindows PowerShell のVersion 3.0以降である必要がありますが、5.1 までUpgradeされていることを前提としています。

 

Windows PowerShell 5.1は WMF 5.1の Installerに含まれていますので.Net framework 4.5をInstallしたのち、お使いのOS Versionに合わせたWMF Installerよりインストールしてください。(要 Reboot)

 

参考:Installing Windows PowerShell | Microsoft Docs

 

 

 

========= VMware PowerCLI Install 手順 ===========

 

1.Windows PowerShellの起動

 

※管理者モードで起動してください

 

1.png

 

 

2.Version確認

$PSVersionTableコマンドを実行してVersionが5.1であることを確認してください。

 

 

2.png

 

 

3.スクリプトの実行を許可

以下のコマンドを実行してスクリプトの実行を許可してください。

Set-ExecutionPolicy RemoteSigned

 

※クリックして画像を拡大してください

3.png

 

 

4.PowerCLIのダウンロードをインストール

参考:https://www.powershellgallery.com/packages/VMware.PowerCLI/10.1.1.8827524

 

Windows PowerShellにて以下のコマンドを実行してください。

 

Install-Module -Name VMware.PowerCLI -AllowClobber

 

※そこそこ時間がかかります。なにも動いていないように見えてもエラーになるかコマンドが返ってくるまでは放置してください。

 

※クリックして画像を拡大してください

4.png

 

 

5.PowerCLIの起動

Installが終わったらPowerCLI Moduleを読み込んでPowerCLIを起動してください

コマンドは以下です。

 

Import-Module VMware.PowerCLI

 

最初に起動したときにCEIPへの参加を是非を聞かれるのでコマンドを実行して設定すれば以後は出なくなります。

 

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

 

※クリックして画像を拡大してください

5.png

 

 

6.セキュリティ警告を無視に設定する

参考:http://kwmtlog.blogspot.com/2018/03/Set-PowerCLIConfiguration.html

 

以下のコマンドを実行して警告を無視にしてください。

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Scope AllUsers

 

 

7.タイムアウト値を無限にする(Option)

PowerCLIではデフォルトで300秒のタイムアウト値が設定されていますが、少し大きめの仮想マシンであれば容易に5分以上かかってしまいます。

次回に紹介する-RunAsyncオプションを利用すれば、バックグラウンドでの実行となるためタイムアウト値は関係ありませんが、移行の順番などを明示的に管理したい場合はフォアグランドでの実行が好ましい場合があるかもしれません。

その場合は以下のコマンドを利用してタイムアウト値を-1 (無期限)にしてください。

 

Set-PowerCLIConfiguration -WebOperationTimeoutSeconds -1 -Scope AllUsers

 

 

 

今回はPowerShellのInstall方法を紹介しました。

次回は実際に既存のVMware環境からVxRail環境へvMotionをします。

【VxRail】既存環境からvSAN 環境へのMigration:その③ 【既存環境からのvMotion】

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

本記事ではPowerCLIのMove-VMコマンドレットを利用したVM移行について紹介します。

 

前回と前々回の記事は以下です。

 

既存環境からvSAN 環境へのMigration:その① 【イントロダクション】

既存環境からvSAN 環境へのMigration:その②  【PowerCLIのInstall】

 

 

 

前回まででPowerCLIのInstallは完了していますのであとは実際にコマンドレットを発行してvSAN ClusterであるVxRailに既存環境からVMを移行します。

 

イントロダクションの記事でも説明しましたが、VxRailを想定しているため、今回は以下の環境での移行を想定しています。

  • 既存および新規(VxRail)環境のそれぞれで独立したvCenterを持つ
  • それぞれのvCenterはSSO ドメインを共有していない(拡張リンクモードでない)
  • 共有ストレージがない

 

0.PNG

    ※こちらの図は以下の資料より抜粋しています。

・Migrating to vSAN

https://storagehub.vmware.com/export_to_pdf/migrating-to-vsan

 

 

 

 

移行の際はMove-VMコマンドレットを使用します。具体的な使用方法は上記の資料、および以下のBlogにも載っています。

 

・VMware PowerCLI Blog

https://blogs.vmware.com/PowerCLI/2017/01/spotlight-move-vm-cmdlet.html

 

 

 

もっと簡単に参照する方法として、PowerCLIからMove-VMのコマンドヘルプを見る方法があります。

 

    Get-Help Move-VM -full

 

    ※クリックして画像を拡大してください

0-1.PNG

 

 

上図のヘルプからもわかるようにPowerCLIで実施するのは以下です。

  • 既存環境のVCにログイン
  • 新規環境(VxRail)のVCにログイン
  • 移行対象VMのObjectを取得($vm)
  • 移行先のホストObjectを取得($destination)
  • 移行対象VMのネットワークアダプタ(vNIC)のObjectを取得($networkAdapter)
  • 移行先のdvportgroup のObjectを取得($destinationPortGroup)
  • 移行先のvSAN データストア Objectを取得($destinationDatastore)
  • ↑で入手したObjectを指定して、Move-VMコマンドレットを実行

 

 

では実際の例を紹介します。

 

 

 

まずはGet-Credential コマンドレットを使って、VCにログインする認証情報を$creとして保存します。

コマンドを実行するとポップアップが出るので認証情報を入力してください。

※今回の例では既存VCと新規VC(VxRail)で同じ認証情報を利用しています。異なる場合は別々に保存してください

 

    $cre = Get-Credential

1.PNG

 

 

 

 

 

 

認証情報を保存できたら、Connect-VIServer(もしくはGet-VIServer)コマンドレットを利用して両VCにログインします。

-Credential オプションで先ほど保存して認証情報を引数として渡します。

 

    Connect-VIServer -Server  <vCenter FQDN> -Credential $cre

   

2.PNG

 

 

 

 

 

 

 

両VCにログインできたら既存環境のVMから移行対象のVMを探します。

下記の例ではVM 名に joeを含むVMの一覧の中から、一つのVMを指定して$vmに格納しています。

 

    Get-VM -Server non-vxrailVC -Name *joe*

    $vm = Get-VM -Server non-vxrailVC -Name *joe*

 

3.PNG

 

 

 

 

 

次に移行先となる新規環境(VxRail)クラスタの中から移行先ESXiを指定します。

以下の例ではhostnameに 01 を含むESXiを指定しています。

 

    $destination = Get-VMHost -Server vxrailVC -Name *01*

 

 

 

 

 

 

次に移行対象VMのvNIC情報を取得します。

 

          $networkAdapter = Get-NetworkAdapter -VM $vm

 

 

 

 

次に移行先のVxRail上でvNICが接続されるdvportgroupを指定します。

以下の例ではVxRail上のVDSに存在するPortGroupを列挙して、その中からvCenter~で始まるPortGroupを選んで変数に格納して言います。

 

    Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC)

    $destinationPortGroup = Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC) -Name vCenter*

 

4.PNG

 

 

 

 

 

次に移行先となるvSANデータストアの情報を変数に格納します。

VxRail環境の場合はデフォルトからデータストア名称を変更していない限り同じコマンドで取得可能と思います。

 

    Get-Datastore -Server vxrailVC

    $destinationDatastore = Get-Datastore -Server vxrailVC -Name MARVIN*

 

5.PNG

 

 

 

 

最後にこれまでに取得した情報を利用して移行を開始します。

 

$vm | Move-VM -Destination $destination -NetworkAdapter $networkAdapter -PortGroup $destinationPortGroup -Datastore $destinationDatastore -RunAsync

 

※表示幅の関係で2行に見えるかも知れませんが1行コマンドですのでご注意ください。

資料やヘルプには紹介されていませんが、-RunAsyncオプションを加えることでバックグラウンド実行となりPowerCLI起因でのタイムアウトによってコマンドが失敗することがなくなります。

トラブルシューティングや実行順序を制御したいなどの場合に-RunAsyncオプションを外す場合は、前回(その②)の最後で紹介している方法にてタイムアウト値を無期限に設定してください

 

 

6.PNG

 

 

※実行中のvMotionタスクは移行元(既存環境)のvSphere Webclient、もしくはGet-Taskコマンドレットで確認できます。

 

 

 

 

 

 

 

 

ここまでの例は単一VMの移行でしたがPowerCLIの機能を使えば複数VMをまとめて移行させることができます。

以下の例ではVM名にjoeを含むVMすべてをまとめて移行させる方法の例です。

最初のコマンドで該当するVMの一覧を取得して、二つ目のコマンドで一覧を変数に格納しています。

 

    Get-VM -Server non-vxrailVC -Name *joe*

    $vms = Get-VM -Server non-vxrailVC -Name *joe*

 

7.PNG

 

 

あとは以下のコマンド例でまとめて実施することが可能です。

 

※単一VM移行の例と異なりVMのvNIC情報の取得がLoopの中に含まれているのでご注意ください

 

#移行先ESXiの指定

$destination = Get-VMHost -Server vxrailVC -Name *02*

 

#移行先dvportgroupの指定

Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC)

$destinationPortGroup = Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC) -Name vCenter*

 

#移行先データストアの指定

Get-Datastore -Server vxrailVC

$destinationDatastore = Get-Datastore -Server vxrailVC -Name MARVIN*

 

# ループ開始

foreach ( $vm in $vms) {

$networkAdapter = Get-NetworkAdapter -VM $vm

$vm | Move-VM -Destination $destination -NetworkAdapter $networkAdapter -PortGroup $destinationPortGroup -Datastore $destinationDatastore -RunAsync

}

# ループ終了

 

foreach文は{から}までで一つのセットですが改行を含めていただいて構いません。

以下がforeach文のコマンド実行例のGif動画です。

 

※下記のGIF動画はobama03さんにご提供いただきました。ありがとうございます。

※動画が再生されない場合はクリックしてみてください。

 

vmotion1.gif

 

 

 

 

実行後は以下のようにすべてのタスクがバックグラウンドで並列実行されています。

 

8.PNG

 

 

9.PNG

 

 

 

 

 

 

 

同時にvMotionできる数には制限があるため、制限を超えた分に関してはQueueに入れられ実行を待ちます。

並列vMotionの制限についての詳細は、以下の資料をご参照ください

 

・Migrating to vSAN

https://storagehub.vmware.com/export_to_pdf/migrating-to-vsan

 

 

 

 

今回まで3回にわたって紹介した移行方法は、VxRailだけでなくほかのvSAN環境や非vSAN環境でも使用可能な方法です。

実際の環境で何百台とあるVMを正確に障害なく移行するためにいはPowerCLIにおけるスクリプトの工夫や確認作業が必要となるとは思いますが、移行の基本となる作業を理解いただけたかと思います。

 

これまでは実施が難しかった独立した新規vSAN環境(VxRail)へのVM移行手法が、簡単かつサポートされた形で提供されているのは非常に便利で安心できることなので、ぜひとも活用いただければと思います。

 

 

================  2018/08/24追記 ===================

 

続編を書きました。

続・既存環境からvSAN 環境へのMigration【実環境向けのコマンド考察】

【VxRail】 続・既存環境からvSAN 環境へのMigration【実環境向けのコマンド考察】

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

 

本記事ではPowerCLIのMove-VMコマンドレットを利用したVM移行で使えそうなコマンドについて紹介します。

前回までの記事は以下です。

 

        既存環境からvSAN 環境へのMigration:その① 【イントロダクション】

既存環境からvSAN 環境へのMigration:その②  【PowerCLIのInstall】

既存環境からvSAN 環境へのMigration:その③ 【既存環境からのvMotion】

 

 

本シリーズは、PowerCLIを利用した独立vSAN環境へのvMotionの基礎を紹介するところまでで終わるつもりでしたが、

実際にラボ環境で移行を試したところ、もうちょっと便利で手軽に移行したい!という気持ちになったので複数がてら投稿することにしました。

 

##### 留意事項 ######

本記事で使用する変数(non-vxrailVCやvxrailVC)は前回までで使用した変数を引き継いでいます。

################

 

前回に紹介したコマンドでは以下のことが可能でした。

・単体VMのvMotion

・VM名でフィルターしたVM Listの一括vMotion

 

しかし、実際の移行の現場では単体VMのvMotionを手動で何度も実施するのは手間ですし、

VM名でVMをグループ分けしている環境のほうが珍しいかもしれません。

また、前回紹介した一括vMotionの方法では、複数のVMを単一ホストに移行することしかできず、分散するためには何度かに分けて実行しなくてはいけません。

しかも宛先のPortGroupを指定する必要があるため単体VM or VM group毎に、使用するPortGroupを手動でしらべてコマンドを作らなければいけません。

しかも、複数vNIC/複数PortGroupを使用するVMを考慮していませんでした。

 

まとめると、前回までの内容では以下の欠点がありました。

・一括vMotionする際のVM グルーピングの粒度が雑

・一度に一つのホストしかvMotion先として選べない

・複数vNIC/複数PortGroupを持つVMの移行に対応していない

 

 

上記の欠点を解決するには以下の要素が必要でした。

・使用するPortGroup毎にVMをグルーピングして一括vMotionできるようにする

・宛先となるESXi ホストを分散する

複数vNIC/複数PortGroupを持つVMであってもそれぞれ適切な宛先PortGroupを指定できるようにする

 

 

それでは上記課題を解決するコマンドを見てみましょう。

 

使用するPortGroup毎にVMをグルーピングして一括vMotionできるようにする

 

VMをグルーピングして変数に格納する方法はいくつか考えられます。たとえば

    • VM名に含まれるキーワードでグルーピング
      • $vms = Get-VM -Name *joe*   ※名前にjoeを含むVM一覧を取得
    • VMが所属するフォルダでグルーピング
      • $vms = Get-Folder -Name kaneda | Get-VM ※kanedaフォルダに所属するVM一覧を取得
    • VMが所属するリソースプールでグルーピング
      • $vms = Get-ResourcePool -Name "ESX Agents" | Get-VM  ※ESX Agents リソースグループに所属するVM一覧を取得
    • VMが利用するPortGroupでグルーピング
      • $vms = Get-VDPortgroup -Name vCenter* | Get-VM ※vCenter* ポートグループに含まれるVM一覧を取得

 

その他、HostベースでまとめるためにはGet-VMHostや、クラスタごとにまとめるGet-Clusterを利用した方法が考えられますが、今回の用途に一番適しているのはPortGroupでグルーピングする方法のように思えます。

各VMが単一のvNICしか持たないことが前提であればこれで済む話なのですが、今回は複数vNICやPortGroupをもつVMを対象としていますのでこの方法では不十分です。

例えば以下の要件を満たすVMの一覧を取得したい場合はどうしたらいいでしょうか?

 

・test フォルダに所属している

・vNICを二つ持ちそれぞれ別のポートグループに所属している

・一つのvNICはLAB ポートグループに所属している

・もう一つのvNICはvCenter Server Network-a5643020-0c6e-471b-8baf-6aa1021583b5 に所属している

 

いろいろな方法があるとは思いますが以下のアルゴリズムを考えました。

    1. ソース側のvSphere Clusterのtestフォルダに所属する全VMをリストする
    2. 1のリストのVMが持つvNICを取得する
    3. vNIC数が2つ、かつ対象のPortGroupの両方に所属にしているVM取得する

 

実際には以下のコマンドを使います

foreach ($vm in @((Get-Folder -Server non-vxrailVC -Name test | Get-VM))) {

$networkAdapters = (Get-Networkadapter -VM $vm) | Sort-Object -Property NetworkName

if ( (get-networkadapter -VM $vm | measure).count -eq 2 -And $networkAdapters.NetworkName.Contains("LAB") -And  $networkAdapters.NetworkName.Contains("vCenter Server Network-a5643020-0c6e-471b-8baf-6aa1021583b5") ) {

<ここに処理を記述>

}

}

 

foreach文にフォルダでフィルターしたVMリストを渡してループを回しています。

ループの中で各VMのvNICを取得して、vNICの数と所属に一致するものだけを対象に処理を実施します。

コマンド中、赤く強調した部分がありますがこれの意味はあとでわかります。

 

 

 

 

一度に一つのホストしかvMotion先として選べない

 

これを実現するためには、Move-VMコマンドレットでの移行毎に指定する宛先ホストを変える必要があります。

手法としては以下のようなアルゴリズムが考えられます。

    1. 宛先クラスタに所属する全ホストを配列に格納
    2. 配列の長さを取得
    3. ループ内で指定する配列のIndex番号を格納する変数を定義し、0で初期化する
    4. ループ毎にインデックス番号をインクリメントする
    5. Move-VMコマンドで指定するHostをインデックス番号で指定してvMotionをする
    6. インデックスが配列長に達したら0にもどす

 

上記のようなやり方が一般的と思いますが、今回はさぼって以下の一行で代替しました。

 

$destination = Get-Cluster -Name MARVIN* -Server vxrailVC | Get-VMHost | Get-Random -Count 1

 

要するに宛先クラスタ内の全ホストからランダムに1ホストをReturnしてくれるコマンドです。

これをMove-VMコマンドレットの前に実行すればvMotion毎に宛先ホストをランダムに変更できます。

 

 

 

 

複数vNIC/複数PortGroupを持つVMであってもそれぞれ適切な宛先PortGroupを指定できるようにする

 

実はMove-VMで指定する-NetworkAdapter オプションと -PortGroup オプションはそれぞれ配列を指定できます。

それぞれ配列は対応するインデックス番号とペアとみなされて処理されます。

すなわち、-NetworkAdapter でしたした配列の1番目のvNICは、-PortGroupで指定した配列の1番目のPortGroupに移行されます

 

このあたりの詳細や、配列の数に差異があった場合の動作などは以下のブログをご参考にしてください。

https://blogs.vmware.com/PowerCLI/2017/01/spotlight-move-vm-cmdlet.html

 

Move-VMコマンドで指定する際には-NetworkAdapter の配列に合う形で -PortGroup の配列を作成してあげればいいことになります。

たとえば、以下のVMの-NetworkAdapter の配列 に合う配列はどのようなものになるでしょうか?(画像①)

 

※画像①

1.PNG

 

宛先側のClusterで、

LAB ポートグループ → MARVIN* ポートグループ

vCentere* ポートグループ → vCenter* ポートグループ

としたいすると以下のように作成できます。

 

$destinationPortGroups += Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC) -Name MARVIN*

$destinationPortGroups += Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC) -Name vCenter*

 

ここで配列に格納する順番は重要です。順番が間違っていると意図したポートグループではないほうのポートグループに移行されてしまい、場合によってはサービスが停止する可能性があります。

 

さぁ、これであとはここまでで紹介したコマンドを組み合わせて実際に移行をしてみるだけなのですが、ちょっと待ってください。

例えば以下のようなVMについてはどうなると思いますか?(画像②)

 

※画像②

2.PNG

 

 

ここでもう一度今回のMove-VMの条件をおさらいしましょう。

 

対象VMの条件は、

・test フォルダに所属している

・vNICを二つ持ちそれぞれ別のポートグループに所属している

・一つのvNICはLAB ポートグループに所属している

・もう一つのvNICはvCenter Server Network-a5643020-0c6e-471b-8baf-6aa1021583b5 に所属している

 

ポートグループの紐づけ条件は、

・LAB       → MARVIN*

・vCentere* → vCenter*

 

でしたね。

 

例で提示した画像①のVMと画像②のVMは両方とも同じ条件を満たす必要があり、対象VMとして条件は満たしています。(つまり両方ともグルーピング条件に一致します。)

ポートグループの紐づけも一致する必要があるのですが、画像①のVMと画像②のVMではネットワークアダプタに対応するポートグループの順序が異なっており、このままではどちらかのVMにて正しくポートグループの移行がなされません。

Move-VMコマンド毎に-PortGroup の配列 の順序を変えれば解決できますが、それをしてしまうとそもそもPortGroupを基準としたグルーピングをした意味がなくなります。(結局同じPortGroupを使用しているVMであっても別のコマンドが必要なり一括処理ができなくなる)

 

同じポリシーで作成したVMにてvNICの順序が変わってしまうことは考えにくいですが、障害などが絡んで手動で再構成などをした場合、可能性はゼロではありません。これが基幹系のVMであったなら重大なサービス影響が出る可能性があります。

この問題をどのように解決したらいいでしょうか?

 

実はこの答えはすでに提示済みです。

グルーピングで紹介したforeachループの中に赤く強調した部分があったのは覚えていますでしょうか?

対象の部分だけ再掲します。

 

$networkAdapters = (Get-Networkadapter -VM $vm) | Sort-Object -Property NetworkName

 

$networkAdapters はMove-VMコマンドレットにて-NetworkAdapter の引数として指定する配列です。

この配列を作成する際に、NetworkNameでソートして配列エントリの順番を整えているのです。

実際に画像②のVMに対してこのソートを入れて配列を作成するとどうなるでしょうか?

 

実際に見てみましょう。(画像③)

※見やすさのため、一部コマンド出力が切れています。

 

※画像③

3.PNG

 

画像②も再掲します。

 

2.PNG

 

お判りでしょうか?画像②と画像③を比較するとvNICの順番が変わっており、画像③の状態であれば画像①のVMと同じコマンドでMove-VMコマンドを発行することが可能となります。

 

 

 

出来上がったコマンド例

 

PowerCLIやPowerShellに不慣れな方には、少々難しくわかりにくい部分があったかと思いますが、冒頭に上げた3つの課題はすべて解決されました。

最後に3つを組み合わせて出来上がったコマンドサンプルを紹介して終わりとさせていただきます。

 

# ソースとターゲットのVCに接続する

$cre = Get-Credential

Connect-VIServer -Server non-vxrailVC -Credential $cre

Connect-VIServer -Server vxrailVC -Credential $cre

 

# 宛先データストアを指定

$destinationDatastore = Get-Datastore -Server vxrailVC -Name MARVIN*

 

# 宛先ポートグループの配列を作成

$destinationPortGroups = @()

$destinationPortGroups += Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC) -Name MARVIN*

$destinationPortGroups += Get-VDPortgroup -VDSwitch (Get-VDSwitch -Server vxrailVC) -Name vCenter*

 

 

# testフォルダに所属するVM一覧でループを回す

foreach ($vm in @((Get-Folder -Server non-vxrailVC -Name test | Get-VM))) {

#各VMのvNIC情報を取得し、条件に合うものをif文で抽出

$networkAdapters = (Get-Networkadapter -VM $vm) | Sort-Object -Property NetworkName

if ( (get-networkadapter -VM $vm | measure).count -eq 2 -And $networkAdapters.NetworkName.Contains("LAB") -And  $networkAdapters.NetworkName.Contains("vCenter Server Network-a5643020-0c6e-471b-8baf-6aa1021583b5") ) {

#抽出したVMに対して、Move-VMコマンドレットで移行を実施する

$networkAdapters = Get-NetworkAdapter -VM $vm | Sort-Object -Property NetworkName

# 宛先クラスタのHost一覧からランダムに1ホストを指定

$destination = Get-Cluster -Name MARVIN* -Server vxrailVC | Get-VMHost | Get-Random -Count 1

$vm | Move-VM -Destination $destination -NetworkAdapter $networkAdapters -PortGroup $destinationPortGroups -Datastore $destinationDatastore -RunAsync

}

}

 

 

いかがでしたでしょうか?

今回紹介したコマンドに手を加えることで、VMをポートグループベースでグルーピングして、同じ移行条件にてホストを分散しつつの移行が可能になりました。

 

移行先と移行元でポートグループ名の一致させておき、それぞれのVMに合わせた形で宛先ポートグループの配列を作るようにスクリプトを組むこともできそうですが、よほど大規模かつ複雑で、多種多様なvNIC数とポートグループの組み合わせを持つ環境でもない限りは、この程度で十分なのではないでしょうか?

 

ご参考にしていただければ幸いです。

【VxRail】VCSAをバックアップからリストアできない!?場合の対処

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

 

もしVCSAが突然使えなくなったらどうしますか?

 

VCSAがDownした場合はvMotionやvSANに関するオペレーションができなくなるか、かなり制限されます。

またHorizon環境ではVDIに接続できなくなったりするので被害が甚大になる場合があります。

 

この世の中に100%の可用性を保証するストレージは存在せず、VxRail(vSAN)も例外ではありません。

したがって、VCSAに限らず、失われたら困るデータやVMは必ずバックアップを取る必要があります。

 

しかしながら、バックアップは取ってはいるものの、いざリストアが必要になったときに手順がわからないといった不安や、

ベンダーの提供する手順書通りにリストアできない!といったトラブルはバックアップあるあるだと思います。

 

VxRail環境においてもきっと例外ではないでしょう。

 

VxRail環境では多くのユーザーでVDPによるバックアップをしていますが、特にVCSA/PSCのリストアをする際に以下の想定外に直面することになります。

 

  1. VDPでVMをリストアする際にvCenterが必要なのでVCSA/PSCがない状態では、そもそもVMをリストアできない
  2. VxRailは分散仮想スイッチしかないのでリストアしたVM(VCSA/PSC)をネットワークに接続するにはVCSA/PSCが必要
  3. リストア後にVxRail Manager の内部DBの情報と齟齬が生じる

 

 

1つ目と2つ目は要するにVDPやVDSの観点でそもそもVCSA/PSCに依存しているため、金庫に鍵を閉じ込めたような状態になるわけです。

かといって、VCSA/PSCは重要なVMであり、リストアできませんでは話になりません。

 

3つ目はVxRail固有の問題とはなりますが、通常運用時は問題にならず、Upgradeや構成変更の際に顕在化することがあるのでリストア後に追加の対処が必要です。

ではどのようにしてこの矛盾を解決すればいいでしょうか?

 

1つ目の問題について

1については簡単です。というのもすでにVDPにはその機能があります。

EmergencyRestoreと呼ばれる機能で、vCenterがない状態でもESXiに直接VMをリストアできる機能です。

この機能があるのでVCSA/PSCに問題が発生したとしてもVDPが生きていればリストアが可能です。

 

詳細は下記VDP管理者ガイドに譲りますが概要としては以下です。

    1. VDP GUIにログイン
    2. Emergency Restoreのタブに移動し、VDPが稼働しているESXiを確認
    3. 上記ESXiのGUIにログインして「vCenterからの切断」を実施
    4. VDP GUIのEmergency Restoreタブから上記ESXiにVCSA/PSCのリストアを実行
    5. リストア後、VCSA/PSCを起動して後に上記ESXiをvCenterに再接続する

 

VDP管理者ガイド

https://docs.vmware.com/en/VMware-vSphere/6.5/vmware-data-protection-administration-guide-61.pdf

 

上記ドキュメントだけでは不安(英語だし。。。)というユーザは有事の際はDell EMCサポートにご相談下さい。

通常、リストア作業はユーザ作業範疇ですがDell EMCのVxRailサポートは旧EMCのエンタープライズサポート文化を継承しているので、より踏み込んだサポートを提供していると自負しています。

また以下のDECNブログでも詳しく説明されています。

 

VxRail 管理系VMのバックアップ・リストア方法【リストア・復旧編】

 

 

VDP以外のバックアップソリューションを利用している場合は必ずVCSA/PSCへの対応状況を確認してください。

一部のバックアップソリューションはVCSA/PSCのリストアができない場合があります。

 

 

2つ目の問題について

2つ目の問題についてはどうでしょうか?

VDPの機能でVCSA/PSC VMをリストアした場合、リストアしたVMは新規VMということになりますが、新規VMのネットワークを設定する場合はVCSA/PSCが必要になります。

そのため、リストアしたVCSA/PSCは仮想スイッチに接続することができず、そのままでは役に立ちません。

この問題の解決方法として以下が考えられます。

 

    1. 事前に短期ポート(Ephemeral Port)を作成しておく
    2. 一時的に標準仮想スイッチを作成し、vmnicの一つを割り当てる(冗長性の低下が発生)
    3. VxRail Manager VMのポートを借りてネットワークに接続する

 

1の方法は短期ポート(短期バインド)とよばれる、VDS上のポートグループでありながらESXiのみで管理可能なポートになります。※短期ポート(短期バインド)の説明(https://kb.vmware.com/s/article/1022312?lang=ja

ただし、短期ポートの作成自体はVCSA/PSCが必要なため、復旧用に事前に作成しておく必要があります。

※作成する短期ポートのポートグループは既存のvCenterネットワークポートグループと同様のVLANを設定し、IPの変更なくESXiと疎通できる必要があります。

事前に作成さえしておけば、この方法が最も簡単なリストア方法になります。

やり方としては、Emergency RestoreでVCSA/PSC VMをリストアしたのちに対象のESXiのGUIにログインして、短期ポートとして作成しておいたポートグループをアサインするだけです。

 

2の方法は既存VDSに割り当てられているvmnicの一つを引っぺがして、新しく作った標準仮想スイッチに割り当てなおすことで、VCSA/PSCなしで新規VMを外部ネットワークと疎通させることができます。

この方法はすでにご紹介済みのDECNブログで説明されていますのでそちらをご参照ください。

VxRail 管理系VMのバックアップ・リストア方法【リストア・復旧編】

 

 

3の方法は既存のVMから作成済みの分散仮想スイッチポートを借用する方法です。

要するに既存の接続済み仮想マシンに成りすまして分散仮想スイッチのポートグループに接続してしまう、という方法です。

この方法はDell EMC KB#504380にて説明されている方法です。

犠牲となるVMはVxRail Managerでなくとも、vCenterと同じポートグループに接続されているVMであれば構いません。

Shutdownする必要があるので、業務影響のないVMを選んでください。

古いVCSA/PSCのポートを借用可能であればそれを流用して構いません。

詳細は上記KBに譲りますが、概要は以下です。

 

    1. VxRail Manager VMをShutdownする
    2. VxRail Managerのvmxファイルからdvs.portIdとdvs.connectedIdをメモする
    3. リストア済み(ネットワーク未接続)のVCSA VMをShutdownする
    4. リストア済みVCSAのvmxファイルを編集してdvs.portIdとdvs.connectedIdをVxRail Manager VMのものと書き換える
    5. VCSA VMを起動する
    6. 起動後VCSA VMを別のHostにvMotionする。vMotionすることでdvs.portId情報が更新されます。
    7. VxRail Manager VMを起動する

 

 

3つ目の問題について

3つ目の問題はVCSA/PSCのリストア後に発生する問題です。

VxRail Managerでは内部DBにVCSA/PSCのuuidとmorefIdを保存していますが、VCSA/PSCをリストアすることでその値が変わってしまうため、内部DB側も編集してあげる必要があります。

この作業はDell EMCサポートにて実施すべきものなので、リストア後はDell EMCサポート窓口にご連絡ください。

なお、VxRail Manager の内部DBの値が実際のUUID/MorefIDと異なっていたとしても、業務影響はありませんのでご安心ください。

即座に対処する必要はありませんが、将来的にUpgradeや構成変更時にVxRail ManagerがVCSA/PSCを見つけられずにエラーとなる可能性がありますので忘れずに対処しましょう。

 

 

いかがでしたでしょうか。

いきなりすべてを理解するのは難しいかもしれませんが、障害時は迅速な復旧が求められる場合もありますので一度関連KBや資料に目を通しておかれることをお勧めします。

【VxRail】VxRailのInternal VCSA/PSCをFLRできるのか

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

VxRail環境でInternal VCSA/PSCのバックアップをどうするべきか、という議論をちょくちょく耳にします。

 

その議論の背景はきっと以下のようなPain Pointによるものでしょう。

 

  1. VxRail環境では分散スイッチしかないため、VCSA/PSCがダウンしているとリストアしたVMがネットワークに接続できない
  2. バックアップソリューションがVCSAやPSCのリストアに対応してない場合がある
  3. vSphere Data ProtectionがVxRail 4.7 (vSphere 6.7) 以降で使用できなくなり、タダで使えるバックアップソリューションがなくなる
  4. 競合との兼ね合いで、せめてSystem VMぐらいは標準的なバックアップ/リストアを提供したい
  5. SnapshotやCloneといったvSAN内部に保存するやり方は静止点の保存に過ぎず、バックアップとは言えない
  6. 定期的なOVFテンプレートのExportではスマートさに欠ける(サイズも大きくなりがち)

 

 

1についてはすでに以下で解説しています。

VCSAをバックアップからリストアできない!?場合の対処

 

 

2~6については、

  • VCSA/PSCは、vSphere 6.5から導入されたFile Level Backup/Restoreを使えばバックアップが可能
  • VxRail Managerは、VxRail 4.0.400以降で導入されたFile Level Backup/Restoreを使えばバックアップ/リストア可能
  • ESRSVE/LogInsightについては、なくても業務影響はなく、また再構築可能なのでバックアップは不要

といった感じになると思います。

問題は本記事のタイトルになっている、

 

VxRailのInternal VCSA/PSCをFLR(File Level Restore)できるのか?

 

ということです。

 

結論から言えば、厳密には可能とはされていません。ただしそれ以外に有効なバックアップ方法がない場合はFile-Level Backupを継続的に取得してください。

 

可能とされていない、というのはVxRail Managerが提供するVxRail独自の機能(Upgradeや構成変更やモニタリング)との互換性が検証されていないからです。

 

とはいえ、VxRail独自機能はvSANの可用性や仮想マシンの稼働とは関係がありません。

仮にVxRail Managerの機能が失われたとしても、緊急時であればFile Level Restoreを実施するべきです。

実際に、本当にVxRailとしての復旧が困難となった場合(vSANとしては問題なく稼働)でも、結局はVMを安全に退避するためにvCenterが必要となります。

ゼロからVCSA/PSCを構築しなおすことも不可能ではありませんが、それであればFile Levelバックアップから戻したほうがいいです。

 

なので、File Levelバックアップであっても必ず取得してvSANの外に保存しておくべきです。

 

 

なお、VxRail Manager VMが復旧困難となった場合は、再デプロイが不可能ですので、Cluster Reset以外の復旧方法がありません。

VxRail Manager VMのバックアップも忘れずに取得してvSANの外に保存をお願いします。


vSphereのアラーム定義で一覧にないEventのアラームを定義する方法

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

 

ある特定のEventを検知したいのにアラーム定義の一覧にそのEventがない!

といった経験はないでしょうか?

 

具体的には以下で参照できる一覧のことです。

 

1.PNG

 

 

vCenterにはデフォルトでアラームが定義されていて、多くの場合はそれで問題ない(通知設定は必要)場合が多いと思いますが、

デフォルトにないEventをアラームで検知したい場合などは自分でアラーム定義を追加することが可能です。

その際に検知したいEventを上記リストから選ぶ必要があります。

しかしながら検知したいEventがリストになくて断念、、、といったパターンもあるのではないでしょうか?

 

 

 

 

 

例えばですが、VxRailの過去のVersionでは、/tmpや/varといったESXiのRAMDISK容量が枯渇する不具合がありました(※修正済み)。

シナリオとして、Fixが出る前の段階では暫定対策としてこのEventをすぐに検知して対処したいと考えるのは自然なことです。

この場合、対象となるEventとして、

 

"RAM ディスクがいっぱいです。"

"RAM ディスクのファイル テーブルがいっぱいです。"

 

といったEventがvCenterには存在しますので、これらのEventについてアラームを定義できれば目的は達成されます。

 

しかしながらvSphere web clientから新しいアラーム定義としてこのEvent通知を定義しようにも、上記のEventがリストにないので設定することができません。

このような場合はどうすればよいでしょうか?

 

 

 

 

 

 

実は上記の例のようにすでに設定したいvCenterのEventが明らかになっている場合は対象のEvent IDを直打ちすることで設定が可能になります。

 

何を言っているの?と思われるかもしれませんが、実はアラーム定義の対象Eventはリストから選ぶ必要はないのです。

具体的には以下のようにします。

 

2.PNG

 

お判りでしょうか?本来リストから選ぶべき項目は、実は入力可能になっており、好きなEventを直に設定できます。

上記の例では、

 

esx.problem.visorfs.ramdisk.full  =====> "RAM ディスクがいっぱいです。"

esx.problem.visorfs.ramdisk.inodetable.full =====> "RAM ディスクのファイル テーブルがいっぱいです。"

 

にそれぞれ対応しています。

このように直にEventIDを設定することでリストにないEventのアラーム定義を作成することが可能なのです。

 

ちなみに、一度設定すれば下図のようにEvent IDを自動的にHuman Friendlyな表現に自動的に書き換えてくれるのでわかりやすさも損なわれません。

 

(編集画面)

3.PNG

 

(確認画面)

4.PNG

 

 

いかがでしょうか?これでRAMDISKの枯渇を検知する、といった目的は達成できました。

 

 

 

 

と、、、、ここまで読んでいただいた方の脳裏には一つ(もしくは二つ)の疑問が浮かんでいるかと思います。

 

設定するEvent IDはどうやって調べんねん!?

※筆者は生粋の江戸っ子です

 

 

当然の疑問ですね。続きは次回にします。

 

 

次回記事↓↓↓

 

vCenterに定義されているEventの一覧とEventIDを取得する方法

vCenterに定義されているEventの一覧とEventIDを取得する方法

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

※本記事は前回の続きです。前回の記事はコチラ↓↓↓

vSphereのアラーム定義で一覧にないEventのアラームを定義する方法

 

 

 

さて、前回の記事ではより自由なアラーム定義の方法をご紹介しましたが、そのためにはEventIDが必要だということがわかりました。

厳密にはEventIDでなくともEventDescriptionを設定すればいいのですが、日本語の場合はスペースや句読点など正しく入力するには多少のハードルがありますので好ましくありません。

前回のEventを例にするとEventDescriptionは以下の二つになりますが、それぞれ微妙に半角スペースが用いられており、正しく入力できない懸念があります。

 

"RAM ディスクがいっぱいです。"

"RAM ディスクのファイル テーブルがいっぱいです。"

 

 

したがって、EventIDがわかるのであればEventIDで入力したいところです。

ではどうやってEventIDを調べるのか、というのが本記事の趣旨になります。

 

 

実はEvent自体はvCenter内に定義ファイルと思しきものがあるのでそれを見ればいいのです。

VMwareの公式情報があるわけではないですが、検証機で試したところ以下の場所に定義ファイルと思しきものを見つけることができました。

 

/etc/vmware-vpx/extensions/hostdiag/extension.xml

 

 

ちなみに確認で用いたvCenterのVersionは以下です。

BRANCH:vsphere65ep7

BUILDNUMBER:8815520

CLOUDVM_VERSION:6.5.0.21000

 

このファイルをみるとEventIDやそのDescriptionがまとめられているのがわかります。

ここから目的とするEventを探し出せばよい、ということになります。

このファイルのDescriptionは英語で書かれていますので、対象のEventの英語表記を探して対象のEventIDを取得すればよいのです。

 

「いや、オレは日本語のメッセージから探したいんだ!」

 

という強い意志をお持ち方は、同じくvCenter内にあるEventの日本語訳が定義されている(と思しき)ファイルを見てください。

検証環境のVCSAでは以下のファイルが該当しているようです。

 

/etc/vmware-vpx/extensions/hostdiag/locale/ja/event.vmsg

 

たとえば、今回の例でいうと以下のように書かれていました。

 

esx.problem.visorfs.ramdisk.full.description     = "RAM ディスクがいっぱいです。"

esx.problem.visorfs.ramdisk.full.formatOnVm      = ""

esx.problem.visorfs.ramdisk.full.formatOnHost    = ""

esx.problem.visorfs.ramdisk.full.formatOnComputeResource = ""

esx.problem.visorfs.ramdisk.full.formatOnDatacenter = ""

esx.problem.visorfs.ramdisk.full.fullFormat      = "RAM ディスク「{1}」がいっぱいです。  そのため、ファイル {2} を書き込むことができませんでした。"

 

したがって、対象のEventIDとして、esx.problem.visorfs.ramdisk.full が抽出できます。

同ファイルにはおそらくvCenterの定義Eventのすべてが記載されていると思われますので、そもそもEventDescriptionにすらアタリがついていない場合は、この中から適当なものを探し出すこともできます。

 

 

 

いかがでしたでしょうか?

2回に分けて紹介したアラーム定義の設定によって、いままで通知できなかったEventも通知できるようになりました。

本記事の内容が、VxRailに限らず、VMware環境の運用監視負荷軽減に寄与すれば幸いです。

vSwitchにSTPが不要な理由

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

 

 

** 知っている人にとっては当たり前の内容です**

 

 

ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。

ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ(vSwitch)につながっています。

vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。

 

1.PNG

図1:ネットワークトポロジ

 

 

vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。

L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol(STP)を設定する必要(最近では必ずしもそうとは言い切れないようですが。。。)があります。

 

ではvSwitchの場合でもSpanning Treeに参加する(ネットワークは専門外なので表現が間違っていたらすみません。。。)必要があるのでしょうか?

表題からもわかるように答えはNoです。

L2ネットワークでBPDUと呼ばれるパケットをやり取りすることでSpanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。

 

ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか?Loopによる問題は発生しないのでしょうか?

 

実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。

その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。

 

たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。

 

下図ではUplink1からBroadcast Packetを受信した際の動作を示しています。

Broadcast Packetは仮想スイッチに接続されるVMに対して転送されますが、uplink2へは転送されません。

 

2.PNG

図2:外部からのBroadcast PacketはほかのUplinkへ転送されない

 

 

またUnknown Unicast(フレームの宛先MACアドレスがMACアドレステーブルにない場合)を外部からUplink経由で受け取った場合、普通の物理L2SWであればFloodingして宛先を探すことになりますが、vSwitchの場合は宛先MACアドレスに一致するVMがいない場合はそのパケットをドロップし、他のUplinkからFloodingすることはありません。

 

このような動作をするはvSwitchがあくまで仮想マシンのための通信であって、その他のNodeとの通信を転送する必要がないためだと思われます。

その結果、STPによりBlockされるポートがないため、帯域を損なうことがありません。

 

言うまでもないことかもしれませんが、ESXi上で稼働するVM起因のBroadcastやUnknown UnicastはちゃんとUplinkへ転送されますのでVMの動作に問題が出ることはありません。

 

3.PNG

図3:仮想マシン(内部)からのBroadcastやUnknown UnicastはUplinkへ転送される

 

 

より詳しく知りたい方は以下の資料が参考になります。

 

参考資料:

Networking for VMware Administrators (書籍)

Best Practices for Virtual Networking(PDF)

 

 

 

vMotionできない、、、そんな時。 (その①)

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

仮想化のメリット

 

VMwareの仮想基盤を導入する最も大きなメリットは何でしょうか?

 

私はvMotionだと思います。

 

ハードウェアを抽象化することでソフトウェアとハードウェアを切り離し、仮想マシンの可搬性が実現されました。

物理サーバのメンテナンス時やリソース不足の際に仮想マシンをオンラインで移行することで、ダウンタイムなしでリソース増設や物理交換が可能になります。

 

 

vMotionができない?!

 

しかしながら、日々の運用の中でvMotionができないシチュエーションが存在します。

それはESXiがvCenterから管理不可状態になってしまった場合です。

vMotionはESXi単体の操作ではなく、複数のESXiにまたがる操作となるため、仲介者としてvCenterが必要なります。

したがって、vCenterから管理できなくなったESXi上の仮想マシンはvMotionができなくなってしまいます。

 

このような管理不可状態は、多くの場合ESXiの管理サービス(hostd)の動作不良によって引き起こされます。vSphere Web Clientから確認すると管理不可状態のESXiは”応答なし”もしくは”Not Responding”と表示されます。

応答なしのESXiで稼働する仮想マシンは切断状態(もしくはdisconnected)となりますが、あくまでvCenter目線でのステータスであり、仮想マシンの稼働状態とは関係ないのでご安心ください。

 

1.PNG

 

※hostdの不具合によるNot Respoding事象自体は、あくまでESXiの管理機能の縮退に相当するだけの事象ですので、対象ESXi上で稼働する仮想マシンの稼働には影響がなく、仮想マシンは問題なく稼働を続けられます。

また、vSANクラスタであった場合でもvSANデータオブジェクトへの可用性には影響がありません。

 

hostdサービスの再起動などで事象が改善すれば問題ないのですが、事象によってはどうしてもESXiの再起動が必要となる場合があります。

ESXiを再起動するためには稼働する仮想マシンを退避する必要がありますが、vMotionができないのでそれもできません。

このような場合はどうしたらよいのでしょうか?

 

 

とりあえず対応保留!?

 

結論から言って、vMotionできない状況でESXiの再起動が必要となってしまった場合は、仮想マシンのダウンタイムが避けられません。

 

とはいえ、すでに述べたように(筆者の想定してる)この事象の場合では、仮想マシンの稼働やvSANデータオブジェクトの可用性への影響はなく、ただちの対処が必要必要な状況ではありません。

 

即座に対処する必要がないだけでなく、また即座に対処(仮想マシンの停止)できない場合がほとんどですので、とりあえず対応を保留し、仮想マシンのダウンタイムを調整する、というのはほぼすべてのパターンで採用される暫定対応です。

 

では、実際にダウンタイムの調整が完了し、いざESXiの再起動を実施する場合はどのようにしたらよいでしょうか?

 

以下のパターンが考えられます。

 

① 仮想マシンをGuestOS側からShutdownし、ESXiの再起動完了後に再度起動させる(ダウンタイム30分~数時間)

② 仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動(ダウンタイム数分~数十分)

③ 仮想マシンを強制的にPowerOff(Kill)し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分

④ 仮想マシンごとESXiを強制的に再起動し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分

 

 

GuestOS側からShutdownする理由

 

誤解を避けるためにまず用語を確認しておきます。私の記事の中では以下の意味で使用します。

 

Node:ESXiがインストールされた物理サーバ。VxRailの場合はPowerEdgeを使っています。(Quantaもあるけど)

ESXi: VMwareが提供するHypervisor。仮想マシンを作成し、管理し、実行する。ホストとも呼ばれることがある

仮想マシン:VMと略して呼ばれることもある。Hypervisorが提供する仮想ハードウェア。GuestOSを実行できる。

GuestOS:仮想マシン上で実行されるOS。WindowsやLinuxなど。

 

なぜこのタイミングで用語を確認したのかというと、仮想マシンとGuestOSの違いが明確に使い分けられていない場合や、そもそも用語が異なる場合があるからです(仮想OS、仮想ホスト、アプリなど。。。)

 

さて、本題にもどってvMotionができない場合はGuestOS側からShutdownする必要があると説明していますがなぜでしょうか。

 

本記事では主にhostdの不具合によるvMotion不可のケースを想定していますが、hostdが正しく動作していない場合、ESXiのCLIやWebClient GUIといったツールから対象の仮想マシンをShutdownすることができません。(hostdに依存しているため)

 

したがって、そのような場合に安全にGuestOSをShutdownするにはGuestOS側の機能を使うしかありません。

たとえばWindowsOSを稼働させている場合は、WindowsOSにRDPなどでログインしてShutdown操作をすることになります。

Linuxの場合はSSHでログインしてShutdownコマンドにて落とすのが一般的と思います。

 

ではもしRDPやSSHが無効でGuestOS側からShutdownができない状況だったら?

→その場合は強制的に落とすしか手段がありません。(仮想マシンのkill or ESXiごと強制再起動)

 

それなら初めから全部強制的に落とせばいいんじゃないの?と思われる方もいらっしゃるかもしれませんが、たとえばご自身のPCを落とすときに時間短縮になるといって、電源ケーブルを抜いたり、バッテリーを抜いたりして落とす人がいるでしょうか?

そのような無茶をした場合、作業中のファイルが破損してしまう場合がありますので、特殊な場合をのぞき、基本的にはきちんとシャットダウンしてから落とす必要があります。

 

 

本記事ではhostd不具合を前提とした、vMotion不可ケースの対応として、とりあえず静観or対応保留が可能であることと、ESXi再起動をともなう作業のためにはGuestOS側からのShutdownが推奨であることを説明しました。

 

次回からは①~④までの手順を説明していきます。

 

※下記URLから直接それぞれのページへ飛べます。

仮想マシンをGuestOS側からShutdownし、ESXiの再起動完了後に再度起動させる(ダウンタイム30分~数時間)

仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動(ダウンタイム数分~数十分)

仮想マシンを強制的にPowerOff(Kill)し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分

仮想マシンごとESXiを強制的に再起動し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する(ダウンタイム数分~数十分

vMotionできない、、、そんな時。 (その②)

$
0
0

**** 留意事項 *****

こちらのブログの内容はDECN(Dell EMC Community Network)に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

 

本記事は以下の記事の続きです。前提条件や用語の確認などがありますので、前回記事を読んでいない方はご一読ください。

 

vMotionできない、、、そんな時。      (その①)

 

 

本記事では前回記事で説明した対処法の一つである、

 

① 仮想マシンをGuestOS側からShutdownし、ESXiの再起動完了後に再度起動させる(ダウンタイム30分~数時間)

 

について説明します。

 

 

実施方法

 

  1. 仮想マシンのダウンタイムの調整が完了したら、対象ESXi上の仮想マシンをすべてGuestOS側からShutdownしてください。
    • 具体的なShutdown手順や対象の仮想マシンを管理している担当者もしくは構築ベンダやOSベンダにご相談ください。
    • 安全にShutdownできないVMがある場合は、強制的に落とすしかありません。その場合はGuestOSのファイルシステムが破損する可能性があります。
  2. 対象ESXi上のすべての仮想マシンをShutdownし終わったら、ESXiのサポート(VxRailの場合はDell EMC)の指示通りにESXiを再起動します。
    • vSANを利用している場合、かならずvSANデータオブジェクトがすべて健全であることを確認してください。(後述)
    • 障害の内容や状況に応じて再起動の手順が異なる場合がありますが、たいていの場合はvSANデータオブジェクトの健全性を確認してからNodeの強制リセット(iDRAC or BMC)のパターンで問題ないです。
  3. ESXiの再起動が完了したらvCenterから正しく認識されている(応答なし状態ではない)ことをvSphere Web Clientから確認し、Shutdownした仮想マシンを起動してください。
  4. 最後にvSANヘルスチェックとVxRail ManagerのDiagnostic(VxRailの場合)を実施して健全性を確認してください。
    • こちらのヘルスチェック手順をご参考にしてください
    • エラーや警告があった場合はサポートにご連絡ください。

 

この方法のメリット・デメリット

メリット

    • 比較的簡単
    • vCenterやPSCの配置に依存しない
      • 対象のESXi上にvCenterやPSCがいた場合、それらはShutdownされるが本手順では関係ない

 

デメリット

    • 最低でも15分くらいはダウンタイムが発生する
    • 万が一ESXiが起動してこなかった場合は数十分~数時間のダウンタイムが発生する場合がある。
      • とりいそぎ他のESXiで起動する必要があるため

 

この方法の使いどころ

以下の場合にお勧めです。

    • 仮想化環境の操作にあまり慣れてない
    • 手順をシンプルにしてオペレーションミスを防ぎたい
    • メンテナンスウインドウをとしてダウンタイムを5~8時間程度確保できる

 

 

 

(補足)vSANデータオブジェクトの健全性を確認

vSAN環境では仮想マシンが使用するデータはCluster内の各ESXiが分散して保有することで冗長性を確保しています。

もしvSANデータオブジェクトが健全でない(=冗長性が確保されていない)状態でESXiを再起動してしまうと、データにアクセスできなくなる仮想マシンが出てくる可能性があります。

なのでESXiの(強制)再起動前に必ずvSANデータオブジェクトの健全性を確認しましょう。

 

確認方法はvSphere WebClientにログインして以下の画面を開いてください。

右上の再テストボタンも押してください。

 

2.PNG

 

赤線を引いたVirtual SAN オブジェクトの健全性がパスしていれば問題ありません。

画面下部ですべてのobjectがhealthyであることを確認してください。

 

また失敗となっているネットワーク、物理ディスク、クラスタは”応答なし”状態のESXiがある場合は必ずでますのでこの段階では無視してください。

 

 

 

以上です。次回は、

② 仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動(ダウンタイム数分~数十分)

について説明します。

Viewing all 5007 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>