Những vấn đề thường gặp với phiên bản vSphere 7.0 (Phần 1/4)

  • Created:
  • / Author: PACISOFT Help 12
Lượt xem: 1,908

Trong quá trình cài đặt và nâng cấp vSphere, người dùng hầu như đều bắt gặp phải những vấn đề hoặc những lỗi xảy ra trong lúc thực hiện, và ở phiên bản vSphere 7.0 cũng không phải ngoại lệ. Ở phần đầu tiên bài viết của series này, VMware sẽ chỉ ra 3 nhóm vấn đề đầu tiên người dùng thường gặp với vSphere 7.0 cũng như cách giải quyết chúng.

Các vấn đề trong việc cài đặt, nâng cấp và di chuyển

  • Vấn đề mới nhất: Tên thiết bị vmnic và vmhba thay đổi sau khi nâng cấp lên ESXi 7.0

Trên một số nền tảng phần cứng nhất định, tên thiết bị vmnic và vmhba (bí danh) có thể thay đổi khi nâng cấp lên ESXi 7.0 từ phiên bản ESXi trước đó. Điều này xảy ra trên các hệ thống có chương trình cơ sở cung cấp phương thức ACPI _SUN. Phương thức này sẽ trả về số vị trí vật lý là 0 cho các thiết bị không nằm trong khe cắm trống.

Cách giải quyết: người dùng có thể đổi tên thiết bị bằng cách sử dụng hướng dẫn trong bài viết hỗ trợ kiến thức VMware 2091560.

  • Kiểm tra sơ bộ quá trình Nâng cấp/Di chuyển vCenter không thành công với lỗi “Unexpected error 87“. (Lỗi không mong muốn số 87)

Việc kiểm tra sơ bộ Nâng cấp/Di chuyển vCenter Server không thành công khi chứng nhận Security Token Service (STS) không chứa trường Subject Alternative Name (SAN). Tình huống này xảy ra khi người dùng cố gắng nâng cấp lên vCenter Server 7.0 và thay thế chứng nhận vCenter 5.5 Single Sign-On bằng một chứng nhận tùy chỉnh khác không có trường SAN. Việc nâng cấp sẽ được xem xét lại khi chứng chỉ STS không hợp lệ và việc kiểm tra sơ bộ sẽ ngăn quá trình nâng cấp tiếp tục.

Cách giải quyết: thay thế chứng nhận STS bằng một chứng nhận hợp lệ khác có chứa trường SAN, sau đó tiến hành Nâng cấp/Di chuyển vCenter Server 7.0.

  • Những sự cố diễn ra trong quá trình nâng cấp lên vSphere 7.0 với các bộ cấp CIM đã có từ trước.

Sau khi nâng cấp, các bộ cấp CIM 32 bit đã cài đặt trước đó ngừng hoạt động vì ESXi yêu cầu các bộ cấp CIM 64 bit. Khách hàng có thể mất các chức năng API quản lý liên quan đến CIMPDK, NDDK (DDK gốc), HEXDK, VAIODK (bộ lọc IO) và xem các lỗi liên quan đến việc phụ thuộc vào uwglibc.

Nhật ký hệ thống báo cáo thiếu module, “32 bit shared libraries not loaded: (“Thư viện chia sẻ 32 bit không thể tải được.”)

Cách giải quyết: hiện tại không có Cách giải quyết nào. Cách khắc phục duy nhất là tải bộ cấp CIM 64-bit mới.

  • Smart Card và RSA SecurID authentication có thể ngừng hoạt động sau khi nâng cấp lên vCenter Server 7.0

Nếu người dùng đã định cấu hình vCenter Server cho Smart Card hoặc RSA SecurID authentication, hãy xem thêm bài viết cơ sở kiến thức về VMware tại https://kb.vmware.com/s/article/78057 trước khi bắt đầu quá trình nâng cấp vSphere 7.0. Nếu người dùng không thực hiện được Cách giải quyết thay thế như mô tả trong KB, họ có thể thấy các thông báo lỗi đi kèm cũng như Smart Card hoặc RSA SecurID authentication không hoạt động.

“Smart Card authentication có thể ngừng hoạt động. Việc cài đặt Smart Card có thể không được duy trì và Smart Card authentication có thể ngừng hoạt động.”

hoặc

