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

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

Ở bài viết trước, chúng ta đã cùng nhau tìm hiểu 3 nhóm đầu tiên trong danh sách các vấn đề thường gặp trong quá trình nâng cấp và cài đặt vSphere 7.0. Và trong bài viết ngày hôm nay, VMware sẽ mang đến 3 nhóm vấn đề tiếp theo để chúng ta cùng thảo luận cũng như tìm phương án giải quyết cho chúng.

Các vấn đề về bộ nhớ dữ liệu

  • Kho dữ liệu trong hệ thống tập tin VMFS không được tự động gắn kết sau khi hot remove và hot insert ổ đĩa trên máy chủ HPE Gen10 có bộ điều khiển SmartPQI..

Khi ổ đĩa SATA trên máy chủ HPE Gen10 có bộ điều khiển SmartPQI không có thiết bị mở rộng được hot remove và hot insert trở lại khoang đĩa khác của cùng một máy hoặc khi nhiều đĩa được hot remove và hot insert theo một thứ tự khác, đôi khi là một tên cục bộ mới được gán cho đĩa. Kho dữ liệu VMFS trên đĩa đó xuất hiện dưới dạng ảnh chụp nhanh và sẽ không được tự động gắn lại vì tên thiết bị đã thay đổi.

Cách giải quyết: Hiện không có. Bộ điều khiển SmartPQI không hỗ trợ thao tác hot remove và hot insert không theo thứ tự.

  • Cài đặt loglevel cho trình điều khiển nvme_pcie không thành công và xuất hiện lỗi.

Khi người dùng cài đặt loglevel cho trình điều khiển nvme_pcie bằng lệnh  esxcli nvme driver loglevel set -l <log level>, thao tác này sẽ không thành công và xuất hiện thông báo lỗi như sau:

Failed to set log level 0x2.

Lệnh này được giữ lại cho việc xem xét khả năng tương thích với trình điều khiển NVMe, nhưng nó không được hỗ trợ cho trình điều khiển nvme_pcie.

Cách giải quyết: Hiện không có. Điều kiện này sẽ tồn tại cho đến khi tính năng nvme_pcie được bật.

  • ESXi có thể kết thúc I/O tới các thiết bị NVMeOF do lỗi trên tất cả các đường dẫn đang hoạt động.

Đôi khi, tất cả các đường dẫn hoạt động đến thiết bị NVMeOF đăng ký I/O bị lỗi do sự cố liên kết hoặc tùy thuộc vào trạng thái bộ điều khiển. Nếu trạng thái của một trong các đường dẫn chuyển thành Dead, thì chế độ High Performance Plug-in (HPP) có thể không chọn một đường dẫn khác nếu nó hiển thị số lượng lỗi lớn. Từ đó kết quả nhận được là I/O không thành công.

Cách giải quyết: Tắt tùy chọn cấu hình /Misc/HppManageDegradedPaths để gỡ chặn I/O.

  • Kiểm tra VOMA trên kho dữ liệu VMFS dựa trên NVMe không thành công vì xuất hiện lỗi.

Việc kiểm tra VOMA không được hỗ trợ cho các kho dữ liệu VMFS dựa trên NVMe và sẽ không thành công với lỗi sau:

ERROR: Failed to reserve device. Function not implemented 

Ví dụ:

# voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>

Running VMFS Checker version 2.1 in check mode

Initializing LVM metadata, Basic Checks will be done

Checking for filesystem activity

Performing filesystem liveness check..|Scanning for VMFS-6 host activity (4096 bytes/HB, 1024 HBs).

ERROR: Failed to reserve device. Function not implemented

Aborting VMFS volume check

VOMA failed to check device : General Error

Cách giải quyết: Hiện không có. Nếu người dùng cần phân tích siêu dữ liệu VMFS, hãy thu thập nó bằng cách sử dụng tùy chọn -l và chuyển cho bộ phận hỗ trợ khách hàng của VMware. Lệnh để thu thập kết xuất là:

voma -l -f dump -d /vmfs/devices/disks/:<partition#> 

  • Sử dụng máy ảo đã cấu hình lại API đính kèm First Class Disk được mã hóa vào máy ảo được mã hóa có thể không thành công với lỗi sau xuất hiện.

Nếu một FCD và một máy ảo được mã hóa bằng các khóa mật mã khác nhau, thì việc người dùng đính kèm FCD mã hóa vào máy ảo đã được mã hóa bằng cách sử dụng VM reconfigure API có thể không thành công với thông báo lỗi:

Cannot decrypt disk because key or password is incorrect.

Cách giải quyết: Sử dụng attachDisk API thay vì VM reconfigure API để đính kèm FCD được mã hóa vào máy ảo mã hóa.

  • Máy chủ ESXi có thể ở trạng thái không phản hồi nếu phạm vi non-head của kho dữ liệu VMFS kéo dài của nó chuyển sang trạng thái Permanent Device Loss (PDL).

Sự cố này không xảy ra khi phạm vi non-head của kho dữ liệu VMFS được mở rộng bị lỗi cùng với phạm vi phần đầu. Trong trường hợp này, toàn bộ kho dữ liệu đều không thể truy cập được và không còn cho phép I/Os nữa.

Ngược lại, khi chỉ một phần non-head bị lỗi, nhưng phần head vẫn có thể tiếp cận được, thì heartbeat trong kho dữ liệu dường như bình thường. Và I/Os giữa máy chủ và kho dữ liệu vẫn tiếp tục. Tuy nhiên, bất kỳ I/O nào phụ thuộc vào  phạm vi non-head cũng đều thất bại. Các giao dịch I/O khác có thể tích trữ trong khi chờ đợi I/O không hoạt động để giải quyết và đưa máy chủ chuyển sang trạng thái không phản hồi.

cách giải quyết: Khắc phục tình trạng PDL trong phạm vi non-head để giải quyết vấn đề này.

  • Sau khi khôi phục từ các điều kiện APD hoặc PDL, kho dữ liệu VMFS với hỗ trợ được kích hoạt từ các đĩa ảo được phân nhóm có thể vẫn không truy cập được.

Người dùng chỉ có thể gặp sự cố này trên các kho dữ liệu hỗ trợ virtual disk được kích hoạt. Khi kho dữ liệu khôi phục từ tình trạng All Paths Down (APD) hoặc Permanent Device Loss (PDL), nó vẫn không thể truy cập được. Trong VMkernel log có thể hiển thị nhiều thông báo lỗi của SCSI3 reservation conflict tương tự như sau:

2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: Reservation conflict retries 544 for command 0x45ba814b8340 (op: 0x89) to device “naa.624a9370b97601e346f64ba900024d53”

Sự cố có thể xảy ra do máy chủ ESXi tham gia vào cụm mất các đặt chỗ SCSI cho kho dữ liệu và không phải lúc nào cũng có thể tự động yêu cầu lại chúng sau khi kho dữ liệu phục hồi.

Cách giải quyết: Đăng ký reservation theo cách thủ công bằng lệnh sau:

vmkfstools -L registerkey /vmfs/devices/disks/<device name>

trong đó <device name> là tên của thiết bị tạo ra kho dữ liệu đó.

  • Virtual NVMe Controller là bộ điều khiển đĩa mềm mặc định cho hệ điều hành khách Windows 10.

Virtual NVMe Controller là bộ điều khiển đĩa mềm mặc định cho các hệ điều hành khách sau đây khi sử dụng phiên bản Hardware 15 trở lên:

Windows 10

Windows Server 2016

Windows Server 2019

Một số tính năng có thể không khả dụng khi sử dụng Virtual NVMe Controller. Truy cập https://kb.vmware.com/s/article/2147714 để biết thêm thông tin.

Lưu ý: Một số client sử dụng giao thức mặc định trước đây của LSI Logic SAS. Điều này bao gồm client máy chủ ESXi và PowerCLI.

Cách giải quyết: Nếu người dùng cần các tính năng không có sẵn trên Virtual NVMe, hãy chuyển sang sử dụng VMware Paravirtual SCSI (PVSCSI) hoặc LSI Logic SAS. Để biết thông tin về cách sử dụng VMware Paravirtual SCSI (PVSCSI), hãy xem thêm tại bài viết https://kb.vmware.com/s/article/1010398.

 

  • Sau khi nâng cấp máy chủ ESXi lên vSphere 7.0, với sự hiện diện của các quy tắc xác nhận quyền sở hữu cốt lõi trùng lặp có thể gây ra hành vi lỗi.

Quy tắc xác nhận quyền sở hữu xác định plugin đa hệ số, chẳng hạn như NMP, HPP, v.v., sở hữu đường dẫn đến một thiết bị lưu trữ cụ thể. Mặc dù ESXi 7.0 không hỗ trợ các quy tắc xác nhận quyền sở hữu trùng lặp, nhưng máy chủ ESXi 7.0 cũng sẽ không thông báo cho người dùng nếu họ thêm các quy tắc trùng lặp vào các quy tắc xác nhận quyền sở hữu hiện có được kế thừa thông qua quá trình nâng cấp từ phiên bản cũ. Do sử dụng các quy tắc trùng lặp, thiết bị lưu trữ có thể bị các plugin nằm ngoài ý muốn xác nhận quyền sở hữu, điều này có thể gây ra kết quả không mong muốn.

Cách giải quyết: Không sử dụng các quy tắc xác nhận quyền sở hữu cốt lõi trùng lặp. Trước khi thêm quy tắc xác nhận quyền sở hữu mới, hãy xóa mọi quy tắc xác nhận quyền sở hữu phù hợp hiện có.

  • Một truy vấn CNS với bộ lọc ở trong trạng thái tuân thủ có thể mất nhiều thời gian hơn bình thường để hoàn thành công việc của nó

API CNS QueryVolume cho phép người dùng lấy thông tin về các tập CNS, chẳng hạn như tình trạng của tập cũng như trạng thái tuân thủ. Khi người dùng kiểm tra tình trạng tuân thủ của từng khối volume riêng lẻ, họ sẽ nhanh chóng thu được kết quả. Tuy nhiên, khi người dùng gọi API CNS QueryVolume để kiểm tra trạng thái tuân thủ của nhiều volume (vài chục hoặc hàng trăm), truy vấn có thể thực hiện nhưng chậm.

Cách giải quyết: Tránh sử dụng các truy vấn hàng loạt. Khi người dùng cần các truy vấn có trạng thái tuân thủ, hãy truy vấn từng tập một hoặc giới hạn số lượng trong API truy vấn ở mức 20 hoặc ít hơn. Trong khi sử dụng truy vấn, hãy tránh chạy các thao tác CNS khác để có được hiệu suất tốt nhất.

  • Vấn đề mới: Khối lượng CNS đã xóa có thể tạm thời xuất hiện như hiện có trong giao diện CNS UI.

Sau khi người dùng xóa đĩa FCD có hỗ trợ ổ đĩa CNS, ổ đĩa đó có thể vẫn hiển thị như hiện có trong giao diện CNS UI. Tuy nhiên, việc người dùng cố gắng xóa tập tin này sẽ không thành công, sẽ có thông báo lỗi hiển thị tương tự như sau:

The object or item referred to could not be found.

cách giải quyết: Đồng bộ hóa đầy đủ trong lần kế tiếp sẽ giải quyết sự không nhất quán và cập nhật chính xác giao diện CNS UI.

  • Vấn đề mới: Việc cố gắng đính kèm nhiều volume CNS vào cùng một nhóm đôi khi không thành công với lỗi xuất hiện.

Khi người dùng đính kèm đồng thời nhiều volume vào cùng một pod, thao tác đính kèm có thể chọn cùng một khe điều khiển. Kết quả dẫn đến chỉ có một trong các thao tác đó thành công, trong khi các thao tác gắn kết volume khác đều thất bại.

Cách giải quyết: Sau khi Kubernetes thử lại, thao tác sẽ không thành công đó sẽ trở nên thành công nếu có sẵn khe điều khiển trên VM node.

  • Ở một số trường hợp nhất định, trong khi thao tác CNS không thành công nhưng trạng thái tác vụ xuất hiện lại là thành công trong vSphere Client.

Điều này có thể xảy ra, chẳng hạn như khi bạn sử dụng chính sách lưu trữ không tuân thủ để tạo tập tin CNS. Thao tác không thành công, trong khi vSphere Client hiển thị trạng thái tác vụ là thành công.

Cách giải quyết: Trạng thái tác vụ thành công trong vSphere Client không đảm bảo rằng hoạt động CNS đã thành công. Để đảm bảo thao tác thành công, hãy xác minh kết quả của nó. 

  • Thao tác xóa không thành công đối với volume trên CNS có thể khiến tập không bị xóa trên kho dữ liệu vSphere

Sự cố này có thể xảy ra khi CNS Delete API cố gắng xóa một persistent volume (volume này vẫn được đính kèm với một nhóm). Ví dụ: khi người dùng xóa  namespace của Kubernetes, nơi hoạt động của pod. Kết quả cho thấy persistent volume sẽ bị xóa khỏi CNS và thao tác truy vấn CNS không trả về tập. Tuy nhiên, volume tiếp tục nằm trên kho dữ liệu và không thể bị xóa thông qua các hoạt động lặp đi lặp lại trên CNS Delete API.

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

Các vấn đề về vCenter Server và vSphere Client

  • Các nhà cung cấp chuyển sang chế độ ngoại tuyến sau khi thay đổi PNID.

Khi người dùng thay đổi địa chỉ IP vCenter (thay đổi PNID), các nhà cung cấp dịch vụ đã đăng ký sẽ chuyển sang chế độ ngoại tuyến.

Cách giải quyết: Đăng ký lại dịch vụ các của nhà cung cấp.

  • Quá trình di chuyển cross vCenter của một máy ảo không thành công với lỗi xuất hiện.

Khi sử dụng cross vCenter vMotion để di chuyển bộ lưu trữ và máy chủ của máy ảo sang một phiên bản máy chủ vCenter khác, người dùng có thể nhận được lỗi “The operation is not allowed in the current state”.

Lỗi này xuất hiện trong UI wizard sau bước Host Selection và trước bước Datastore Selection, trong trường hợp máy ảo có chính sách lưu trữ được chỉ định chứa các quy tắc host-based như mã hóa hoặc bất kỳ quy tắc lọc IO nào khác.

Cách giải quyết: Gán máy ảo và các đĩa của nó cho một chính sách lưu trữ không có quy tắc host-based. Người dùng có thể cần giải mã máy ảo nếu máy ảo nguồn được mã hóa. Sau đó thử lại hành động cross vCenter vMotion.

  • Thông tin về Storage Sensors trong tab Hardware Health hiển thị các giá trị không chính xác trên giao diện  vCenter UI, máy chủ UI và MOB.

Khi người dùng điều hướng đến Host > Monitor > Hardware Health > Storage Sensors trên vCenter UI, thông tin lưu trữ sẽ hiển thị các giá trị không chính xác hoặc không xác định. Vấn đề tương tự cũng được thấy trên máy chủ UI và đường dẫn MOB: “runtime.hardwareStatusInfo.storageStatusInfo”.

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

  • Cài đặt nâng cao máy chủ vSphere UI hiển thị product locker location hiện tại là trống và chế độ mặc định cũng là trống.

Cài đặt nâng cao máy chủ vSphere UI hiển thị product locker location hiện tại là trống và chế độ mặc định cũng là trống. Điều này mang lại sự không nhất quán vì symlink của vị trí sản phẩm thực tế được tạo ra và có hiệu lực. Từ đó gây ra sự nhầm lẫn cho người dùng và không thể sửa lỗi mặc định từ  UI.

Cách giải quyết: Người dùng có thể sử dụng lệnh esxcli trên máy chủ để sửa lỗi mặc định product locker location hiện tại như bên dưới.

  1. Xóa cài đặt Product Locker Location hiện có bằng: “esxcli system settings advanced remove -o ProductLockerLocation”
  2.  Thêm lại cài đặt Product Locker Location với giá trị mặc định thích hợp:

2a. Nếu ESXi hiện tại là một bản được cài đặt đầy đủ, thì giá trị mặc định là “/ locker / pack / vmtoolsRepo” export PRODUCT_LOCKER_DEFAULT = “/ locker / pack / vmtoolsRepo”

2b. Nếu ESXi là cấu hình PXEboot (chẳng hạn như tự động triển khai), thì giá trị mặc định là: “/ vmtoolsRepo” export PRODUCT_LOCKER_DEFAULT = “/ vmtoolsRepo”

Chạy lệnh sau để tự động tìm ra vị trí: export PRODUCT_LOCKER_DEFAULT = `readlink / productLocker`

Thêm cài đặt: esxcli system settings advanced add -d “Path to VMware Tools repository” -o ProductLockerLocation -t string -s $ PRODUCT_LOCKER_DEFAULT

Người dùng có thể kết hợp tất cả các bước trên trong phần 2 bằng cách sử dụng một lệnh duy nhất:

esxcli system settings advanced add -d “Path to VMware Tools repository” -o ProductLockerLocation -t string -s `readlink /productLocker`

  • Phiên bản Software-Defined Data Center (SDDC) vCenter Server đã được liên kết xuất hiện trong on-premise vSphere Client nếu vCenter Cloud Gateway được liên kết với SDDC.

Khi một vCenter Cloud Gateway được triển khai trong cùng một môi trường với một on-premise vCenter Server và được liên kết với một SDDC, SDDC vCenter Server sẽ xuất hiện trong vSphere Client tại chỗ. Đây là hành vi ngoài ý muốn và SDDC vCenter Server đã được liên kết nên bỏ qua. Tất cả các hoạt động liên quan đến SDDC vCenter Server được liên kết phải được thực hiện trên vSphere Client đang chạy trong vCenter Cloud Gateway.

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

Các vấn đề về quản lý máy ảo

  • Phần postcustomization của tập lệnh customization chạy trước guest customization

Khi người dùng chạy tập lệnh guest customization cho hệ điều hành khách Linux, phần precustomization của tập lệnh customization được xác định trong phần đặc tả customization sẽ chạy trước guest customization và phần postcustomization sẽ chạy sau đó. Nếu người dùng bật Cloud-Init trong hệ điều hành khách của máy ảo, phần postcustomization sẽ chạy trước phần tùy chỉnh do sự cố đã xuất hiện trong Cloud-Init.

Giải pháp: Tắt Cloud-Init và sử dụng standard guest customization.

  • Các hoạt động di chuyển nhóm trong vSphere vMotion, Storage vMotion và vMotion không có bộ nhớ lưu trữ chia sẻ không thành công với lỗi xuất hiện.

Khi người dùng thực hiện các hoạt động di chuyển nhóm trên máy ảo với nhiều đĩa mềm và ảnh chụp nhanh nhiều cấp độ, các hoạt động có thể không thành công với lỗi com.vmware.vc.GenericVmConfigFault Failed waiting for data. Error 195887167. Connection closed by remote host, possibly due to timeout.

Cách giải quyết: Lần lượt thử lại các thao tác di chuyển trên các máy ảo bị lỗi.

  • Triển khai mẫu OVF hoặc OVA từ URL không thành công với lỗi 403 Forbidden error.

Các URL chứa tham số truy vấn HTTP không được hỗ trợ. Ví dụ: http://webaddress.com?file=abc.ovf  hoặc các URL S3 được Amazon ký sẵn

Giải pháp: Tải tệp tin xuống và triển khai chúng từ hệ thống tệp cục bộ.

  • Nhập hoặc triển khai các tệp OVF cục bộ có chứa các ký tự không phải ASCII trong tên của chúng có thể không thành công do xuất hiện lỗi.

Khi nhập các tệp .ovf cục bộ có chứa các ký tự không phải ASCII trong tên của chúng, người dùng có thể nhận được lỗi 400 Bad Request Error. Khi người dùng sử dụng các tệp .ovf như vậy để triển khai một máy ảo trong vSphere Client, quá trình triển khai sẽ dừng lại ở 0%. Do đó, người dùng có thể nhận được lỗi 400 Bad Request Error hoặc 500 Internal Server Error.

Cách giải quyết:

  1. Xóa các ký tự không phải ASCII khỏi tên tệp .ovf và .vmdk.
  • Để chỉnh sửa tệp .ovf, hãy mở tệp bằng trình chỉnh sửa văn bản.
  • Tìm kiếm tên tệp .vmdk non-ASCII và thay đổi nó thành ASCII.
  1.  Nhập hoặc triển khai lại các tệp đã lưu.
  • Vấn đề mới: Mức độ thứ ba của các nested object trong cùng một thư mục máy ảo không hiển thị

Thực hiện các bước sau:

  1. Điều hướng đến trung tâm dữ liệu và tạo một thư mục máy ảo.
  2. Trong thư mục máy ảo, hãy tạo một thư mục máy ảo nested.
  3. Trong thư mục thứ hai, tạo một máy ảo nested, thư mục máy ảo, vApp hoặc VM Template.

Kết quả cho thấy, từ VMs and Templates, người dùng đều không thể nhìn thấy các object trong nested folder thứ ba.

Cách giải quyết: Để xem các object trong nested folder thứ ba, hãy điều hướng đến nested folder thứ hai và chọn tab VM.

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

Tagged: