To have a better experience, please upgrade your IE browser.upgrade
Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
issue version: FusionAccessV100R006C10SPC100
issue identify: after upgraded from V100R005C30 TO V100R006C10SPC100, the issue occured.
October 2017 customer A in Country B has 22 vms can not normally log on through the client, the customer can only log in through the self-help console, FusionAccess shows that the vms are not registered.
(1) View the TrancelogMainService log of the unregistered vms and find that the CBB decryption fails. The decryption failure is due to the inconsistency of SK in the HDC and the SK of the vm.
(2) look at the vm registry table SK information, found the SK or FusionAccessR5 version of the SK. In the evening of 10/24 TAC staff updated the vm SK, theoretically where the SK should be FusionAccessR6 version of the SK.
(3) FusionAccessR6C10SPC100 previous version When updating the SK on the FA, FusionCompute will save the updated SK in the hidden disk of the vm, save the FusionAccess update after the completion of the SK task is completed. After the vm is powered on, the SysPrep process will save the SK in the vm to hide the disk into the registry. The update of the SK task completed FusionA, the vm SK error, suspected SysPrep service is caused by the normal operation, view the vm SysPrep process, found that the process has not started after the vm upgrade and manually unable to start normally.
(4) Manually reinstall HW.SysPrep in the vm.
After reinstalling the SysPrep service is running normally, the vm status
During the upgrade process, the linkclone and fullcopy configuration files will be found on the c drive after the SysPrep is started, and the linkclone will take some time (this takes 5 minutes) due to the FusionCompute id disk. SysPrep needs to loop through the wait, and the unloading failure probability is 5% to 10%; t
manually reinstall all unregistered vm HW.SysPrep, vm can change to the registration state. problem solved.
prevent same problem occur again
exception protection optimization
(1) optimize the upgrade tool prompts, so that the upgrade tool to detect the vm in the running state of SysPrep;
(2) Optimize the task logic of updating SK in FusionAccess:
Currently: SK will be written to the vm after the hidden disk will be considered successful update task.
Improved: the task of updating SK will automatically wake up the vm, the detection of the vm registry SK and HDC database table SK have reached the desired value when the task is successful; update task failure automatically HDC database SK and The values in the vm registry fall back to the pre-update values (the vm registration status does not change and does not affect the normal use of the vm).
upgrade process optimization
(1) This question is missing Checklist, need to refresh the upgrade Checklist. At the same time the optimization has been incorporated into the R6C10SPC001, pre-upgrade version of SysPrep in R6C10SPC001 and later versions do not occur this problem;
(2) upgrade completed in strict accordance with the upgrade instructions to check the status of the vm is normal, and c