“RSA SecurID authentication có thể ngừng hoạt động. Cài đặt RSA SecurID có thể không được duy trì và RSA SecurID authentication có thể ngừng hoạt động.”

 

Cách giải quyết: trước khi nâng cấp lên vSphere 7.0, hãy xem bài viết cơ sở kiến thức về VMware tại https://kb.vmware.com/s/article/78057.

  • Nâng cấp vCenter Server với external Platform Services Controller từ 6.7u3 lên 7.0 không thành công với lỗi VMAFD.

Khi triển khai việc nâng cấp vCenter Server bằng external Platform Services Controller, người dùng sẽ phải chuyển Platform Services Controller thành một thiết bị vCenter Server. Nếu quá trình nâng cấp không thành công với lỗi xuất hiện là install.vmafd.vmdir_vdcpromo_error_21 thì quá trình khởi động VMAFD đầu tiên cũng sẽ thất bại. Quá trình khởi động VMAFD đầu tiên sao chép VMware Directory Service Database (data.mdb) từ Platform Services Controller và bản sao của thiết bị vCenter Server. 

Cách giải quyết: Vô hiệu hóa TCP Segmentation Offload TCP (TSO) và Generic Segmentation Offload (GSO) trên bộ điều hợp Ethernet của Platform Services Controller hoặc bản sao của thiết bị vCenter Server trước khi nâng cấp  vCenter Server với external Platform Services Controller. Xem thêm bài viết trong Knowledge Base: https://kb.vmware.com/s/article/74678.

  • Nâng cấp vCenter Server bằng cách sử dụng CLI sẽ không hoàn toàn giữ nguyên cấu hình Transport Security Layer (TLS) cho dịch vụ vSphere Authentication Proxy.

Nếu dịch vụ vSphere Authentication Proxy (vmcam) được định cấu hình để sử dụng giao thức TLS cụ thể khác với giao thức TLS 1.2 mặc định, cấu hình này được giữ nguyên trong quá trình nâng cấp CLI. Theo mặc định, vSphere hỗ trợ giao thức mã hóa TLS 1.2. Nếu người dùng phải sử dụng các giao thức TLS 1.0 và TLS 1.1 để hỗ trợ các sản phẩm hoặc dịch vụ không hỗ trợ TLS 1.2, hãy sử dụng TLS Configurator Utility để bật hoặc tắt các phiên bản giao thức TLS khác nhau.

Cách giải quyết: Sử dụng TLS Configurator Utility để định cấu hình cổng vmcam. Để tìm hiểu cách quản lý cấu hình giao thức TLS và sử dụng TLS Configurator Utility, hãy xem tài liệu VMware Security.

  • Cài đặt Smart card và RSA SecurID có thể bị thay đổi trong quá trình nâng cấp vCenter Server.

Việc xác thực bằng RSA SecurID sẽ không hoạt động sau khi nâng cấp lên vCenter Server 7.0. Thông báo lỗi sẽ cảnh báo cho người dùng về vấn đề này khi họ cố gắng đăng nhập bằng thông tin đăng nhập RSA SecurID.

Cách giải quyết: Định cấu hình lại Smart card hoặc RSA SecurID.

  • Di chuyển vCenter Server đối với Windows sang thiết bị vCenter Server 7.0 không thành công với thông báo lỗi mạng.

Di chuyển vCenter Server với Windows sang thiết bị vCenter Server 7.0 không thành công với thông báo lỗi IP đã tồn tại trong mạng (IP already exists in the network). Điều này ngăn cản quá trình di chuyển định cấu hình các thông số mạng trên thiết bị vCenter Server mới. Để biết thêm thông tin, hãy kiểm tra tệp nhật ký: /var/log/vmware/upgrade/UpgradeRunner.log 

Cách giải quyết:

  1. Người dùng cần xác minh rằng tất cả các Bản cập nhật Windows đã được hoàn tất trên phiên bản vCenter Server gốc của Windows hoặc tắt các Bản tự động cập nhật Windows cho đến khi quá trình di chuyển kết thúc.
  2. Thử lại quá trình di chuyển vCenter Server với Windows sang thiết bị vCenter Server 7.0.
  • Khi người dùng định cấu hình số lượng chức năng ảo cho thiết bị SR-IOV bằng cách sử dụng tham số module max_vfs, các thay đổi có thể không có hiệu lực.

Trong vSphere 7.0, người dùng có thể định cấu hình số lượng chức năng ảo cho thiết bị SR-IOV bằng cách sử dụng API quản lý cơ sở hạ tầng ảo (VIM) thông qua vSphere Client. Tác vụ này không yêu cầu khởi động lại máy chủ ESXi. Sau khi sử dụng cấu hình API VIM, nếu người dùng cố gắng định cấu hình số lượng hàm ảo SR-IOV bằng cách sử dụng tham số module max_vfs, các thay đổi có thể không có hiệu lực vì chúng bị cấu hình API VIM ghi đè.

Cách giải quyết: Hiện không có. Để định cấu hình số lượng chức năng ảo cho thiết bị SR-IOV, hãy sử dụng cùng một phương pháp mọi lúc. Sử dụng API VIM hoặc sử dụng tham số module max_vfs và khởi động lại máy chủ ESXi.

  • Phiên bản được nâng cấp của thiết bị vCenter Server không giữ lại tất cả các mạng phụ (NIC) từ phiên bản nguồn.

Trong quá trình nâng cấp chính, nếu phiên bản nguồn của thiết bị vCenter Server được định cấu hình với nhiều mạng thứ cấp khác với VCHA NIC, thì phiên bản vCenter Server đích sẽ không giữ lại các mạng thứ cấp ngoài VCHA NIC. Nếu phiên bản nguồn được định cấu hình với nhiều NIC là một phần của nhóm cổng DVS, cấu hình NIC sẽ không được giữ nguyên trong quá trình nâng cấp. Các cấu hình cho các phiên bản thiết bị vCenter Server là một phần của nhóm cổng tiêu chuẩn sẽ được giữ nguyên.

Cách giải quyết: Hiện không có. Định cấu hình mạng phụ theo cách thủ công trong phiên bản thiết bị vCenter Server đích.

  • Sau khi nâng cấp hoặc di chuyển vCenter Server với external Platform Services Controller, nếu người dùng sử dụng Active Directory để xác thực thì họ sẽ mất quyền truy cập vào phiên bản vCenter Server mới được nâng cấp.

Sau khi nâng cấp hoặc di chuyển vCenter Server với external Platform Services Controller, nếu vCenter Server vừa được nâng cấp không được kết hợp với miền Active Directory. Khi đó người dùng sử dụng Active Directory để xác thực sẽ mất quyền truy cập vào phiên bản vCenter Server.

Cách giải quyết: Hãy xác minh rằng phiên bản vCenter Server mới đã được kết nối với miền Active Directory.  Xem thêm bài viết trong Knowledge Base: https://kb.vmware.com/s/article/2118543

  • Di chuyển vCenter Server trong Windows với external Platform Services Controller bằng cơ sở dữ liệu Oracle không thành công.

Nếu các chuỗi không phải ASCII xuất hiện trong bảng sự kiện và tác vụ Oracle, thì quá trình di chuyển có thể không thành công khi xuất dữ liệu sự kiện và tác vụ. Khi đó, thông báo lỗi sau sẽ xuất hiện: UnicodeDecodeError.

Cách giải quyết: Hiện không có.

  • Sau khi nâng cấp máy chủ ESXi, hãy kiểm tra Host Profile để chỉ ra trạng thái không tuân thủ nguyên tắc trong khi các tác vụ khắc phục máy chủ không thành công.

Trạng thái không tuân thủ biểu thị sự không nhất quán giữa profile và máy chủ.

Sự mâu thuẫn này có thể xảy ra vì ESXi 7.0 không cho phép các quy tắc xác nhận quyền sở hữu trùng lặp, nhưng hồ sơ mà người dùng sử dụng có chứa các quy tắc trùng lặp. Ví dụ: nếu người dùng cố gắng sử dụng Host Profile mà họ đã trích xuất từ máy chủ trước khi nâng cấp ESXi 6.5 hoặc ESXi 6.7 lên phiên bản 7.0 và Host Profile chứa bất kỳ quy tắc xác nhận quyền sở hữu trùng lặp nào của quy tắc mặc định của hệ thống, người dùng sẽ có thể gặp sự cố.

Cách giải quyết:

  1. Xóa mọi quy tắc xác nhận quyền sở hữu trùng lặp của quy tắc mặc định của hệ thống khỏi tài liệu Host Profile.
  2. Kiểm tra tình trạng tuân thủ nguyên tắc.
  3. Khắc phục tình trạng máy chủ.
  4. Nếu các bước trước đó không có tác dụng, hãy khởi động lại máy chủ.
  • Thông báo lỗi hiển thị trong vCenter Server Management Interface

Sau khi cài đặt hoặc nâng cấp lên vCenter Server 7.0, khi người dùng điều hướng đến bảng Cập nhật trong vCenter Server Management Interface, màn hình sẽ xuất hiện thông báo lỗi “Kiểm tra URL và thử lại”. Thông báo lỗi không ngăn người dùng sử dụng các chức năng trong bảng Cập nhật và họ vẫn có thể xem, hiển thị và cài đặt bất kỳ bản cập nhật nào có sẵn.

Cách giải quyết: Hiện không có.

Các vấn đề về tính năng bảo mật

  • Máy ảo được mã hóa không thể bật nguồn khi phần mềm HA-enabled Trusted Cluster của máy chủ chưa được kiểm tra.

Trong VMware® vSphere Trust Authority ™, nếu người dùng đã bật HA trên Trusted Cluster và một hoặc nhiều máy chủ trong cụm không xác thực được thì máy ảo được mã hóa không thể bật nguồn.

Cách giải quyết: Xóa hoặc sửa tất cả các máy chủ không xác thực được khỏi Trusted Cluster.

  • Máy ảo được mã hóa không thể bật nguồn khi DRS-enabled Trusted Cluster chứa máy chủ chưa được kiểm tra.

Trong VMware® vSphere Trust Authority ™, nếu người dùng đã bật DRS trên Trusted Cluster và một hoặc nhiều máy chủ trong cụm không xác thực được, DRS có thể cố gắng bật máy ảo được mã hóa trên máy chủ chưa được kiểm tra trong cụm. Thao tác này sẽ giúp đưa máy ảo vào trạng thái bị khóa.

Cách giải quyết: Xóa hoặc sửa chữa tất cả các máy chủ không xác thực được từ Trusted Cluster.

  • Không thể di chuyển hoặc nhân bản các máy ảo được mã hóa trên các phiên bản vCenter Server khi dùng vSphere Client.

Nếu người dùng cố gắng di chuyển hoặc sao chép một máy ảo được mã hóa trên các phiên bản vCenter Server bằng vSphere Client, thao tác không thành công với thông báo lỗi sau: “The operation is not allowed in the current state.” (“Thao tác không được cho phép thực hiện ở trạng thái hiện tại.”)

Cách giải quyết: Người dùng phải sử dụng các API vSphere để di chuyển hoặc sao chép các máy ảo được mã hóa trên các phiên bản vCenter Server.

Các vấn đề về mạng

  • Giảm thông lượng trong hiệu suất mạng trên Intel 82599 / X540 / X550 NICs

Tính năng queue-pair mới được thêm vào trình điều khiển ixgben để cải thiện hiệu suất mạng trên các NIC của dòng Intel 82599EB / X540 / X550 giúp làm giảm thông lượng trong một số khối lượng công việc trong vSphere 7.0 so với vSphere 6.7.

Cách giải quyết: Để đạt được hiệu suất mạng tương tự như vSphere 6.7, người dùng có thể vô hiệu hóa queue-pair với một tham số module. Để tắt queue-pair, hãy chạy lệnh:

# esxcli system module parameters set -p “QPair=0,0,0,0…” -m ixgben

Sau khi chạy lệnh, hãy khởi động lại.

  • Máy ảo thông lượng cao có thể bị suy giảm hiệu suất mạng khi Network I/O Control (NetIOC) được kích hoạt.

Máy ảo yêu cầu thông lượng mạng cao có thể bị suy giảm thông lượng khi nâng cấp từ vSphere 6.7 lên vSphere 7.0 với NetIOC được kích hoạt.

Cách giải quyết: Điều chỉnh cài đặt ethernetx.ctxPerDev để kích hoạt đa không gian.

  • Lưu lượng IPv6 không thể đi qua các cổng VMkernel bằng IPsec

Khi người dùng di chuyển các cổng VMkernel từ nhóm cổng này sang nhóm cổng khác, lưu lượng IPv6 không đi qua các cổng VMkernel sử dụng IPsec.

Cách giải quyết: Xóa liên kết bảo mật IPsec (SA) khỏi máy chủ bị ảnh hưởng, sau đó áp dụng lại SA. Để tìm hiểu cách thiết lập và xóa IPsec SA, hãy xem thêm tài liệu vSphere Security.

  • Hiệu suất mạng ESX cao hơn với mức sử dụng CPU tăng lên một phần.

Hiệu suất mạng ESX có thể tăng lên khi sử dụng một phần CPU.

Cách giải quyết: Loại bỏ và thêm giao diện mạng chỉ với 1 hàng đợi điều phối rx. Ví dụ:

esxcli network ip interface remove –interface-name=vmk1

esxcli network ip interface add –interface-name=vmk1 –num-rxqueue=1

  • VM có thể mất lưu lượng Ethernet sau khi hot-add, hot-remove hoặc lưu trữ vMotion.

Máy ảo có thể ngừng nhận lưu lượng Ethernet sau khi hot-add, hot-remove hoặc lưu trữ vMotion. Sự cố này ảnh hưởng đến các máy ảo uplink của VNIC đã bật SR-IOV. NIC ảo của PVRDMA đã thể hiện vấn đề này khi uplink của mạng ảo là một Mellanox RDMA tiềm năng với namespace là NIC và RDMA  được định cấu hình.

Cách giải quyết: Người dùng có thể hot-add, hot-remove các card mạng NIC Ethernet bị ảnh hưởng của máy ảo để khôi phục lưu lượng. Trên hệ điều hành khách Linux, việc khởi động lại mạng cũng có thể giải quyết được sự cố. Nếu các Cách giải quyết này không có tác dụng, người dùng có thể khởi động lại máy ảo để khôi phục kết nối mạng.

  • Thay đổi địa chỉ IP cho phần mềm VCSA được triển khai với địa chỉ IP tĩnh yêu cầu người dùng tạo bản ghi DNS trước.

Với sự ra đời của DDNS, bản cập nhật bản ghi DNS chỉ hoạt động đối với phần mềm VCSA được triển khai với mạng được định cấu hình DHCP. Trong quá trình thay đổi địa chỉ IP của vCenter server qua VAMI, lỗi sẽ hiển thị như sau:

The specified IP address does not resolve to the specified hostname. 

(Địa chỉ IP được chỉ định không phân giải thành tên máy chủ được chỉ định.)

Cách giải quyết: Có hai Cách giải quyết khả thi.

  1. Tạo mục nhập DNS bổ sung có cùng FQDN và địa chỉ IP mong muốn. Đăng nhập vào VAMI và làm theo các bước để thay đổi địa chỉ IP.
  2. Đăng nhập vào VCSA bằng ssh. Thực thi đoạn mã sau:

./opt/vmware/share/vami/vami_config_net

Sử dụng tùy chọn số 6 để thay đổi địa chỉ IP của eth0. Sau khi thay đổi, hãy thực thi tập lệnh sau:

./opt/likewise/bin/lw-update-dns

Khởi động lại tất cả các dịch vụ trên VCSA để cập nhật thông tin IP trên máy chủ DNS.

  • Có thể mất vài giây để xóa NSX Distributed Virtual Port Group (NSX DVPG) sau khi xóa logical switch tương ứng trong NSX Manager.

Khi số lượng logical switch tăng lên, người dùng có thể mất nhiều thời gian hơn để xóa NSX DVPG trong vCenter Server sau khi xóa logical switch tương ứng trong NSX Manager. Trong môi trường có 12000 logical switch, người dùng sẽ mất khoảng 10 giây để xóa NSX DVPG khỏi vCenter Server.

Cách giải quyết: Hiện không có.

  • Nếu một số lượng lớn các nhóm cổng NSX Distributed Virtual được tạo ra, Hostd sẽ hết bộ nhớ và không hoạt động.

Trong vSphere 7.0, các nhóm cổng NSX Distributed Virtual tiêu thụ lượng bộ nhớ lớn hơn rất nhiều so với các mạng opaque. Vì lý do này, các nhóm cổng NSX Distributed Virtual không thể hỗ trợ cùng một quy mô so với mạng opaque với cùng một lượng bộ nhớ.

Cách giải quyết: Để hỗ trợ việc sử dụng các nhóm cổng NSX Distributed Virtual, hãy tăng dung lượng bộ nhớ trong các máy chủ ESXi. Nếu người dùng xác minh rằng hệ thống của mình có đủ bộ nhớ để hỗ trợ máy ảo, người dùng có thể trực tiếp tăng bộ nhớ của hostd bằng cách sử dụng lệnh sau.

localcli –plugin-dir /usr/lib/vmware/esxcli/int/ sched group setmemconfig –group-path host/vim/vmvisor/hostd –units mb –min 2048 –max 2048

Lưu ý rằng điều này sẽ khiến hostd sử dụng bộ nhớ (thường được dành riêng cho các máy ảo) trong môi trường của người dùng. Điều này có thể ảnh hưởng đến việc giảm lượng máy ảo mà máy chủ ESXi của người dùng có thể hỗ trợ.

  • DRS không thể khởi chạy vMotion một cách chính xác nếu mạng đặt trước được định cấu hình trên máy ảo.

Nếu việc mạng đặt trước được cấu hình trên một máy ảo, DRS dự kiến chỉ di chuyển máy ảo đó đến một máy chủ có thể đáp ứng các yêu cầu đã chỉ định. Trong một cụm có các nút NSX transport, nếu một số nút transport tham gia vùng vận chuyển bằng NSX-T Virtual Distributed Switch (N-VDS) và các nút khác bằng vSphere Distributed Switch (VDS) 7.0, DRS có thể khởi chạy vMotion sai cách. Người dùng có thể gặp sự cố này khi:

  • Máy ảo kết nối với bộ logical switch NSX được cấu hình với mạng đặt trước.
  • Một số nút transport tham gia vùng truyền tải bằng N-VDS và những nút còn lại tham gia bằng VDS 7.0 hoặc, các nút transport tham gia vùng truyền tải thông qua các phiên bản VDS 7.0 đều khác nhau.

Cách giải quyết: Làm cho tất cả các nút transport tham gia vùng truyền tải bằng N-VDS hoặc cùng một phiên bản VDS 7.0.

  • Khi thêm VMkernel NIC (vmknic) vào nhóm cổng NSX, vCenter Server báo lỗi “Connecting VMKernel adapter to a NSX Portgroup on a Stateless host is not a supported operation. Please use Distributed Port Group instead.” (“Kết nối bộ điều hợp VMKernel với NSX Portgroup trên máy chủ Stateless là hành động không được hỗ trợ. Vui lòng sử dụng Distributed Port Group để thay thế.”)

  • Đối với stateless ESXi trên Distributed Virtual Switch (DVS), vmknic trên nhóm cổng NSX đã bị chặn. Thay vào đó, người dùng phải sử dụng Distributed Port Group.
  • Đối với stateful ESXi trên DVS, vmknic trên nhóm cổng NSX được hỗ trợ, nhưng vSAN có thể gặp sự cố nếu nó đang sử dụng vmknic trên nhóm cổng NSX.

Cách giải quyết: Sử dụng Distributed Port Group trên cùng một DVS.

  • Kích hoạt SRIOV từ vCenter đối với QLogic 4x10GE QL41164HFCU CNA có thể không thành công.

Nếu bạn điều hướng đến hộp thoại Edit Settings cho bộ điều hợp mạng vật lý và cố gắng bật SR-IOV, hoạt động có thể không thành công khi sử dụng QLogic 4x10GE QL41164HFCU CNA. Việc cố gắng kích hoạt SR-IOV có thể khiến máy chủ ESXi ngừng chạy mạng.

Cách giải quyết: Sử dụng lệnh sau trên máy chủ ESXi để bật SRIOV:

esxcfg-module

  • Vấn đề mới: vCenter Server không hoạt động nếu các máy chủ trong một cụm sử dụng Distributed Resource Scheduler (DRS) để tham gia mạng NSX-T bằng Virtual Distributed Switch (VDS) khác hoặc kết hợp giữa NSX-T Virtual Distributed Switch (NVDS) và VDS.

Trong vSphere 7.0, khi sử dụng mạng NSX-T trên vSphere VDS với một cluster DRS, nếu các máy chủ không tham gia vùng truyền tải NSX bởi cùng một VDS hoặc NVDS, nó có thể khiến vCenter Server bị lỗi.

Cách giải quyết: Yêu cầu các máy chủ trong một cluster DRS tham gia vùng truyền tải NSX bằng cách sử dụng cùng một VDS hoặc NVDS.

Biên dịch bởi Tuyết Hiền – Pacisoft.com

Tagged: