FusionSphere PCS 6.5.1.1 Operation Guide (Virtualization Xen To KVM)

FusionSphere PCS
6.5.1.1
Operation Guide (Virtualization
Xen to KVM)PCS（Platform
Cross Service）工具操作指南
（FusionCompute - KVM）
Issue 01
Date 2019-08-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei
and the customer. All or part of the products, services and features described in this document may
not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all
statements, information, and recommendations in this document are provided "AS IS" without
warranties, guarantees or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in
the preparation of this document to ensure accuracy of the contents, but all statements, information,
and recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: https://e.huawei.com
Issue 01 (2019-08-30) Copyright © Huawei Technologies Co., i

Ltd.
FusionSphere PCS
Operation Guide (Virtualization Xen to KVM) About This Document
About This Document
Purpose
This document describes how to obtain, install, operate, and uninstall the Platform Cross
Service (PCS) tool and provides related precautions.
Intended Audience
This document is intended for:
 Switchover planning engineers
 Switchover implementation engineers
 Switchover technical support engineers
 Switchover development engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates an imminently hazardous situation which, if not

avoided, will result in death or serious injury.
Indicates a potentially hazardous situation which, if not

avoided, could result in death or serious injury.

avoided, may result in minor or moderate injury.

avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
NOTICE is used to address practices not related to personal
injury.
Calls attention to important information, best practices and
tips.
NOTE is used to address information not related to personal
injury, equipment damage, and environment deterioration.
FusionSphere PCS
Operation Guide (Virtualization Xen to KVM) About This Document
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Issue 01 (2019-08-30)
This issue is the first official release.
FusionSphere PCS
Operation Guide (Virtualization Xen to KVM) Contents
Contents
About This Document....................................................................................................................ii

1 Overview.........................................................................................................................................1
1.1 Introduction....................................................................................................................................................................1
1.2 Switchover Process Overview........................................................................................................................................1
2 Technical Support.........................................................................................................................3
3 Switchover Service and Risk Precautions................................................................................4
3.1 Introduction to the Switchover Service..........................................................................................................................4
3.1.1 Information Collection and Feasibility Analysis.........................................................................................................4
3.1.2 Switchover Plan and Solution Design.........................................................................................................................4
3.1.3 Core Service Switchover Test......................................................................................................................................5
3.2 Switchover Risk..............................................................................................................................................................5
4 Switchover Restrictions................................................................................................................6
4.1 Networking.....................................................................................................................................................................6
4.2 Switchover Network Restrictions...................................................................................................................................6
4.3 Switchover Pre-implementation Requirements..............................................................................................................7
4.4 Switchover Implementation Requirements....................................................................................................................7
4.5 Impact on Services.........................................................................................................................................................7
4.6 Function Restrictions......................................................................................................................................................9
5 Compatibility List.......................................................................................................................12
5.1 Platform Compatibility.................................................................................................................................................12
5.2 Guest OS Support Policies...........................................................................................................................................12
6 Installation and Deployment....................................................................................................13

6.1 Software Obtaining.......................................................................................................................................................13
6.2 Switchover Software Specifications.............................................................................................................................14
6.3 Installation and Deployment.........................................................................................................................................14
6.3.1 Preparing for the FusionCompute 6.5.0 Environment...............................................................................................14
6.3.2 Upgrading the Xen Platform to V100R006C10SPH108...........................................................................................15
6.3.3 Configuring the MAC Address Segment...................................................................................................................16
6.3.4 Configuring Dual-site Management to Allow Source and Target Platforms to Access VIMS.................................16
6.3.5 Deploying Controller and Agent VMs on the Target Platform..................................................................................18
FusionSphere PCS
6.3.6 (Optional) Configuring a Backup Server..................................................................................................................19

6.3.7 Configuring the Cloud Platform................................................................................................................................20
6.3.8 Registering an Agent VM..........................................................................................................................................23
7 System Configuration.................................................................................................................25
7.1 Managing Switchover Obstacle Items..........................................................................................................................25
7.2 Configuring Password Policy.......................................................................................................................................25
7.3 Configuring the Login Timeout Period........................................................................................................................26
7.4 Viewing System Tasks..................................................................................................................................................27
8 VM Drill and Switchover..........................................................................................................28

8.1 Registering the VM to Be Switched over.....................................................................................................................28
8.2 Creating a Switchover Task..........................................................................................................................................29
8.3 Performing Switchover Drill........................................................................................................................................33
8.4 Performing a VM Switchover......................................................................................................................................34
8.5 Rolling Back the Switchover........................................................................................................................................35
8.6 Completing Switchover................................................................................................................................................35
8.7 Adding Hosts on the Xen Platform to the KVM Platform...........................................................................................35
9 Operations After Finish Confirmation....................................................................................37

9.1 Deleting PCS Controller and Agent VMs....................................................................................................................37
9.2 Disabling Dual-site Management.................................................................................................................................37
9.2.1 In the Xen Platform...................................................................................................................................................37
9.2.2 Deleting Dual-site Management Configuration........................................................................................................38
9.2.3 Restoring Configurations on the FusionCompute V100R006C10SPH108 Platform................................................38
9.3 Converting the Disk Format from VHD to RAW.........................................................................................................38
9.3.1 Conversion By VM....................................................................................................................................................38
9.3.2 Conversion By Disk..................................................................................................................................................39
9.3.3 Restoring Configurations on the FusionCompute 6.5.0 Platform.............................................................................39
9.3.4 Adding the Host or VRM Node (Deployed on Physical Servers) Where the VRM VM Is Located on the XEN
Platform to the KVM Platform...........................................................................................................................................39
9.4 (Optional) Modifying the IP Address of the VRM Node.............................................................................................39
9.5 (Optional) Migrating a VRM VM................................................................................................................................40
9.6 Importing a License File...............................................................................................................................................40
10 Appendix 1 Common Operations..........................................................................................41

10.1 Verifying Software Packages......................................................................................................................................41
10.2 Guest OSs that Support Switchover...........................................................................................................................41
10.3 Guest OSs that Do Not Support UEFI l After Switchover.........................................................................................46
10.4 Account Information List...........................................................................................................................................46
10.5 Applying for a New License File................................................................................................................................48
10.6 Changing the Password of User root for a Node........................................................................................................49
10.7 Changing the Password of the User gandalf for a Node............................................................................................50
10.8 Changing admin User's Password..............................................................................................................................52
FusionSphere PCS
10.9 Using PuTTY to Log In to a Node in Key Pair Authentication Mode.......................................................................53

10.10 Restoring Data..........................................................................................................................................................55
10.11 Switching VMs that Use the Port Group of the Subnet Type...................................................................................60
10.12 Changing Passwords of Interconnection Accounts During the Switchover.............................................................62
10.13 Performing the Switchover of eBackup Management VMs and Backup VMs........................................................63
10.14 Creating Interconnection Accounts on Cloud Platforms..........................................................................................67
10.15 Replacing the Security Authentication Certificate for Controller Nodes and Agent Nodes....................................67
10.16 Changing the Password for the GaussDB Administrator on the Controller Node...................................................74
10.17 Changing the Password for Accessing Common Services in GaussDB on the Controller Node.............................76
10.18 Resetting the Password for Accessing Common Services in GaussDB on the Controller Node.............................78
11 Appendix 2 Troubleshooting..................................................................................................81
11.1 Failure to Access the System After a UEFI VM Is Switched.....................................................................................81
11.2 Message "Failed to create a VM on the cloud platform" Is Displayed During VM Drill and Switchover Tasks......81
11.3 Initial Configuration for a Template VM on the KVM Platform Before Confirmation Is Performed.......................83
11.3.1 Linux Template VM.................................................................................................................................................83
11.3.2 Windows Template VM...........................................................................................................................................83
11.4 Agent status display for Abnormal.............................................................................................................................87
11.5 Failed to Execute the Disk Configuration Injection Task During the Drill and Switchover......................................87
11.6 Faulty OS During the Deployment of Controller VM................................................................................................88
12 Appendix 3 Obstacle Item Description.................................................................................90

12.1 VM Has vCPU Binding Enabled................................................................................................................................90
12.2 VM Is Bound to Host.................................................................................................................................................90
12.3 Reserving Resources upon VM Stop Is Enabled for a VM........................................................................................91
12.4 VM Is a Template VM................................................................................................................................................92
12.5 VM Uses an Independent Persistent Disk..................................................................................................................93
12.6 VM Uses a Non-Persistent Disk.................................................................................................................................94
12.7 VMs that Use Shared Disks Are Not All Stopped......................................................................................................94
12.8 VM is a Linked Clone VM.........................................................................................................................................95
12.9 ISO File Is Mounted to the VM..................................................................................................................................96
12.10 Tools ISO File Is Mounted to the VM......................................................................................................................96
12.11 USB Device Is Mounted to a VM.............................................................................................................................97
12.12 VM Is a DR VM.......................................................................................................................................................98
12.13 VM Is an Antivirus Guest VM (GVM)....................................................................................................................98
12.14 VM Is a Secure VM (SVM).....................................................................................................................................99
12.15 GPU Device Is Mounted to a VM............................................................................................................................99
12.16 HANA Configuration Is Enabled on the VM.........................................................................................................100
12.17 VM Uses Local Disk (Non-Virtualization) Storage...............................................................................................101
12.18 VM Uses SAN Storage (Non-Virtualization).........................................................................................................101
12.19 VM Uses the Advanced SAN Storage....................................................................................................................102
12.20 VM Uses FusionStorage.........................................................................................................................................102
12.21 VM Uses Local RAM Disks...................................................................................................................................103
FusionSphere PCS
12.22 VM Uses Virtualized Local Hard Disks.................................................................................................................103

12.23 HA Function Is Enabled for the VM, but Not Enabled for the Target Cluster.......................................................104
12.24 A Fault Handling Policy Is Set for the VM, but Not Set for the Target Cluster, or Different Policies Are Set for the
VM and Cluster................................................................................................................................................................105
12.25 VM Has a VM Snapshot or Volume Snapshot.......................................................................................................105
12.26 Tools (PV Driver) Is Not Running..........................................................................................................................106
12.27 Source VM Is Not in the Running or Stopped State...............................................................................................107
12.28 VM Does Not Support Snapshot Creation Because the Number of CPUs Exceeds 64.........................................107
12.29 VM or Template Uses an MAC Address Used by the Target Platform..................................................................108
12.30 NIC Configuration of the Source VM Changes After the VM Is Added to a Switchover Plan.............................109
12.31 Source and Target Port Groups Are Different in Types..........................................................................................109
12.32 Source and Target Port Groups Are of Common Type, but Their VLAN IDs Are Different.................................110
12.33 Source and Target Port Groups Are of Trunk Type, but Their VLAN Ranges Are Different.................................111
12.34 TCP Checksums for Source and Target Port Groups Are Different.......................................................................111
12.35 Source and Target Port Groups Are Different in IP Address and MAC Address Binding Configuration..............112
12.36 Source and Target Port Groups Are Different in DHCP Isolation Configuration..................................................113
12.37 Source and Target Port Groups Are Different in IP/ARP Broadcast Suppression Configuration..........................113
12.38 Source and Target Port Group Are Different in QoS (Outbound and Inbound Traffic Shaping) Configuration....114
12.39 IP-MAC Binding Is Enabled for the Source Port Group........................................................................................115
12.40 Source Port Group Is of the Subnet Type...............................................................................................................115
12.41 Source Port Group Uses VXLAN...........................................................................................................................116
12.42 Number of Disks on the Source VM Exceeds 25, There Are IDE Disks Whose Slot IDs Are Greater Than 25, or
the Source VM Uses RDM Disks, and the Guest OS Does Not Support virtio-scsi Disks..............................................117
12.43 Target Cloud Platform Does Not Support Guest OS of Source VM......................................................................117
12.44 Data Store Used by the Source VM Is Not Added to the Target Cloud Platform...................................................118
12.45 CPU Quota Set for the Source VM Exceeds that Supported by the Target Cloud Platform..................................119
12.46 Maximum Number of Read or Write Bytes Configured for the Source VM Disks Exceeds the Value Range
Supported by the Target Cloud Platform..........................................................................................................................119
12.47 Configurations of Whether Memory Overcommitment Is Enabled Are Different for the Source and Target
Clusters.............................................................................................................................................................................120
12.48 Configurations of Whether HA Is Enabled Are Different for the Source and Target Clusters...............................121
12.49 Configurations of Whether IMC Is Enabled Are Different for the Source and Target Clusters.............................121
12.50 IMC Configurations Are Different for the Source and Target Clusters..................................................................122
12.51 Type of the DVS Connected to the Source VM Is Different from that of the DVS Connected to the Target VM 123
12.52 Source and Target VMs May Have Different Guest NUMA Topologies...............................................................123
12.53 Affinity or Anti-affinity Rule Is Configured for the Source VM............................................................................124
12.54 Object Operation Permissions Are Configured for the Source VM.......................................................................125
12.55 Source VM Uses a Passthrough DVS....................................................................................................................125
12.56 Source VM Uses the Port Group of a DVS in Network Enhancement Mode........................................................126
12.57 QoS (Upper Limit of IOPS) Is Configured for Disks of the Source VM, Which May Affect the Driver Injection
Speed During the Switchover...........................................................................................................................................126
12.58 Source VM or Disk Has 32 Snapshots, and No Snapshot Can Be Created............................................................127
12.59 RDM Disk Slot IDs of the Source VM Change After the Switchover...................................................................128
FusionSphere PCS
12.60 Source VM Is Configured with a Free Clock.........................................................................................................128

12.61 Network Configurations of the Drill Port Group and Source Port Group May Conflict.......................................129
12.62 Guest OS of the Source VM Does Not Support Online Disk Snapshots...............................................................130
12.63 Source VM Does Not Exist....................................................................................................................................130
12.64 Target Compute Resources Are Unavailable..........................................................................................................131
12.65 VM Uses a Shared Disk.........................................................................................................................................132
12.66 Source VM Uses the UEFI Boot Firmware, but the Guest OS Does Not Support UEFI on the Target Cloud
Platform............................................................................................................................................................................132
12.67 Source VM Uses an Independent Persistent Disk and Has a VM Snapshot..........................................................133
12.68 The Guest OS Does Not Support Online Drill.......................................................................................................133
12.69 The Hardware Configuration of Source VM Exceeds the Specifications Supported by Guest OS.......................134
12.70 iCache Is Configured for a Template VM..............................................................................................................135
FusionSphere PCS
Operation Guide (Virtualization Xen to KVM) 6 Installation and Deployment
1 Overview
1.1 Introduction
PCS allows you to switch over VMs that use VIMS, FC SAN virtualization, NAS, and
RDM from FusionCompute V100R006C10SPH108 standard version to the FusionCompute
6.5.0 virtualization platform.
1.2 Switchover Process Overview

1. Preparations before the Switch over: Prepare the environment that meets switchover
requirements, FusionCompute 6.5.0 target platform, and PC client.
2. Drill: Before a VM switchover, carry out a drill to ensure that the VM can run properly
on the target platform.
3. Switchover: Switch over VMs from the source platform to the target platform.
4. Test verification: Verify that the systems and applications can work properly after the
switchover.
FusionSphere PCS
Operation Guide (Virtualization Xen to KVM) 6 Installation and Deployment
Upgrade the Xen plat form.
Prepare for the KVM platform.
Check whether VI MS uses hardware-

assisted locking.
No
Yes Change it t o hardware-assisted locking.
Deploy the P CS environment.
Perf orm the drill.
End t he drill.
Perf orm the switchover.
Perf orm service conf irmation.
Confirm the switch.
Delet e t he resources.
Disable dual-site management.
Convert the disk format from VHD to RAW.

2 Technical Support
A professional technical team is responsible for switchover evaluation, switchover solution

design, and switchover implementation, and provides complete technical support, thus
ensuring smooth switchover from FusionCompute V100R006C10SPH108 to FusionCompute
6.5.0.
3 Switchover Service and Risk Precautions
System switchover, covering system service data, is a high-risk activity and affected by
multiple factors, and therefore the switchover may fail.
You are advised to follow a professional service process to implement the switchover and thus
identify potential risks in advance.
3.1 Introduction to the Switchover Service

The professional switchover service consists of the following phases: information collection,
switchover feasibility analysis, service switchover risk and countermeasures, switchover plan
formulation, switchover solution formulation, switchover tool and solution test, service
switchover implementation, and service switchover acceptance.
3.1.1 Information Collection and Feasibility Analysis

Check whether the guest OS supports the switchover by referring to 10.2"Guest OSs that
Support Switchover."
If the guest OS does not support the switchover, the switchover cannot be performed.
The storage can be only virtualized SAN (hardware-assisted locking) and NAS storage. The
remaining space must be greater than the disk space used by the VM that occupies the largest
space.
3.1.2 Switchover Plan and Solution Design

To ensure the efficiency and success rate of switching from Xen to KVM, you are advised to:
 Plan the drill network and prepare test VMs for service verification in advance to achieve
the VM drill purpose.
 Perform switchover in batches if the services deployed on a VM are not coupled with
other VMs.
 Perform the switchover for VMs that are associated with each other in the same batch.
For example, the database service is deployed on vm1, and vm2 needs to access the
database of vm1, or vm3, vm4, vm5, and vm6 provide cluster applications, you are
advised to place vm1 and vm2 in the same batch and vm3, vm4, vm5, and vm6 in the
same batch.
3.1.3 Core Service Switchover Test

To ensure that services run properly after the core service VMs are switched from Xen to
KVM, you are advised to:
 Clone a VM that has core services by following "Making a VM Clone from a Parent
VM" in the product documentation. Before this, switch over the cloned VM. After
verifying that services are running properly on the cloned VM, switch over the VM that
carries core services.
 If third-party software is deployed on the service VM, contact the third-party vendor for
technical support in advance.
 If the service license deployed on the VM is related to the hardware ESN, the license
may need to be activated again after the VM is switched from Xen to KVM. Contact the
service provider in advance and activate the license again after the switchover.
 If the Windows license is of the OEM type, you need to reactivate the Windows license
after the VM is switched from Xen to KVM.
3.2 Switchover Risk

System switchover is a high-risk activity and may fail to be implemented due to such factors
as the network environment, platform, OS, and old service system. You are advised to back up
core service data before the switchover.
4 Switchover Restrictions
4.1 Networking
Figure 4.1.1.1.1.1.1.1 Networking
 Ensure that the Xen platform, source host, KVM platform, target host, and PC
communicate with each other.
 The target KVM platform can access and reuse resources in the existing storage pool of
Xen.
 For details about ports to be opened for switchover, see the FusionSphere PCS 6.5.0
Communication Matrix.
Ensure that the ports listed in the communication matrix are enabled on the system and
network firewalls. You are advised to disable the firewall on the source system and enable it
after the switchover. You are advised to set the security group policy of the target platform to
ensure that the source platform, target platform, and PC communicate with each other after
successful switchover.
4.2 Switchover Network Restrictions
 Only LAN supports switchover. WAN and NAT networks do not support switchover.
 Switchover implementation requires no packet loss, no jitter, latency less than 2 ms, and
bandwidth greater than 100 Mbit/s. If such QoS requirements are not met, a switchover
failure is highly possible.
 The executor can access management plane networks of the source and target
FusionCompute platforms.
4.3 Switchover Pre-implementation Requirements

 FusionCompute with version earlier than V100R006C10SPH108 must be upgraded to
V100R006C10SPH108. VIMS must use hardware-assisted locking.
 At least two idle nodes must be prepared to set up the FusionCompute 6.5.0 environment
for VM switchover.
 To avoid time jump after VM switchover, the target and source compute nodes must be
synchronized in time.
 To switch over Xen VMs to a KVM site that has provisioned services, network
configurations, such as MAC addresses and IP addresses, on the KVM site may conflict
with those on the Xen site, and the administrator needs to check and adjust the network
configurations before VM switchover.
 During the drill, a drill VM and the original VM have the same network configuration.
To prevent impacts on existing services, plan a drill network and specify the drill
network used by each VM when creating a switchover task.
 The remaining storage space must be sufficient for snapshot creation during drill, and
driver injection during drill or switch, which will generate about 300 MB data per VM.
 Check the background periodic tasks which will operate source Xen VMs in advance,
and stop these tasks during the switchover window period.
 If a Xen VM has the DR service enabled, disable the DR service before the switchover
and reconfigure DR after the switchover.
4.4 Switchover Implementation Requirements

 Do not change the account role used for interconnection during switchover.
 To change the passwords of interconnection accounts during the switchover, see
Changing Passwords of Interconnection Accounts During the Switchover.
 To switch over a VM or VM template in offline mode, the customer needs to ensure that
there is no operations performed on the VM or VM template and its background periodic
tasks are stopped.
4.5 Impact on Services
 After VM switchover, the customer needs to confirm the correctness of internal services.
 A Windows OEM license may be invalid after the switchover and needs to be
reactivated.
 After a VM switchover is complete, a snapshot is created by default for the rollback
purpose, and this affects the I/O performance and occupies extra storage space. If the
user confirms that the service is normal, the snapshot is automatically deleted after
completion of the switchover is confirmed on PCS, and rollback is not supported. If the
user confirms that the service is abnormal, the data can be restored to the state before the
switchover after rollback is performed on PCS, and the data generated between the
switchover and the rollback is lost.
 Xen VMs with historical backup points cannot be restored from these points after the
switchover. If eBackup VMs are deployed, perform operations by strictly following
"Performing the Switchover of eBackup Management VMs and Backup VMs."
 For Xen VMs with historical VM snapshots or volume snapshots, historical snapshot
points are invisible after switchover and these VMs cannot be restored to these points. To
prevent impacts on performance after the switchover, you are advised to delete snapshots
before the switchover.
 All VMs that use the shared volume must be shut down before the switchover.
 For VMs using independent disks, PCS automatically changes the independent disks to
common disks during the drill and switchover and then changes them back after the drill
and switchover.
 After the VM is switched from Xen to KVM, URNs of the VM and associated volumes
change.
 After a VM is switched from Xen to KVM, the existing DR needs to be reconfigured by
an administrator.
 Database applications (especially Oracle) and cluster applications (such as MSCS) are
recommended to be switched over using an existing application switchover solution.
 The features of the source and target platforms are different. Therefore, before the
switchover, evaluate the service dependency on features that are not provided by the
target platform.
 Differences between capability and compatibility of Xen and KVM platforms bring the
following effects:
− When VIMS or NAS storage is used and the non-thick provision zeroed volume is
configured, QCOW2 snapshots are created by default after the switchover, and the
VM volume cannot be scaled. The administrator can log in to the VRM node,
perform planned data merge (data copy and merge of the parent volume), and remove
these QCOW2 snapshots.
− For VMs that are bound to CPUs or hosts, you need to manually set the binding again
after the switchover.
− For VMs that are bound to hosts and for which resources are reserved, these
configurations need to be configured again after switchover.
− For VMs that are mounted with the CD-ROM drive device/file and Tools ISO, you
need to manually mount the drive again after the switchover.
− For antivirus VMs, reconfigure the antivirus function based on the KVM antivirus
configuration guide.
− For VMs that use GPU devices, reconfigure the GPU based on the KVM GPU
passthrough or virtualization configuration guide.
− For VMs whose IDE disk slot IDs are the same as the SCSI disk slot IDs, the slot IDs
of the SCSI disks in the PRDM mode change.
− For VMs that have IP and MAC binding enabled and use DHCP-based automatic
assigning, the IP and MAC address binding fails after switchover.
− For VMs that use a subnet port group, you need to manually configure the subnet
− For VMs that are enabled with Guest NUMA (the number of sockets is greater than 2
and Guest NUMA is enabled for the cluster), the VM NUMA topology may change.
− For VMs that have an affinity rule configured, you need to reconfigure the affinity
rule after switchover.
− For VMs that have object operation permissions configured, you need to manually
configure object operation permissions after switchover.
− For VMs that have a free clock configured and whose time is manually adjusted and
does not depend on the NTP server, the host time prevails after the switchover. There
is no time deviation between the time that you manually adjust and the host time.
− For VMs that have port mirroring configured, port mirroring must be reconfigured
after the VMs are switched over to the KVM platform.
− If DRS or HA access control is enabled for the cluster where the Xen VM is located,
you are advised to plan a similar cluster on the KVM platform before switchover and
switch over the VM to the planned cluster. Otherwise, the VM uses the DRS or HA
default access control configured for the KVM target cluster. If the source VM
belongs to a DRS balancing group, the DRS balancing group must be reconfigured as
required after the VM is switched over to the KVM platform.
− The write I/O mechanism of the file system on the virtual SAN and the monitoring
algorithm on the KVM platform are different from those on the Xen platform.
Therefore, during dual-site management configuration, an error indicating that the
memory usage of the host virtualization domain exceeds the threshold is mistakenly
reported during the VM disk format conversion on the KVM platform.
 For guest OSs, mainly OSs whose warranty periods expire, that are supported by Xen but
are not supported by KVM, use new guest OSs on the KVM platform. If switchover
must be performed, carry out a survey as required.
 For guest OSs that support UEFI boot in Xen but do not support this function in KVM,
use new Guest OSs on the KVM platform. If switchover must be performed, carry out a
survey as required.
 For USB passthrough VMs, services that depend on the USB device cannot be used in
these VMs after the switchover. Therefore, the customer needs to bind the USB device to
these VMs on the target platform.
 After switchover, Tools is installed by default. And, you can uninstall it.
 Hostname may be changed after switchover when VM configured
DHCLIENT_SET_HOSTNAME=yes, For details, see
https://support.huawei.com/enterprise/en/knowledge/EKB1001577902.
4.6 Function Restrictions

 Support only FusionSphere Virtualization Suite Standard edition.
 Switchover can be performed only when VMs that use VIMS, NAS, and RDM data
stores. These source data stores can only be attached to one other FusionSphere
Virtualization Suite as the target platform for switchover.
 Xen resource pools using IPv4 cannot be switched over to KVM resource pools using
IPv6.
 Switchover of linked clone VMs in desktop cloud scenarios is not supported.
 Xen VM templates exported from the platform cannot be directly switched over to the
target platform.
 Switchover of volumes that are not attached to any device is not supported.
 Before switching over an antivirus guest VM (GVM), you need to uninstall the GVM
driver from the VM and then switch over the VM.
 To switch over a VM in GPU sharing mode, you need to uninstall the shared memory
driver from the VM and then switch over the VM.
 The restrictions on the guest OS configuration of the VM to be switched over are as
follows:
− The VM disk peripheral type changes from Xen IDE(pvblk) to virtio-blk or virtio-
scsi. The VM NIC type changes from PVNet to virtio-net. If the internal service of
the VM strongly depends on the peripheral type, the service needs to be adjusted and
adapted.
− The remaining space of the system disk on the Windows VM must be greater than or
equal to 300 MB. The remaining space of the system disk on the Linux VM must be
greater than or equal to 200 MB, and that of the /boot directory must be at least four
times the actual size of initrd.
− Only VMs that use mainstream file systems, such as ext2, ext3, ext4, btrfs, cramfs,
FAT, Minix, MS-DOS, VFAT, XFS, and NTFS, are supported.
− On a Linux VM, data disks that are mounted in UUID, LVM, or partition mode are
remounted based on the configuration in /etc/fstab after the switchover. Data disks
that are mounted in non-mainstream mode (including by-id, by-path, and by-label)
are not automatically mounted after the switchover. You need to manually mount
such data disks.
− VMs cannot be switched over when multiple guest OSs are installed, including
multiple guest OSs installed on multiple partitions on the same disk and multiple
guest OSs installed on different disks.
 Do not perform the online drill on the following Xen VMs or in the following scenarios:
− Source VMs whose guest OSs do not support online disk snapshots
− Template VMs (Drill can be performed through switchover and rollback.)
− VMs that use non-persistent disks
− VMs that use shared volumes
− VM that has more than 25 disks (or disks in slot ID greater than slot 25) or uses
PRDM disks, and uses the guest OS that does not support virtio-scsi on the target
platform
− DR VMs
− Antivirus service VMs
− Antivirus client VMs
− VMs that use GPUs
− VMs where Tools is not running
− VMs that are not in the running or shutdown state
− VMs with more than 64 vCPUs
− VMs that use MAC addresses used by the target KVM platform
− VMs that use guest OSs not supported by the target KVM platform
− VMs that use UEFI boot firmware not supported by the target KVM platform
− VMs whose CPU quota and disk IOPS exceed the limit supported by the KVM
platform
− Types of DVSs connected to the source platform and target platform are different.
− The source VM or disk has 32 snapshots.
− Source VMs use independent persistent disks and VM snapshots exist.
− The guest OS does not support online drill.
− The hardware configuration of source VM exceeds the specifications supported by
guest OS.
− iCache is configured for a template VM.
 Xen VM switchover is not supported on the following Xen VMs or in the following
scenarios:
− VMs that use non-persistent disks
− All VMs using the shared volume are not shut down.
− VM that has more than 25 disks (or disks in slot ID greater than slot 25) or uses
PRDM disks, and uses the guest OS that does not support virtio-scsi on the target
platform
− DR VMs
− Antivirus service VMs
− VMs where Tools is not running
− VMs that are not in the running or shutdown state
− VMs that use MAC addresses used by the target KVM platform
− VMs that use guest OSs not supported by the target KVM platform
− VMs that use UEFI boot firmware not supported by the target KVM platform
− VMs whose CPU quota and disk IOPS exceed the limit supported by the KVM
platform
− Types of DVSs connected to the source platform and target platform are different.
− The hardware configuration of source VM exceeds the specifications supported by
guest OS.
− iCache is configured for a template VM.
5 Compatibility List
5.1 Platform Compatibility

Table 5.1.1.1.1.1.1.1.1 FusionCompute source and target platform compatibility list
FusionCompute Source Platform Type Target Platform Type
FusionCompute V100R006C10SPH108 FusionCompute 6.5.0
5.2 Guest OS Support Policies

Guest OSs running on the cloud computing platform are independent of the release period and
life cycle policy. Huawei defines different support levels for the guest OSs and provides
respective management policies during their life cycle.
 For details about the guest OS support policies, contact Huawei technical support.
 For a guest OS no longer supported by the Huawei cloud platform, the support team is not obligated
to provide assistance in any switchover problems related to this OS.
 For guest OSs that support switchover, see 10.2"Guest OSs that Support Switchover."
6 Installation and Deployment
6.1 Software Obtaining

Download the desired documentation package from the Huawei technical support websites:
 For enterprise users: http://support.huawei.com/enterprise
 For telecom carrier users: http://support.huawei.com
Table 6.1.1.1.1.1.1.1.1 Switchover tool software

Software Description
FusionSphere_PCSA_Virtualization- PCS Agent template file

6.5.1.1-X86_64.zip
FusionSphere_PCSC_Virtualization- PCS Controller template file
6.5.1.1-X86_64.zip
FusionCompute FusionCompute V100R006C10 patch
V100R006C10SPH108_Upgrade.zip
FusionSphere SIA 6.5.7_GuestOS-Plug-In FusionSphere SIA 6.5.7 FusionSphere 6.1
for FusionSphere V100R006C10.zip GuestOS Compatibility Plug-In
FusionSphere SIA 6.5.7_GuestOSDriver FusionSphere SIA 6.5.7 GuestOS Tools
for FusionSphere V100R006C10.zip
Table 6.1.1.1.1.1.1.1.2 Switchover tool software material

Material Description
FusionSphere PCS 6.5.1.1 Operation FusionSphere PCS 6.5.1.1 Operation Guide

Guide (Virtualization Xen to KVM) (Virtualization Xen to KVM)
FusionCompute V100R006C10SPH108 FusionCompute V100R006C10SPH108
Upgrade Guide Upgrade Guide
FusionCompute V100R006C10SPH108 FusionCompute V100R006C10SPH108 Patch
Patch Notes Notes
FusionSphere SIA 6.5.7 FusionSphere 6.1 FusionSphere SIA 6.5.7 FusionSphere 6.1
GuestOS Compatibility Plug-In GuestOS Compatibility Plug-In Installation
Installation Guide 01 Guide
FusionSphere SIA 6.5.7 PV Driver FusionSphere SIA 6.5.7 PV Driver
Installation and Upgrade Guide 01 Installation and Upgrade Guide
6.2 Switchover Software Specifications

Controller VMs and injection agent VMs are deployed in FusionCompute 6.5.0 KVM.
Table 6.2.1.1.1.1.1.1.1 Specifications of the controller VM

Hardware and Software Recommended Configuration
CPU 4 CPUs and above

Memory 5 GB and above
Hard Disk 40 GB and above
Table 6.2.1.1.1.1.1.1.2 Specifications of the injection agent VM

Hardware and Software Recommended Configuration
CPU 2 CPUs and above

Memory 2 GB and above
Hard Disk 20 GB and above
6.3 Installation and Deployment

6.3.1 Preparing for the FusionCompute 6.5.0 Environment
Create a FusionCompute 6.5.0 platform or upgrade the existing FusionCompute 6.3 to
FusionCompute 6.5.0.
Create a FusionCompute platform according to FusionSphere Virtualization Suite 6.5.0 Product

Documentation.
 If VMs need to be migrated between hosts with different CPU types during the switchover and
subsequent normal running, configure the IMC policy for the cluster by following "Configuring
IMC for a Cluster" in FusionSphere Virtualization Suite 6.5.0 Product Documentation.
 If VMs are running in the cluster to be modified and the IMC policy needs to be configured for the
cluster, create a temporary cluster by following "Creating a Cluster" and move hosts from the cluster
to the temporary cluster by following "Moving a Host" in FusionSphere Virtualization Suite 6.5.0
Product Documentation. After all hosts are removed, configure the IMC policy for the cluster by
following "Configuring IMC for a Cluster". Then, move the hosts from the temporary cluster to the
source cluster and delete the temporary cluster.
6.3.2 Upgrading the Xen Platform to V100R006C10SPH108

Step 1 Upgrade the environment.
For details, see FusionCompute V100R006C10SPH108 Upgrade Guide.
 The Xen platform must be upgraded to V100R006C10SPC101 or a later version before being
upgraded to V100R006C10SPH108.
 The Lock Type of the SAN storage must be Hardware-assisted Locking. If the hardware does not
support hardware-assisted locking, the switchover cannot be completed. If the SAN storage uses the
distributed locking mode, switch to hardware-assisted locking following operations provided in
"Switching to Hardware-Assisted Locking for the Virtualized SAN Storage" in the FusionSphere
V100R006C10 Product Documentation (Server Virtualization). During the switching process, the
services are interrupted for about 30 to 90 seconds.
Step 2 Upgrade GuestOS Compatibility Plug-In based on FusionSphere SIA 6.5.7 FusionSphere 6.1
GuestOS Compatibility Plug-In Installation Guide 01.
Step 3 (Optional)Upgrade GuestOS Tools based on FusionSphere SIA 6.5.7 PV Driver Installation
and Upgrade Guide 01.
Step 4 On the FusionCompute web client, choose System > System Configuration > License
Management and click Load License File. On the Load License File page, click Obtain
ESN and record the ESN.
Step 5 Use PuTTY to log in to the CNA host as the gandalf user and run the su - root command to
switch to the root user,
Step 6 Run the TMOUT=0 command and then run the rpm -qa |grep GalaX-CNA-Update
command to obtain the version number after GalaX-CNA-Update- in the command output,
for example GalaX-CNA-Update-100.5.0-XXX.
 If the second number is 5 or 6, no action is required.
 If the second number is 3, upgrade the environment to V100R006C10SPH108, add a
virtualized SAN storage device by following "Adding a Data Store" in FusionSphere
V100R006C10 Product Documentation (Server Virtualization), and migrate the VM to
the new storage device by following "Migrating Disks of a VM." After the migration is
successful, switch the VM.
If capacity expansion has been performed in the environment, obtain the original version number of the
host during initial installation and that of the host to be expanded.
----End
6.3.3 Configuring the MAC Address Segment
During switchover, Xen and KVM environments use the same layer 2 network. In this case,
you need to plan the MAC address segment in each environment to avoid MAC address
conflict.
Perform the following operation to modify the MAC address segment.
Step 1 On the FusionCompute 6.5.0 web client, click to go to the Resource Pools page. On the
displayed page, choose Configure > MAC Address Pool, and click Modify in the
Operation column in the row that contains the default MAC address pool. In the displayed
dialog box, modify the MAC address segment.
Step 2 On the FusionCompute V100R006C10SPH108 web client, choose site > MAC Address Pool
and click Modify in the Operation column in the row that contains the default MAC address
pool. In the displayed dialog box, modify the MAC address segment.
 Do not use the reserved address segment, multicast address segment, and broadcast address segment.
 Reserved address segment: from 44456477242017 (this value included) to 44456477247017 in
decimal notation; from 28:6e:d4:88:b2:a1 (this value included) to 28:6e:d4:88:c6:29 in hexadecimal
notation
 Multicast address segment and broadcast address segment: The MAC address consists of 48 bits,
usually represented as a string of 12 hexadecimal digits. It consists of 6 pairs where each pair has
two hexadecimal digits. The value ranges from 00-00-00-00-00-00 (this value included) to FF-FF-
FF-FF-FF-FF (this value included). The first pair has two hexadecimal digits corresponding to odd
numbers from 0 to 255 (this value included), indicating the multicast address and broadcast address.
For example, hexadecimal digits 0d correspond to the odd number 13, and the multicast address is
0d-xx-xx-xx-xx-xx.
----End
6.3.4 Configuring Dual-site Management to Allow Source and

Target Platforms to Access VIMS
In FusionCompute 6.5.0
Step 1 Use PuTTY to log in to the active VRM node as user gandalf, run the su - root command to
switch to user root, and run the TMOUT=0 command to disable user logout upon system
timeout.
Step 2 Run the sh /opt/galax/gms/common/ha/modifyVimsMultisiteSwitch.sh open command to
enable dual-site configurations.
Step 3 Perform the preceding operations on the standby VRM node.
----End
In FusionCompute V100R006C10SPH108
timeout.
Step 2 Run the sh /opt/galax/gms/common/ha/modifyVimsMultisiteSwitch.sh open command to
enable dual-site configurations.
----End
Configuring Dual-site Management

Step 1 Create interconnection accounts on FusionCompute V100R006C10SPH108 and
FusionCompute 6.5.0 as instructed in "Creating Interconnection Accounts on Cloud
Platforms".
Step 2 On the FusionCompute 6.5.0 web client, choose System > Connect To > Dual-site
Management.
 In the Peer VRM Information area, configure the IP address, port number, protocol,
version, and new username and password of FusionCompute V100R006C10SPH108.
 In the Local VRM Information area, set the IP address, port number, protocol, version,
and new username and password of FusionCompute 6.5.0.
Step 3 After all information is configured, click Save.
The admin account is not allowed for "Dual-site Management".
Step 1 On the FusionCompute 6.5.0 web client, choose Resource Pools > Storage > Storage Device
and click Scan. In the displayed Scan Storage Device dialog box, select all hosts and click
Confirm.
Step 2 Choose Resource Pools > Storage > Data Store and click Add Data Store. In the displayed
Storage Device dialog box, select the first LUN in the VIMS cluster of the Xen version and
click Next.
Step 3 Enter the storage name, set Format to No, select hosts for which the VIMS cluster is to be
configured on the Associate Host tab page, and click Next. In the displayed dialog box, click
Confirm.
Xen hosts and KVM hosts must be added to the same host group during the storage configuration.
Otherwise, VIMS cluster dual-site management cannot be achieved.
----End
Changing VIMS Cluster Node IDs in FusionCompute 6.5.0

On the FusionCompute 6.5.0 web client, choose Resource Pools > Storage > Data Store >
Modify VIMS Cluster Node Number to change the host IDs in conflict.
Before the change, switch over or stop all VMs using virtualized SAN storage on the host.
6.3.5 Deploying Controller and Agent VMs on the Target

Platform
Step 1 Deploy the controller and agent VMs by referring to section "Creating a VM from a
Template" in the FusionSphere Virtualization Suite 6.5.0 Product Documentation.
 You can customize names and IP addresses of controller and agent VMs.
 The password custom injection is not supported. To change the password, log in to the system as
user root and change the password of user gandalf or root after the environment is installed.
Step 2 Configure PCS controller and agent VM object permissions.
1. Click the name of the controller or agent VM, choose Configuration, and click Settings
next to Permissions.
2. On the displayed page, select Create snapshot, Modify snapshot, Delete snapshot,
Resume snapshot, Back up and restore VM, Delete VM, Hibernate VM, Pause VM, and
Resume VM.
3. Click Confirm.
----End
6.3.6 (Optional) Configuring a Backup Server
Configure a third-party File Transfer Protocol (FTP) server to back up important data on the controller
node. After the FTP server is configured, the controller node automatically sends important data to the
FTP server at 02:00:00 every day. If a system exception occurs, the backup data can be used to restore
the system.
Step 1 Use PuTTY to log in to the controller node as user gandalf, run the su - root command enter
the password of user root to switch to user root, and run the TMOUT=0 command to disable
user logout upon system timeout.
Step 2 Run setConfig to configure data backup and enter yes.
Should we upload the backups to ftp server? (yes/no):
If you enter no, the data backup upload function is disabled.

Step 3 Set the protocol type.
You are advised to select FTPS to enhance file transmission security. If the FTP server does
not support the FTPS protocol, select FTP.
Please input the upload network protocol[ ftp,ftps ], press enter and default value
[ftp] :
Step 4 Set IP Address.
Enter the IP address of an FTP server.

Please input the ftp server ip address, press enter and default value [127.0.0.1] :
Step 5 Set Port.
Enter the port used by an FTP server.

Please input the ftp server port, press enter and default value [21]
Step 6 Set Username.
Enter the username for logging in to an FTP server.

Please input the ftp upload user name, press enter and default value [admin]
Step 7 Set Password.
Enter the password for logging in to an FTP server.

Please input the ftp upload user password, press enter and default value
[AAAAAQAAAAEAAAAAAAAABQAAAAEAAAAB5Mh8rThC94LDGli4bYNAbYR/VUcSnDS6JLD8XQSx6VkAAAAQA
AAAAAAAAAAtkb3fqf1fBx2B3gwDfcKsAAAAAQAAAAAAAAgEAAAAAQAAAAGdfr4qJTbdEaWANZjlBjdDAAA
AAAAAAACf9DpDZbduCRWT/xt+aAVD/7AaB+g5ED6ytVM3n9W+MQ=] :
Step 8 Set Backup Path.
Enter the relative path in which the backup files are stored.
Please input the ftp upload root directory, press enter and default value [/] :
The configuration information is displayed. If the information is correct, enter yes. Otherwise,
enter no and run the setConfig command again.
Backup configure :
1.Upload network protocol : ftp
2.Ftp server IP : 200.200.0.51
3.Ftp server port : 21
4.Ftp server user name : admin
5.Ftp server user password :

AAAAAQAAAAEAAAAAAAAABQAAAAEAAAABNyiC5bmbz918vZnC9o6hLEdq9mXFBDkirU5Zf/ksjcUAAAAQAAA
AAAAAAABjYVQ22T68GCjb0XPZTaMzAAAAAQAAAAAAAAgEAAAAAQAAAAHUhIldf61AYY80I8CV20o4AAAAAA
AAAAANgB41jRWlS3OQOumtbJjFHhFWZwmAKXjhEj2fZ1Ml/Q=
6.Ftp server upload root directory : /
Are you sure Save ? (yes/no) :
If the configuration fails, check the following items

1. Check whether the management data backup configuration is correct, for example, the username or
password.
2. Check whether the network between the controller node and a third-party FTP server is faulty.
3. Check whether the disk space of a third-party FTP server is insufficient.
4. Check whether the FTP server configuration client does not have permission to create a folder or
file.
If an exception occurs on a third-party FTP server, contact the server administrator to handle this issue.
----End
6.3.7 Configuring the Cloud Platform

Step 1 Create interconnection accounts on FusionCompute V100R006C10SPH108 and
FusionCompute 6.5.0 as instructed in "Creating Interconnection Accounts on Cloud
Platforms".
Step 2 Enter https://IP address of the controller VM in the address box of your browser to log in to
the controller VM management page.
Change the default password upon the first login. For details about the default password, see
10.4"Account Information List."
On the home page, you can view the overall PCS system status.
 Common Operation: provides functions, including Add Cloud Platform, Add Agent,
Register VMs, and Create Switchover Plan.
 Resource statistics: View Cloud platforms, Agents, VMs, and Switchover plans.
 VM Statistics: View the switchover result and drill result to know the VM drill and
switch status.
 Agent Statistics: View the agent information to know the agent status.
 Recent Tasks: View tasks generated in the latest 30 minutes to know the task status.
Step 3 Set the source platform information.
On the PCS management page, click Add Cloud Platform. On the displayed page, set Name
to FC_XEN, Category to FusionSphere Virtualization Suite, Version to V100R006C10,
IP Address to the IP address of the source platform, Port to the one created in the Xen
platform, Username to the one created in the Xen platform, and Password. Then, click
Confirm.
Step 4 Set the target platform information.
On the PCS management page, click Add Cloud Platform. On the displayed page, set Name
to FC_KVM, Category to FusionSphere Virtualization Suite, Version to 6.5, IP Address
to the IP address of the target platform, Port to the one created in the KVM platform,
Username to the one created in the KVM platform, and Password. Then, click Confirm.
 After the cloud platform is successfully registered, its VM list, storage resource list, and network
resource list can be automatically displayed.
 After the cloud platform is added, the user roles cannot be modified.
 To change the passwords of interconnection accounts during the switchover, see Changing
Passwords of Interconnection Accounts During the Switchover.
 When Category is set to FusionSphere Virtualization Suite, select Enable certificate. In this case,
identity authentication can be performed on the FusionSphere virtualization suite to prevent the suite
against forgery when PCS communicates with the FusionSphere virtualization suite.
 For details about how to obtain the FusionSphere virtualization suite certificate and password, see
Operation and Maintenance > Maintenance Management in Single-Hypervisor Scenarios >
Security Management > FusionCompute Certificate Management > Exporting the VRM Root
Certificate.
After the source and target platforms are added successfully, the following is displayed.
To modify information, click Modify in the Operation column to modify the information, or
click Delete and add the information again.
----End
6.3.8 Registering an Agent VM
If multiple VMs need to be switched over and there are sufficient idle resources in the target
environment, multiple agent nodes can be deployed to improve switchover efficiency.
An agent supports a maximum of eight VMs to be concurrently switched. To support more VMs to be
concurrently, deploy multiple agents on different hosts and then perform the drill and switchover
operations.
Step 1 On the PCS management page, choose Cloud Platform Management > FC_KVM and click
Register VMs. On the Register VMs page, select an agent VM and click Register.
Step 2 On the PCS management page, choose Cloud Platform Management > FC_KVM >
Agents, and click Add Agent. On the Add Agent page, specify Name, set Type to Injection
driver, and select the name of the VM to be registered for VM. Then, click Confirm.
After an agent VM is added, the information about the registered agent VM is displayed on
the Agents page. You can click Modify to change the agent name and type. If an error occurs,
click Delete and add the agent again.
----End
7 System Configuration
7.1 Managing Switchover Obstacle Items

Step 1 Choose System > System Configuration > Switchover Obstacle Management. Locate an
obstacle item and click Modify in the Operation column. On the displayed page, select
Adjust VM Later or Ignore for the item and click Confirm.
Step 2 On the Service Configuration page, you can set Check critical items only or Check all
items for VM Switchover Pre-check Configuration and then click Confirm.
----End
7.2 Configuring Password Policy

Step 1 Choose System > Password Policy and click Modify.
On the displayed page, all parameters are editable, and you can configure them.
Step 2 Click Save to save the configuration.
----End
7.3 Configuring the Login Timeout Period

Step 1 Choose System > Time Management.
Step 2 In the System Timeout area, select a value and click Confirm.
When the idle time exceeds the value, user logout occurs, and the user needs to log in to the system
again.
Step 3 In the displayed dialog box, click Confirm to complete the configuration.
----End
7.4 Viewing System Tasks

Choose System > System Tasks. On the displayed page, time-consuming tasks or tasks
whose task results cannot be immediately displayed are displayed, and you can view their
status.
8 VM
Drill and Switchover
8.1 Registering the VM to Be Switched over

Step 1 On the PCS management page, choose Cloud Platform Management > FC_XEN and click
Register VMs. On the displayed page, select the VM to be switched over and click Register.
 The Cloud Platform VM List page can be customized by site, cluster, and host.
 A pre-check is performed automatically when the VM to be switched over is registered.
Step 2 If Major is displayed for Switchover Pre-check Result, click the VM name to go to the VM
details page. Then, click Switchover Pre-check to view the cause and rectify the fault based
on information in the Obstacle area. After the processing is complete, click Recheck.
If the obstacle items do not affect the drill or switchover, set Ignore to them on the System page.
----End
8.2 Creating a Switchover Task

Step 1 On the PCS management page, choose VM Switchover, click Create Switchover Plan. On
the displayed page, set Name and select Virtualization Suite for Type, select FC_XEN for
Source Platform and FC_KVM for Target Platform. Then, click Next.
Step 2 Select the VM to be operated and click Next.
Step 3 Set the mapping between the source and target resources of the VM to be switched over.
 Target Network: Select the network used by the VM to be switched on the target
platform.
 Drill Network: Select the network used by the VM to be switched on the target platform
during the drill.
To avoid network conflicts, the two networks must be different.

 Target Compute Resource in the Target Compute Resource Mapping area: Select the
cluster or host resources used by the VM to be switched on the target platform.
After the configuration is complete, click Next.
Step 4 Modify the configuration information of the target resource.
The information about the VM to be switched over, target compute resources, target network,
and drill network is displayed.
 To modify the target resource of a VM, locate the row that contains the VM and click
Modify Target Resource.
 To modify target resources of multiple VMs, select multiple VMs and click Batch
Modify Target Resources.
After confirming that the configuration is correct, click Next.

Step 5 Perform switchover pre-check for the VM to be switched over and process the detection
result.
If Normal is displayed in the Check Result column, no risk item or item that cannot be
switched over is detected on the VM.
For a VM whose check result is not normal and values, rather than Normal, are displayed in
the Drill Impact or Switchover Impact column in the Obstacle area, click the arrow next to
the VM name to expand the obstacle information.
Based on the information in Obstacle, select Using System Configuration, Ignore, or
Adjust VM Later for Handling Action (Drill) and Handling Action (Switchover). After
doing this, click Next.
Step 6 After confirming that the switchover task information is correct, click Confirm to create the
switchover task.
Step 7 For risk VMs, you need to eliminate the risks on the source platform and then perform a
check again.
Alternatively, choose System > System Configuration > Switchover Obstacle
Management, select Ignore for Handling Action (Drill) and Handling Action (Switchover)
for the risk item and then click Confirm.
Step 8 In the switchover task, click the VM name. Under Basic Information, click Switchover Pre-
check and then click Recheck to check the VM again. If the message "the check result is
normal" is displayed, the operation is successful.
----End
8.3 Performing Switchover Drill

Step 1 After a switchover plan is created, choose VM Switchover > Switchover Plan to view the
plan.
Step 2 Locate the row that contains the switchover plan, click More in the Operation column, and
select Add VM to add the VM to be processed to the plan.
Also you can select Modify to modify the VM resource configuration after the switchover, or
Delete to delete the switchover plan.
Step 3 Click Drill in the Operation column. On the displayed page, select the VM to be drilled and
click Confirm. On the displayed page, click Confirm to start the drill.
Step 4 Click the arrow next to the task plan to view the drill progress and result of each VM.
Step 5 Choose VM Switchover > Switchover Task to view the execution result of each task.
If Succeeded is displayed in the Status column, the VM can be running on the target platform. You can
perform service check for the VM.
An agent supports a maximum of eight VMs to be concurrently. To support more VMs to be
concurrently switched, deploy multiple agents on different hosts and then perform the drill and
switchover operations.
Step 6 Click the arrow next to the task plan to expand the plan. Locate the row that contains the drill
VM whose status is Succeeded, click Drill. On the displayed Drill page, select End Drill,
select the VM for which drill has been completed, and click Confirm.
The data generated during VM drill is deleted.
Step 7 Choose VM Switchover > Switchover Plan to view the end drill status.
----End
8.4 Performing a VM Switchover

Step 1 Locate a switchover plan and click Switchover in the Operation column. On the Switchover
page, select the target VM, select Switchover, and click Confirm. On the displayed dialog
box, click Confirm to start the switchover.
Step 2 Click the arrow next to the task plan to view the switchover progress and result of each VM.
Step 3 Choose VM Switchover > Switchover Task to view the execution result of each task.
An agent supports a maximum of eight VMs to be concurrently. To support more VMs to be

concurrently, deploy multiple agents on different hosts and then perform the drill and switchover
operations.
If Succeeded is displayed in the Status column, the VM can be running on the target platform. You can
perform service check for the VM.
----End
8.5 Rolling Back the Switchover

This operation restores only data before the switchover. You are advised to back up the VM data, thus
avoiding data loss.
If an exception occurs on the VM that is switched to the target platform, roll back the VM.
Step 1 Locate the row that contains the VM to be rolled back, click More in the Operation column,
and select Rollback. Then, click Confirm in the dialog box that is displayed to start the
rollback operation.
Step 2 Choose VM Switchover > Switchover Task to view the execution result of the rollback task.
----End
8.6 Completing Switchover

If the VM that is switched to the target platform is running properly, locate the row that
contains the switchover task, click Switchover in the Operation column. On the displayed
page, select the target VM, select Finish Confirmation, and click Confirm. In the displayed
page, click Confirm.
Choose VM Switchover > Switchover Task to view the execution result of each task.
8.7 Adding Hosts on the Xen Platform to the KVM

Platform
Step 1 After all VMs on a host are switched over and the confirmation is complete, remove the host
from the source platform by referring to "Removing a Host" in FusionSphere V100R006C10
Product Documentation xx (Server Virtualization).
 When removing the last host from a data store, you can select only Thoroughly Delete. If dual-site
management is configured, data in the data store is not affected. If the VRM is deployed on a VM,
switch over all service VMs on the host where the VRM is located and the host is not processed. If
the KVM resources are insufficient, stop some service VMs and then switch over the service VMs.
 If the VRM is deployed on physical servers, switch over all service VMs on all hosts, and the VRM
nodes are not processed. If the KVM resources are insufficient, stop some service VMs and then
switch over them.
Step 2 Install the FusionCompute 6.5.0 system in the host removed from the Xen platform by
following "Installing Hosts Using an ISO Image" in FusionSphere Virtualization Suite 6.5.0
Product Documentation, and add the host to the target platform by following "Adding Hosts"
----End
9 Operations After Finish Confirmation
9.1 Deleting PCS Controller and Agent VMs

After all VMs are switched over from the Xen platform to the KVM platform and Confirm
Completion is performed for all tasks, stop or delete PCS controller and agent nodes based on
"Deleting a VM" or "Stopping a VM" in the FusionSphere Virtualization Suite 6.5.0 Product
Documentation.
 To stop or delete PCS controller and agent nodes, ensure that all switchover tasks are carried out
successfully.
 After the stop or deleting operations, rollback cannot be performed for VMs that are subjected to the
switchover.
9.2 Disabling Dual-site Management

9.2.1 In the Xen Platform
Step 1 Disassociate hosts in the Xen platform from VIMS. For details, see "Disassociating Hosts
from a Data Store" in Batches in the FusionSphere V100R006C10 Product Documentation xx
(Server Virtualization).
Step 2 Disassociate storage resources from hosts on the Xen platform.
For details, see "Disassociating a Storage Resource from a Host" in Batches in the
FusionSphere V100R006C10 Product Documentation xx (Server Virtualization).
If the data store is FC SAN, log in to the FC SAN management page and remove the initiator associated
with the host.
Step 3 On the FusionCompute web client of the Xen platform, choose Resource Pools > Storage. In
the Storage Device tab, click Scan, and select the host from which the storage device is
disassociated to perform the scan, and click OK.
In the dialog box that is displayed, click OK. After the scan is complete, no shared storage
device is available on the host.
----End
9.2.2 Deleting Dual-site Management Configuration

Step 1 Log in to the FusionCompute 6.5.0 web client and choose System > Connect To > Dual-site
Management.
Step 2 Click Clear All.
----End
9.2.3 Restoring Configurations on the FusionCompute

V100R006C10SPH108 Platform
timeout.
Step 2 Run the sh /opt/galax/gms/common/ha/modifyVimsMultisiteSwitch.sh close command to
disable dual-site configurations.
----End
9.3 Converting the Disk Format from VHD to RAW

 After the switchover, the disk VHD format must be changed RAW to improve performance.
 Format conversion operation occupies storage resources, and after the operation, the occupied
resources are released. Lazy zeroed disks occupy the total disk capacity, and thin-provisioned disks
occupy actually used capacity.
 Format conversion operation has impacts on storage I/O. You are advised to perform conversion
operation during off-peak hours.
 The format conversion time depends on the available storage size. You are advised to select No limit
to improve the conversion efficiency.
 A data store supports the concurrent conversion of four disks while a host supports the concurrent
conversion of two disks.
 A template can provision VMs only after being converted into VHD.
9.3.1 Conversion By VM
Step 1 Log in to the FusionCompute 6.5.0 web client, choose Resource Pools > VM, and then click
Advanced Search, select VHD for Disk Format, and click Search.
VMs that have VHD disks are displayed.
Step 2 Locate the target VM, click More in the Operation column, and choose Convert Format.
Alternately, select multiple VMs, click Convert Format in the Operation column.
----End
9.3.2 Conversion By Disk

Step 1 Log in to the FusionCompute 6.5.0 web client, choose Resource Pools > Storage > Data
Store. On the displayed page, click the VIMS that is used, click Disk List, select VHD from
the drop-down list, and click the search button.
Step 2 Locate a disk, click More in the Operation column, choose Convert Format, select a
suitable mode for Switchover Speed, and click Confirm.
Step 3 Perform the conversion operation for all VHD disks.
----End
9.3.3 Restoring Configurations on the FusionCompute 6.5.0

Platform
timeout.
Step 2 Run the sh /opt/galax/gms/common/ha/modifyVimsMultisiteSwitch.sh close command to
disable dual-site configurations.
----End
9.3.4 Adding the Host or VRM Node (Deployed on Physical

Servers) Where the VRM VM Is Located on the XEN Platform to
the KVM Platform
Step 1 Log in to the management page of FusionCompute V100R006C10SPH108 and verify that no
service VM except the VRM VM exists.
Step 2 Install the FusionCompute 6.5.0 system in the host or VRM node removed from the Xen
platform by following "Installing Hosts Using an ISO Image" in FusionSphere Virtualization
Suite 6.5.0 Product Documentation, and add the host or VRM node to the target platform by
following "Adding Hosts".
----End
9.4 (Optional) Modifying the IP Address of the VRM

Node
If you need to change the VRM IP address to the original address, change the VRM address
by following "Changing the VRM IP Address and Host Management IP Address" in
FusionSphere Virtualization Suite 6.5.0 Product Documentation.
9.5 (Optional) Migrating a VRM VM
To migrate the VRM VM to a specified host, see "Migrating a VRM VM" in FusionSphere
Virtualization Suite 6.5.0 Product Documentation.
9.6 Importing a License File

Apply for a license based on "Applying for a New License File" and import a license based on
"Loading a FusionCompute License File" in FusionSphere Virtualization Suite 6.5.0 Product
Documentation.
10 Appendix 1 Common Operations
10.1 Verifying Software Packages

 Software packages that have been tampered with or sabotaged during transmission may
pose a security threat to the carrier's network. After obtaining the software packages,
verify their integrity, and do not use them unless they pass the integrity check.
 Each software package has its own digital signature file. The file name extension of a
digital signature file is asc. Usually, the name of the digital signature file is the same as
that of the software package. For example, if the name of the software package is
FusionSphere PCS.zip, the name of its digital signature file is FusionSphere
PCS.zip.asc.
Step 1 Log in to http://support.huawei.com/enterprise.
Step 2 Download the software digital signature validation tool (PGP Verify) from the following link:
http://support.huawei.com/enterprise/toolsinfo?idAbsPath=0602_ROOT|
8221819&pid=8221819&show=showServiceDetail&versionid=TV1000000014
Step 3 Verify the software package integrity by referring to the OpenPGP Signature Verification
Guide.
----End
10.2 Guest OSs that Support Switchover

No. Guest OS Name
1 CentOS 5.11_64bit
2 CentOS 6.0_32bit
3 CentOS 6.0_64bit
4 CentOS 6.1_32bit
5 CentOS 6.1_64bit
6 CentOS 6.2_32bit
7 CentOS 6.2_64bit
8 CentOS 6.3_32bit
9 CentOS 6.3_64bit
10 CentOS 6.4_32bit
11 CentOS 6.4_64bit
12 CentOS 6.5_32bit
13 CentOS 6.5_64bit
14 CentOS 6.6_32bit
15 CentOS 6.6_64bit
16 CentOS 6.7_64bit
17 CentOS 6.7_32bit
18 CentOS 6.8_32bit
19 CentOS 6.8_64bit
20 CentOS 6.9_32bit
21 CentOS 6.9_64bit
22 CentOS 6.10_64bit
23 CentOS 7.0_64bit
24 CentOS 7.1_32bit
25 CentOS 7.1_64bit
26 CentOS 7.2_64bit
27 CentOS 7.2_32bit
28 CentOS 7.3_64bit
29 CentOS 7.4_64bit
30 CentOS 7.5_64bit
31 Debian GNU/Linux 7.1.0_32bit
66 Ubuntu 14.04 server_32bit
67 Ubuntu 14.04 desktop_32bit
68 Ubuntu 14.04 desktop_64bit
70 Ubuntu 14.04.1 server_32bit
74 Ubuntu 14.04.3 desktop_32bit
84 Ubuntu Server 16.04.1_64bit
86 Red Hat Enterprise Linux 6.0_64bit
111 Rocky Secure Server V6.0.80 64bit
112 Oracle Linux 5.7_64bit
136 SUSE Linux Enterprise Server 11 SP3_32bit
143 openSUSE Leap 15.0_64bit
144 openSUSE 42.1_64bit
147 Fedora 24_64bit
148 Fedora 25_64bit
149 Scientific Linux release 6.3_32bit
152 EulerOS 2.1_64bit
155 Red Flag Asianux Server 4 SP2_64bit
156 Red Flag Asianux Server 4 SP4_64bit
157 Red Flag Asianux Server 7.3_64bit
158 NeoKylin Linux Advanced Server release 6.5_64bit
159 NeoKylin Linux Trusted OS V6_64bit
160 Deepin GNU/Linux (Server 15)_64bit
161 Astra Linux 1.4_64bit
162 NewStart V4_64bit
163 Windows Server 2008 Enterprise SP1_32bit
164 Windows Server 2008 Enterprise SP1_64bit
165 Windows Server 2008 Standard SP1_32bit
169 Windows Server 2008 DataCenter SP2_32bit
170 Windows Server 2008 R2 Datacenter_64bit
171 Windows Server 2008 R2 Enterprise_64bit
172 Windows Server 2008 R2 Standard_64bit
173 Windows Server 2008 WEB R2_64bit
174 Windows Server 2008 DataCenter R2 SP1_64bit
175 Windows Server 2008 Enterprise R2 SP1_64bit
176 Windows Server 2008 Standard R2 SP1_64bit
177 Windows 7 Ultimate_32bit
178 Windows 7 Ultimate_64bit
179 Windows 7 Professional_32bit
180 Windows 7 Professional_64bit
181 Windows 7 SP1 Ultimate_32bit
182 Windows 7 SP1 Ultimate_64bit
183 Windows 7 SP1 Professional_32bit
184 Windows 10_32bit
185 Windows 10_64bit
186 Windows 10 Enterprise_32bit
187 Windows 10 Enterprise_64bit
188 Windows Server 2012 Datacenter_64bit
189 Windows Server 2012 Standard_64bit
190 Windows Server 2012 R2 Datacenter_64bit
191 Windows Server 2012 R2 Standard_64bit
192 Windows Server 2012 Essentials R2_64bit
193 Windows Server 2016 DataCenter_64bit
194 Windows Server 2016 Standard_64bit
10.3 Guest OSs that Do Not Support UEFI l After

Switchover
No. Guest OS Name
10.4 Account Information List

To ensure system security, you are advised to periodically change the default passwords of the
internal accounts of PCS using the recommended methods.
The following table lists the common login accounts.
Account Default Account Account Rights Password

Description Protection Policy
PCS login account Username: admin Has the rights of the  Change the default
Password: system administrator. password upon
IaaS@PORTAL- the first login.
CLOUD9!  If you enter
incorrect
passwords for
three consecutive
times, the
account will be
locked for five
minutes.
OS account Username: gandalf Has the rights of a If you enter
Password: common OS user. incorrect passwords
IaaS@OS- for three consecutive
CLOUD9! times, the account
will be locked for
five minutes.
OS account Username: root Has the OS If you enter
Template import: administrator rights. incorrect passwords
IaaS@OS- for three consecutive
CLOUD8! times, the account
will be locked for
five minutes.
Common user Username: pcsuser Has the permission to If the password is
account of the Password: log in to and operate entered incorrectly
controller node SingleLOUD!1 the Gauss database. for five consecutive
database Database: pcs times, the account
When you connect will be locked for
to the database by five minutes.
running the psql
command, enter the
database password
in interactive mode.
Otherwise, the
database password
theft may be caused.
Controller node Username: postgres This account is the The account will not
database Password: super administrator in be locked if an
administrator cloudos@123 the database and can incorrect password
account be used to create a is entered.
database and user
account, and back up
data.
Table 10.4.1.1.1.1.1.1.1 Internal OS accounts

Account Permission Description
root Has all operation Linux system administrator account

permissions for the system.
bin Default system service System account of the bin service
accounts of the Linux OS.
daemon External users cannot use System account for controlling
these accounts to log in to background processes
the Linux system.
lp Print service account
mail Account for accessing the mailbox
in the /var/mail directory
games Games service account
ftp File Transfer Protocol (FTP) service
account
nobody Default system account of the user
identification service
ntp Default system account of the
Network Time Protocol (NTP)
daemon process
sshd Default system account of the sshd
daemon process
adm adm account
sync Synchronization service account
shutdown Account for the shutdown service
halt Account for the halt service
operator Operation account
systemd-bus- systemd Bus Proxy account
proxy
systemd-network systemd Network Management
account
dbus System message bus account
tss TrouSerS account used for trusted
computing
saslauth Saslauthd Daemon account
rpc RPC service account
unbound Unbound DNS resolver account
polkitd polkit service account
radvd Router Advertisement Daemon
account
rpcuser RPC service account
nfsnobody NFS service account
qemu Simulated I/O account in
virtualization
10.5 Applying for a New License File

 Versions earlier than V100R006
− Upgrade the system based on the upgrade guide and then change the license file
based on section "Applying for a License for an Upgrade Project" in FusionSphere
Virtualization Suite 6.5.0 License Delivery Guide.
− After the switchover from Xen to KVM, change the ESN contained in the license file
based on section "Changing an ESN" in FusionSphere Virtualization Suite 6.5.0
License Delivery Guide.
 V100R006
After the switchover from Xen to KVM, change the ESN contained in the license file
based on section "Changing an ESN" in FusionSphere Virtualization Suite 6.5.0 License
Delivery Guide.
10.6 Changing the Password of User root for a Node

Scenarios
Change the password for logging in to the operating system (OS) of a host as user root. This
operation helps improve the operation and maintenance security of the system.
Prerequisites
Conditions
 An application, such as PuTTY, which can be used for remote access on various
platforms is available.
 You have obtained the management IP address of the node.
 You have obtained the passwords of user root and user gandalf for logging in to the
node.
The default password of user gandalf is IaaS@OS-CLOUD9!, and the default password of user root is
IaaS@OS-CLOUD8!.
Procedure
Step 1 Use PuTTY to log in to the OS of the node.
Ensure that the management IP address and username gandalf are used to establish the
connection.
The system supports the login authentication using a password or private-public key pair. If
you use a private-public key pair to authenticate the login, see section 10.9"Using PuTTY to
Log In to a Node in Key Pair Authentication Mode."
Step 2 Run the following command and enter the password of user root to switch to user root:
su - root
Step 3 Run the following command to disable user logout upon system timeout:
TMOUT=0
Step 4 Run the following command to change the password of user root:
passwd
The following information is displayed:
Changing password for user root.
Changing password for root.
(current) UNIX password:
Step 5 Enter the old password and press Enter.

New Password:
Step 6 Enter a new password and press Enter.
The password must meet the requirements in the following table.
Parameter Description Example Value
Password  The password must contain at least eight GalaX8800!

characters.
 The password must contain at least three of
the following combinations:
- Uppercase letters
- Lowercase letters
- Digits
- Spaces or special characters `~!@#$
%^&*()-_=+|[{}];:'",<.>/?
 The password cannot contain the username
or the reverse username.
 The password cannot contain a word from
the Linux password dictionary.

Retype new password:
If the following information is displayed, this password cannot be used and you must enter
another one:
BAD PASSWORD: ...
Step 7 Enter the new password again and press Enter.
The password is changed if the following information is displayed:

passwd: all authentication tokens updated successfully.
----End
10.7 Changing the Password of the User gandalf for a

Node
Scenarios
Change the password for logging in to the operating system (OS) of a node as user gandalf.
This operation helps improve the operation and maintenance security of the system.
Prerequisites
Conditions
 You have obtained the management IP address of the node and the password of user
gandalf.
The default password of user gandalf is IaaS@OS-CLOUD9!.
Procedure
Step 1 Use PuTTY to log in to the OS of the node as user gandalf.
Ensure that the Management IP address is used to establish the connection.

Step 2 Run the following command to change the password of user gandalf:
passwd
Changing password for user gandalf.
Changing password for gandalf.
(current) UNIX password:

New password:
The password must meet the requirements in the following table.
Password  The password must contain at least eight GalaX8800!

characters.
 The password must contain at least three of
the following combinations:
- Uppercase letters
- Lowercase letters
- Digits
- Spaces or special characters `~!@#$
%^&*()-_=+|[{}];:'",<.>/?
 The password cannot contain the username
or the reverse username.
 The password cannot contain a word from
the Linux password dictionary.

Retype new password:
If the following information is displayed, this password cannot be used and you must enter
another one:
BAD PASSWORD: ...
The password is successfully changed if the following information is displayed:

passwd: all authentication tokens updated successfully.
----End
10.8 Changing admin User's Password

Scenarios
On the PCS portal, change a user's password to improve the system security.
Prerequisites
Conditions
You have logged in to PCS using the account to be changed.
Procedure
Step 1 In the upper right corner of PCS, click the name of the current login user.
Step 2 Click Change Password.
The Change Password dialog box is displayed.

Step 3 Enter the old password and the new password.
The new password must meet the requirements in the following table.
Parameter Description Example

Value
New  Specifies the password to be set. Galax@8800

Password  Default value: a string of 8 to 32 characters
 The password must contain at least one space or one of
the following special characters: `~!@#$%^&*()-
_=+\|[{}];:'",<.>/?
 The password must contain at least two of the
following combinations:
- Uppercase letters
- Lowercase letters
- Digits
 The password cannot contain the username or the
reverse username.
 The password modification must comply with the
configured password policies.
Step 4 Click Confirm.
The password is changed.

----End
10.9 Using PuTTY to Log In to a Node in Key Pair

Authentication Mode
Scenarios
Use PuTTY and the required private key to log in to a target node.
Prerequisites
You have obtained the private key certificate matching the public key certificate.
You have obtained the password of the private key certificate if the private key certificate is
an encrypted certificate.
To obtain the default private key certificate, visit the following websites:
 For enterprises: Visit http://support.huawei.com/enterprise and choose Support >
Software Download > Cloud Computing > FusionSphere Virtualization Suite >
FusionCompute > FusionCompute 6.5.0.
 For carriers: Visit http://support.huawei.com and choose Support > Software > Carrier
IT > Cloud Computing > FusionCloud > FusionSphere > FusionCompute >
FusionCompute 6.5.0.
Procedure
Step 1 Check whether PuTTY on the local PC has been used to log in to a node in key pair
authentication mode.
 If yes, go to Step 7.
 If no or you cannot confirm, go to Step 2.
Step 2 Run PuTTY and enter the IP address of the target node and the SSH port number (default
value: 22).
Step 3 In the Category area in the left pane, choose Connection > SSH > Auth.
The SSH authentication configuration page is displayed.
Step 4 Click Browse, select the prepared private key certificate in the displayed window, and click
Open.
The file name extension of the private key certificate is *.ppk. Contact the administrator to
obtain the private key certificate.
The following figure shows the SSH authentication configuration page.
Figure 10.9.1.1.1.4.1.1 Configuring the private key certificate
Step 5 In the Category area in the left pane, select Session.
The main page is displayed.

Step 6 To facilitate subsequent access, create a custom session in Saved Sessions and click Save.
The following figure shows the session configuration page.

Figure 10.9.1.1.1.6.1.1 Saving a session
After this step, go to Step 8.

Step 7 Select a saved session and click Load.
Step 8 Click Open.
Step 9 Enter the username for logging in to the target node as prompted.
If the private key certificate is an encrypted certificate, enter the password of the private key
certificate as prompted.
The default private key certificate delivered with the version release is an encrypted
certificate, and its default password is Huawei@CLOUD8!.
----End
10.10 Restoring Data

Scenarios
This section guide maintenance engineers to restore the data of controller nodes.
If an exception occurs in the controller node system, you need to restore its data.
Before you restore data, back up the data on the abnormal controller node to ensure that lost
data can be retrieved after the data restoration.
 If the controller node is installed again due to a fault, restore the data by performing operations
starting from Step 9.
Impact on the System

 During data restoration, the processes on the controller nodes are stopped.
 After data restoration, the data produced between the backup time and restoration time is
lost.
Prerequisites
Conditions
 The required backup file is available on the controller node or a third-party backup
server.
 A local PC is available to access the controller node.
 You have obtained the IP addresses and the root user password of controller nodes .
 The system is running properly.
 The following conditions are met if the files backed up on the third-party server are used
to restore data:
− The local PC communicates with the third-party backup server properly.
− You have obtained the IP address of the third-party backup server.
− If the third-party backup server uses a Windows operating system (OS), you have
obtained the OS login username and password. If the backup server uses a Linux OS,
you have obtained the password of user root.
− The FTPS Server application is installed on the third-party backup server.
Procedure
Back up the data on the abnormal controller node.
Step 1 Use PuTTY to log in to the controller node.
Ensure that the management plane IP address and username gandalf are used to establish the
connection.
su - root
TMOUT=0
Step 4 Run the following command to back up the data:
cronBackupUpload
The backup path is /var/backup/.
Copy the required backup file to the controller node.
Step 5 Run the following command to check whether any directory containing backup files is
available on the controller node:
ll Directory containing backup files
The directory is:
 /var/backup/ for automatic backup files
 /var/backup/month/ for automatic monthly backup files
The data automatically backed up each month is stored only in the /var/backup/month directory.
No directory containing backup files is available on the controller node if the following
information is displayed:
ls: cannot access /var/backup/: No such file or directory
The directory containing backup files is available on the controller node and this directory
contains backup data if information similar to the following is displayed:
total 4
drwx------ 4 root root 4096 May 27 17:56 2013-05-27_0000000001
Step 6 Based on the command output in Step 5, check whether any directory containing backup files
is available on the controller node and the directory contains required backup data.
 If no, go to Error: Reference source not found.
Step 7 Run the following command to switch to the directory containing backup files on the
controller node:
cd Directory containing backup files
The directory is:
 /var/backup/ for automatic backup files
 /var/backup/month/ for automatic monthly backup files
Step 8 Run the following command to copy the required backup file to the /home/GalaX8800
directory on the controller node:
cp -r YYYY-MM-DD_sn /home/GalaX8800
YYYY-MM-DD indicates the date when backup is performed, and sn indicates the serial
number of the backup file.
Go to Step 14 after this step.
Step 9 Check the type of the OS used by the third-party backup server.
 If the third-party backup server runs the Windows OS, go to Step 10.
 If the third-party backup server runs the Linux OS, go to Step 12.
Contact the backup server administrator to perform operations on the third-party server if required.
Step 10 Log in to the third-party backup server over a remote desktop connection.
Step 11 Copy the required backup file from the third-party backup server to the local PC.
Go to Step 13 after this step.

 Backup file name: YYYY-MM-DD.tar.gz.zip
 Directory containing configuration files:
− Directory configured on the FTPS server\YYYY-MM-DD_sn\DATA\ for automatic
backup files
− Directory configured on the FTPS server\month\YYYY-MM-DD_sn\DATA\ for
automatic monthly backup files.
 Directory containing database files which need to be backed up only when the Gauss
database is being used:
− Directory configured on the FTPS server\YYYY-MM-DD_sn\DB\ for automatic
backup files
− Directory configured on the FTPS server\month\YYYY-MM-DD_sn\DB\ for
YYYY-MM-DD indicates the backup date, and sn indicates the serial number of a backup file
folder.
Step 12 Use WinSCP to copy the required backup file from the third-party backup server to the local
PC.
 Directory containing configuration files:
− Directory configured on the FTPS server/YYYY-MM-DD_sn/DATA/ for automatic
backup files
− Directory configured on the FTPS server/month/YYYY-MM-DD_sn/DATA/ for
 Directory containing database files which need to be backed up only when the Gauss
database is being used:
− Directory configured on the FTPS server/YYYY-MM-DD_sn/DB/ for automatic
backup files
− Directory configured on the FTPS server/month/YYYY-MM-DD_sn/DB/ for
Step 13 Use WinSCP to copy the required backup file from the local PC to the /home/GalaX8800
directory on the controller node:
 Directory containing manually-copied configuration files: /home/GalaX8800/YYYY-
MM-DD_sn/DATA/
 Directory containing manually-copied database files: /home/GalaX8800/YYYY-MM-
DD_sn/DB/, which is available only when the Gauss database is being used
Restore data of the controller node.
Ensure that the management IP address of the controller node is used for logging in to the controller
node.
Step 14 Use PuTTY to log in to the controller node and switch to user root.
Ensure that username gandalf and the management IP address of the controller node are used
to establish the connection.
Step 15 Run the following command to restore configuration data of the controller node:
restoreGeData -t DATA -f /home/GalaX8800/YYYY-MM-DD_sn/DATA/Backup file name

The data is restored if the following information is displayed:
Congratulations! Your restore task ran successfully.
Step 16 Run the following command to restore data in the database of the controller node:
restoreGeData -t DB -f /home/GalaX8800/YYYY-MM-DD_sn/DB/backup file name

The data is restored if the following information is displayed:
Congratulations! Your restore task ran successfully.
Step 17 Use PuTTY to log in to the controller node and run the following command to check the
software monitoring process status until the process stays in the running state:
service had query
The software monitoring process is in the running state if the following information is
displayed:
NODE ROLE PHASE RESS VER START
ha1(PCSC) active Actived normal V100R001C01 2019-08-15

22:22:32
-------------------------------------------------------------------------------------------
-------------
ID RES STAT RET TYPE
ha1(PCSC): 1 cron Normal Normal

Double_active
2 gaussdb Normal Active_normal

Active_standby
3 mngrFloatIp Normal Normal

Single_active
4 ntp Normal Normal

Double_active
5 pcsd Normal Normal Single_active

Observe the status of the controller node for 5 minutes. If the node automatically restarts during the
period, restore data for the controller node again. If the controller node restarts again after the data is
restored again, contact technical support.
----End
10.11 Switching VMs that Use the Port Group of the

Subnet Type
Background
If the source VM uses the port group of the subnet type as shown in 12.40Source Port Group
Is of the Subnet Type", to use the original dynamic IP address and ensure normal network
communication, perform the following operation.
Procedure
Principles and Preparations
Figure 10.11.1.1.1.1.1.1 DHCP service switch
3. Configure DHCP relay based on the

VRM dhcp server original configuration before NIC restart. Customer dhcp server
FC (KVM): does not
FC (Xen) VLAN:100 pvid VLAN:300
provide the DHCP
subnet:192.168.10.0/24 subnet:192.168.30.0/24
service.
IP:192.168.10.10 static IP:192.168.30.100
2. Obtain the IP address

1. Obtain the IP from the Xen platform after 4. Obtain the dynamic IP
address from the the switch. address from the new
Xen platform. DHCP server.
VM
VM
PortGroup:PG200
PortGroup:TestSubnetPG
VLAN:200
VLAN:200 PCS migration
subnet:192.168.20.0/24
subnet:192.168.20.0/24
after switch:192.168.20.3
Dynamic IP:192.168.20.3
after restart:192.168.20.3
On the Xen platform, if a port group of the subnet type is selected during VM deployment, the
VM can obtain the dynamic IP address from the DHCP service provided by VRM. However,
VRM on the KVM platform does not provide the DHCP service and the platform does not
support the port group of the subnet type. To use the original IP address and avoid a failure of
binding to the IP address after the switch, perform the following operation while the network
resource allocation as shown in the preceding figure is used as an example:
 Ensure that the source and destination port groups use the same VLAN.
 Create a DHCP server on the KVM platform.
 Obtain the password of the switch where the gateway corresponding to VLAN 200
(switch network VLAN) locates.
 Allow packets carrying VLANs for VMs and DHCP servers to pass the KVM platform.
 Configure the new DHCP server on the Xen platform based on configuration files on the
original VRM.
− DHCP server configuration file: /etc/galax/dhcp_conf/nrm-dhcp.conf
− DHCP lease file: /etc/galax/dhcp/nrm-dhcp.leases
As the DHCP servers on the two platforms are different in the version, only configuration file
copy may cause abnormal DHCP service. You need to configure the new DHCP server as
required.
Assume that in the nrm-dhcp.conf file, the following configuration is set and the information
in green indicates the subnet on which the ports to be switched over locate.
shared-network nrm {
subnet 192.168.20.0 netmask 255.255.255.0{
option subnet-mask 255.255.255.0;
option routers 192.168.20.1;
}
}
Use DHCP 4.2.5 server running CentOS 7 is used as an example. Configure
etc/dhcp/dhcp.conf based on the preceding information in green.
subnet 192.168.20.0 netmask 255.255.255.0{
range 192.168.20.100 192.168.20.110;
#option subnet-mask 255.255.255.0;
option routers 192.168.20.1;
}
As the configuration files have different formats, the configuration file for the new DHCP server does
not contain the shared-network nrm field, but has the range field added. If you just copy the original
configuration file, an error message "no free leases" is reported. For details about the configuration file
format, see the DHCP server specification configuration requirements.
The etc/galax/dhcp/nrm-dhcp.leases lease file may contain the following configuration:

host vnic-28-6e-d4-88-c6-fd {
dynamic;
hardware ethernet 28:6e:d4:88:c6:fd;
fixed-address 192.168.20.105;
}
You can copy the information to the leases configuration file of the new DHCP server.
If the leases configuration file of the new DHCP server has the fixed address corresponding to the MAC
address, ignore the NIC. Before the switch, ensure that there is no NIC whose MAC address is the same
as that on the source platform, thus avoiding a switch failure.
Procedure
Step 1 Switch the VM with the IP address of 192.168.20.3 using PCS and confirm that the switch is
successful.
Step 2 Start the VM on the target platform.
As VLAN 200 is still used, you can obtain the old IP address through the DHCP service of the
original VRM. If the IP address cannot be obtained, check the DHCP status in the
/var/log/message file on the VRM (Xen).
 If a message "no free lease" is displayed, add the range field to the config file.
 If the DHCP service is normal, the VM IP address is still 192.168.20.3.
Step 2 After all VMs using port groups in TestSubnetPG are switched on the Xen platform, the
original DHCP server is to be deleted. Before the deletion, configure the DHCP relay on the
switch where the gateway corresponding to the VLAN locates.
The following uses Huawei switch as an example.
[~Kernel_IDF]display this
#
interface Vlanif2304
ip address 192.168.20.1 255.255.255.0
dhcp select relay
dhcp relay binding server ip 192.168.30.100
#
Return
Step 3 Start the DHCP service on the KVM platform based on the prepared configuration and lease
files.
Step 4 Restart the NIC and check whether its dynamic IP address can be obtained.
----End
10.12 Changing Passwords of Interconnection Accounts

During the Switchover
Passwords of interconnection accounts can be changed during the switchover to improve
system security or retrieve the passwords. However, password change is risky because the
change will cause communication failures. Therefore, exercise caution when changing the
passwords.
For details about how to change passwords of accounts for logging in to the FusionCompute
Xen platform, see Operation And Maintenance > Maintenance Management > Maintenance
Management in Single-Hypervisor Scenarios > Security Management > FusionCompute
Account Management (Common Mode) > Resetting the Password in FusionSphere
V100R006C10 Product Documentation (Server Virtualization).
For details about how to change passwords of accounts for logging in to the FusionCompute
KVM platform, see Operation And Maintenance > Maintenance Management > Maintenance
Management in Single-Hypervisor Scenarios > Security Management > FusionCompute
Account Management > Resetting the Password in FusionSphere Virtualization Suite 6.5.0
Product Document.
If you have changed the passwords of interconnection accounts for cloud platform dual-site
management, log in to FusionCompute 6.5.0, choose System > Connect To > Dual-site
Management, and change the password to the new one.
If you have changed the passwords of accounts for interconnecting with the PCS cloud
platform, log in to the FusionSphere PCS management console, choose Cloud Platform
Management, and click Modify corresponding to the target cloud platform. On the Modify
Cloud Platform page, change the password to the new one.
10.13 Performing the Switchover of eBackup

Management VMs and Backup VMs
Deleting Permissions Configured for eBackup Management VMs
Step 1 Obtain the username and password of the administrator and log in to FusionCompute
V100R006C10SPH108.
Step 2 Delete all permissions configured for eBackup management VMs. For details, see section
"Operation and Maintenance" > "Service Management" > " Service Management in Single-
Hypervisor Scenarios" > "Virtual Machine Management" > "VM Operation Management" >
"Configuring Object Rights" in FusionSphere V100R006C10 Product Documentation (Server
Virtualization).
----End
Performing the Switchover of eBackup Management VMs
Switch OceanStor BCManager eBackup management VMs from FusionCompute
V100R006C10SPH108 to the FusionSphere virtualization suite 6.5.0 platform by performing
the operations provided in section 8"VM Drill and Switchover."
Configuring Permissions for eBackup VMs on the FusionSphere Virtualization Suite

Platform
Step 1 Obtain the username and password of the administrator and log in to FusionCompute on the
FusionSphere virtualization suite 6.5.0 platform.
Step 2 Configure permissions for eBackup management VMs by performing the operations provided
in section "Operation and Maintenance" > "Service Management" > " Service Management in
Single-Hypervisor Scenarios" > "Virtual Machine Management" > "VM Operation
Management" > "Configuring Object Rights" in FusionSphere Virtualization Suite 6.5.0
Product Documentation.
For details about permissions to be disabled, see Configure object rights for a eBackup
VM. in section "User Guide" > "Virtual Backup" > "Installation and Uninstallation" >
"Installing eBackup" > "Installing eBackup Using a Template" in OceanStor BCManager
eBackup Product Documentation.
----End
Upgrading eBackup to the Required Version

Step 1 Determine the target version of eBackup based on the FusionSphere Virtualization Suite 6.5.0
Version Mapping.
Step 2 Upgrade eBackup based on the corresponding upgrade guide of OceanStor BCManager
eBackup.
----End
Adding FusionSphere Virtualization Suite 6.5.0 As a Protected Environment

Add the target FusionSphere virtualization suite platform to eBackup as a protected
environment. For details, see section "User Guide" > "Virtual Backup" > "Backup" >
"Configuring Production Storage" > "Adding a FusionSphere Protected Environment" in
OceanStor BCManager eBackup Product Documentation.
Performing the Switchover of Backup VMs

Switch backup VMs from FusionCompute V100R006C10SPH108 to the FusionSphere
virtualization suite 6.5.0 platform by performing the operations provided in 8"VM Drill and
Switchover."
Removing Switched Backup VMs from the Protected Set on eBackup

Modify the protected set and remove VMs switched from FusionCompute
V100R006C10SPH108 to the FusionSphere virtualization suite 6.5.0 platform from the
protected set. For details, see section "User Guide" > "Managing Backup and Restore" >
"Protected Set Management" in OceanStor BCManager eBackup Product Documentation.
After the switchover, protected environments will be scanned. eBackup will detect that the source VMs
are not in the environment and remove them from the protected set.
----End
Creating a Protected Set and Backup Plan for the Target Protected Environment
 If the backup VM that is switched to the FusionSphere virtualization suite 6.5.0 platform
is the first VM in the protected set, perform Step 1.
 If the backup VM that is switched to the FusionSphere virtualization suite 6.5.0 platform
is not the first VM in the protected set, perform Step 3.
Step 1 Create a protected set for the protected environments on the FusionSphere virtualization suite
6.5.0 platform based on the procedure for creating that on FusionCompute
V100R006C10SPH108. Add the VMs switched to the target platform to the created protected
set. For details, see section "User Guide" > "Virtual Backup" > "Backup" > "Creating a
Protected Set" in OceanStor BCManager eBackup Product Documentation.
Step 2 Use the created protected set and backup policies in the original backup plan to create the
backup plan for the protected environments on the FusionSphere virtualization suite 6.5.0
platform based on the procedure for creating that on FusionCompute V100R006C10SPH108.
For details, see section "User Guide" > "Virtual Backup" > "Backup" > "Creating a Backup
Plan" in OceanStor BCManager eBackup Product Documentation.
After this step is performed, no further action is required.
Step 3 Scan the protected environments on the target platform to detect VMs switched to the
FusionSphere virtualization suite 6.5.0 platform. For details, see section "User Guide" >
"Virtual Backup" > "Backup" > "Configuring Production Storage" > "Adding a FusionSphere
Protected Environment" in OceanStor BCManager eBackup Product Documentation.
Step 4 Modify the protected set and add VMs switched to the FusionSphere virtualization suite 6.5.0
platform to the protected set. For details, see section "User Guide" > "Managing Backup and
Restore" > "Protected Set Management" in OceanStor BCManager eBackup Product
Documentation.
----End
10.14 Creating Interconnection Accounts on Cloud

Platforms
Creating interconnection accounts on FusionCompute V100R006C10SPH108
Log in to the FusionCompute V100R006C10SPH108 management page and create an
interconnection account. Alternatively use user admin.
To create an account, choose System > Rights Management > User Management and click
Add User. On the Add User page, select Interface interconnection user for User Type and
administrator for Subrole and set other parameters as required. Then click OK.
To avoid account conflict, you need to create an account for dual-site management
configuration. In the separation of roles scenarios:
 Log in to the system as user sysadmin and choose System > Rights Management > User Management
to create an interconnection account.
 Log in to the system as user secadmin, and choose System > Rights Management > User
Management. Locate the target user, click More in the Operation column, and select Activate User.
In the displayed page, select System administrator for User Type and sysadmin for Subrole and then
click Confirm.
Creating interconnection accounts on FusionCompute 6.5.0

Log in to the FusionCompute 6.5.0 web client and create an interconnection account.
Alternatively use user admin.
To create an account, choose System > Rights Management > User Management and click
Add User. On the Add User page, select Interface interconnection user for User Type and
administrator for Subrole and set other parameters as required. Then click OK.
In the separation of roles scenarios:

 Log in to the system as user sysadmin and choose System > Rights Management > User Management
to create an interconnection account.
 Log in to the system as user secadmin, and choose System > Rights Management > User
Management. Locate the target user, click More in the Operation column, and select Activate User.
In the displayed page, select System administrator for User Type and sysadmin for Subrole and then
click Confirm.
10.15 Replacing the Security Authentication Certificate

for Controller Nodes and Agent Nodes
Scenarios
This section describes how to manually replace the security authentication certificates for the
controller nodes and agent nodes when the system is running properly, improving system
O&M security.
The product supports only level-2 security certificates.

Services will be temporarily interrupted during the certificate replacement. Continue with
other operations after service processes recover.
Prerequisites
Conditions
 You have obtained the root certificate, certificate file, and private key file from the third-
party Certificate Authority (CA).
 You have obtained PuTTY.
 You have obtained WinSCP.
 You have obtained the management IP address of the controller node and agent node of
the certificate to be replaced and the passwords of the gandalf user and root user.
Procedure
Check certificate files on the agent nodes.
Step 1 Use PuTTY to log in to the Agent nodes one by one.
connection.
su – root
TMOUT=0
Step 4 Run the following commands to switch to the directory that contains the certificates:
cd /opt/cloudos/pcs/agent/certs/
ll
Information similar to the following is displayed:
total 12
-rw------- 1 root root 1233 Feb 23 12:50 agent.crt
-rw------- 1 root root 1751 Feb 23 12:50 agent.key
-rw------- 1 root root 3567 Feb 23 12:50 ca.crt
In the preceding command output, ca.crt indicates the root certificate, and agent.crt indicates
the server's certificate file, and agent.key indicates the server's private key file.
The new certificate files should be placed in the directory the same as that containing original ones. If
the newly replaced certificate has the same name as the original certificate, you need to back up the
original certificate.
If you have changed the certificate filename, accordingly change it in the configuration file by following
steps provided in (Optional) Modify the configuration file of the agent node.
Replace all certificate files on the agent nodes.

Step 5 Use WinSCP to copy the obtained server's root certificate, server's certificate, and server's
private key file to the /home/GalaX8800/ directory of the agent nodes.
Ensure that user gandalf is used to establish the connection.
Step 6 Run the following commands to copy certificates:
cp /home/GalaX8800/obtained certificate file /opt/cloudos/pcs/agent/certs/
The default password is FusionSphere123. If you have changed the password of private key file,
accordingly change it in the configuration file by following steps provided in (Optional) Modify the
configuration file of the agent node.
Step 7 Run the following command to restart the pcs-agent service:
systemctl restart pcs-agent

Check certificate files on the controller nodes.
Step 8 Use PuTTY to log in to the controller nodes.
connection.
su - root
TMOUT=0
Step 11 Run the following commands to switch to the directory that contains the certificates:
cd /opt/cloudos/pcs/controller/conf
ll
Information similar to the following is displayed:
total 208
-rw-r--r-- 1 root root 6561 Feb 23 16:29 catalina.properties
-rw------- 1 root root 216 Feb 23 16:29 gaussdbpwd.conf
-rw-r--r-- 1 root root 3420 Feb 23 16:29 logging.properties
-rw------- 1 root root 2469 Feb 23 16:29 PcsClientKeyStore.p12
-rw------- 1 root root 1409 Feb 23 16:29 PcsTrustKeyStore.jks
-rw------- 1 root root 1766 Feb 23 16:29 server-private-key.pem
-rw-r--r-- 1 root root 7727 Feb 23 18:52 server.xml
-rw------- 1 root root 1314 Feb 23 16:29 tomcat-server-cert.pem
-rw-r--r-- 1 root root 169585 Feb 23 16:29 web.xml
In the preceding command output, PcsTrustKeyStore.jks indicates the root certificate, and
PcsClientKeyStore.p12 indicates the certificate file.
The new certificate files should be placed in the directory the same as that containing original ones. If
the newly replaced certificate has the same name as the original certificate, you need to back up the
original certificate.
If you have changed the certificate filename, accordingly change it in the configuration file by following
steps provided in (Optional) Modify the configuration file of the controller node.
Generate authorization certificates for controller node.

Step 12 Use WinSCP to copy the obtained server's root certificate, server's certificate, and server's
private key file to the /home/GalaX8800/ directory of the controller node.
Ensure that user gandalf is used to establish the connection.
Step 13 Run the following command to switch to the /home/GalaX8800/ directory:
cd /home/Galax8800
Step 14 Run the following command to generate client's certificate files (.pkcs12):
openssl pkcs12 –export –in Client's certificate file name –inkey Client's private key file
name –passin pass: Obtained client's certificate encryption password –out Name of the
client's certificate file (.pkcs12) to be generated –passout pass: Password of the client's
certificate file (.pkcs12) to be generated
For example, if the client's certificate file is agent.crt, client's private key file is agent.key,
the client's certificate encryption password and the password of the client's certificate file
(.pkcs12) to be generated are all FusionSphere123, and the client's certificate file (.pkcs12) to
be generated is PcsClientKeyStore.p12, run the following command:
openssl pkcs12 –export –in agent.crt –inkey agent.key –passin pass:FusionSphere123 –out
PcsClientKeyStore.p12 –passout pass:FusionSphere123
Step 15 Run the following command to generate the truststore certificate (.jks):
keytool –import –alias rootCA –file Root certificate file name –keystore Name of the
trustkeystore file(.jks) to be generated
For example, if the root certificate file is ca.crt, and the truststore certificate file (.jks) to be
generated is PcsTrustKeyStore.jks, run the following command:
keytool –import –alias rootCA –file ca.crt –keystore PcsTrustKeyStore.jks
Step 16 As prompted, enter the user-defined client's truststore password.
Enter keystore password:
The default password is FusionSphere123. If you have changed the truststore password, accordingly
change it in the configuration file by following steps provided in (Optional) Modify the configuration
file of the controller node.
The passwords of client's keystore and client's truststore must be the same.
Step 17 As prompted, enter the user-defined client's truststore password again.
Re-enter new password:
Step 18 As prompted, enter y and press Enter to trust this certificate.
Trust this certificate? [no]:
Step 19 The truststore certificate (.jks) has been generated if the following information is displayed:
Certificate was added to keystore
Replace all certificate files on the controller nodes.

Step 20 Run the following command to remove certificate file.
cd /opt/cloudos/pcs/controller/conf
rm PcsClientKeyStore.p12 PcsTrustKeyStore.jks
Step 21 Run the following commands to import certificate file.
cp /home/GalaX8800/Name of the generated truststore certificate file (.jks)

/opt/cloudos/pcs/controller/conf/
cp /home/Galax8800/Name of generated keystore certificate file(.p12)
/opt/cloudos/pcs/controller/conf
Step 22 Run the following command to restart the pcsd service:
systemctl restart pcsd

(Optional) Modify the configuration file of the agent node.
connection.
su – root
TMOUT=0
Step 26 If you need to modify the private key password, go to Step 27. Otherwise, go to Step 31.
Step 27 Run the following command to invoke the encryption tool:
kmctool –e
Step 28 As prompted, enter the plaintext to be encrypted and press Enter to generate the encrypted
information.
please input password:
The encrypted information has been generated if the following information is displayed.
Where cipherLen indicates the ciphertext length and cipher indicates the encrypted
ciphertext.
FS_KMC_Encrypt success.
cipherLen=[216]
cipher=[AAAAAQAAAAEAAAAAAAAABQAAAAEAAAABEoKhjHVc/5+WP2Mij7mO
FLVN4HB4bBZbBW+5q4+0J/wAAAAQAAAAAAAAAACsxdxm4hxDymyfhnF7TxH4AA
AAAQAAAAAAAAgEAAAAAQAAAAEgZKuX79jh3HOKCu+WhRLUAAAAAAAAAA
BU32Iet4WHptpa3MZoLkP5D0u72/80I1yioVLk9uf8Yg==]
Step 29 Run the following command to open the agent.conf configuration file using the vi editor:
vi /opt/cloudos/pcs/agent/conf/agent.conf
Press i to enter the editing mode.
Change the ssl.agent.key.passwd value in the configuration file.
Change the ssl.agent.key.passwd value to the ciphertext noted down in Step 28. The changed
configuration file is as follows:
ssl.agent.key.passwd=AAAAAQAAAAEAAAAAAAAABQAAAAEAAAABEoKhjHVc/5+
WP2Mij7mOFLVN4HB4bBZbBW+5q4+0J/wAAAAQAAAAAAAAAACsxdxm4hxDymyfh
nF7TxH4AAAAAQAAAAAAAAgEAAAAAQAAAAEgZKuX79jh3HOKCu+WhRLUAAA
AAAAAAABU32Iet4WHptpa3MZoLkP5D0u72/80I1yioVLk9uf8Yg==
Step 30 Press Esc and enter :wq to save the configuration and exit the vi editor.
Step 31 If you need to modify root certificate filename or file path, go to step Step 32. Otherwise, go
to Step 34.
Change the ssl.ca.cert.path value to the latest root certificate path and file name.
Step 34 If you need to modify certificate filename or file path, go to Step 35. Otherwise, go to Step
37.
Change the ssl.agent.cert.path value to the latest server certificate path and file name.
Step 37 If you need to modify certificate filename or file path, go to Step 38. Otherwise, go to Step
40.
Change the ssl.agent.key.path value to the latest root certificate path and file name.
systemctl restart pcs-agent

(Optional) Modify the configuration file of the controller node.
Step 41 Use PuTTY to log in to the Controller node.
connection.
su – root
TMOUT=0
Step 44 If you need to modify the certificate access password, go to Step 45. Otherwise, go to Step 49.
Step 45 Run the following command to invoke the encryption tool:
kmctool –e
Step 46 As prompted, enter the plaintext to be encrypted and press Enter to generate the encrypted
information.
please input password:
The encrypted information has been generated if the following information is displayed.
Where cipherLen indicates the ciphertext length and cipher indicates the encrypted
ciphertext.
FS_KMC_Encrypt success.
cipherLen=[216]
cipher=[AAAAAQAAAAEAAAAAAAAABQAAAAEAAAABEoKhjHVc/5+WP2Mij7mO
FLVN4HB4bBZbBW+5q4+0J/wAAAAQAAAAAAAAAACsxdxm4hxDymyfhnF7TxH4AA
AAAQAAAAAAAAgEAAAAAQAAAAEgZKuX79jh3HOKCu+WhRLUAAAAAAAAAA
BU32Iet4WHptpa3MZoLkP5D0u72/80I1yioVLk9uf8Yg==]
Step 47 Run the following command to open the PcsAgentConfig.conf configuration file using the vi
editor:
vi /opt/cloudos/pcs/controller/apps/pcs-website/WEB-
INF/classes/conf/PcsAgentConfig.conf
Change the keystorepassword value in the configuration file.
Change the keystorepassword value to the ciphertext noted down in Step 46. The changed
configuration file is as follows:
keystorepassword=AAAAAQAAAAEAAAAAAAAABQAAAAEAAAABEoKhjHVc/5+W
P2Mij7mOFLVN4HB4bBZbBW+5q4+0J/wAAAAQAAAAAAAAAACsxdxm4hxDymyfhn
F7TxH4AAAAAQAAAAAAAAgEAAAAAQAAAAEgZKuX79jh3HOKCu+WhRLUAAA
AAAAAAABU32Iet4WHptpa3MZoLkP5D0u72/80I1yioVLk9uf8Yg==
Step 49 If you need to modify truststore certificate file (.jks) filename or file path, go to Step 50.
Otherwise, go to Step 52.
editor:
Change the trustkeystore value in the configuration file.
Change the trustkeystore value to the latest truststore certificate file (.jks) path and filename.
Step 52 If you need to modify keystore certificate file (.p12) filename or file path, go to Step 53.
Otherwise, go to Step 55.
editor:
Change the clientkeystore value in the configuration file.
Change the clientkeystore value to the latest keystore certificate file (.p12) path and filename.

systemctl restart pcsd
----End
10.16 Changing the Password for the GaussDB

Administrator on the Controller Node
Scenarios
Change the password of user postgres for connecting to the Gauss database on the controller
node. This account is the internal super administrator account of the Gauss database, and is
granted the permission to create databases and users and back up data.
To ensure database security, change the default password immediately after database
installation and keep changing periodically.
The default password of user postgres is cloudos@123.
Prerequisites
Conditions
 You have obtained the management IP address of the controller node.
 You have obtained the login passwords of user gandalf and user root.
 You have obtained the current password of the Gauss database on the controller node.
The default passwords of users gandalf and root are IaaS@OS-CLOUD9! and IaaS@OS-CLOUD8!,
respectively.
Procedure
connection.
su - root
Step 3 Run the following command to disable logout on timeout:
TMOUT=0
Run the following command to change the Gauss database password:
sh /opt/galax/gms/common/modsysinfo/modifyPostgresPwd.sh
The password must meet requirements listed in the following table.
Table 10.16.1.1.1.5.1.1.1 Password requirements

Parameter Parameters Example Value
New password Value: a string of 8 to 30 Gaussdb@234

characters
The password must contain at
least three of the following
character types:
Uppercase letters
Lowercase letters
Digits
Special characters: ~!@#$
%^&*()-_=+|[{}];:,<.>/?
The new password cannot be
the same as the old password.
The password cannot be the
same as the password set in
the latest 60 days.
username or the username in
reversed order.
The password is successfully changed if the following information is displayed:

Password modified successed!
----End
10.17 Changing the Password for Accessing Common

Services in GaussDB on the Controller Node
Scenarios
On PCS, change the database passwords of the Controller nodes to improve system security.
This is a high-risk operation. Do not frequently change the database passwords. If the user
environment imposes high requirements for security, change the passwords periodically.
The default password of user pcsuser is SingleLOUD!1.

When this operation is performed, all service processes must be stopped. Therefore, do not
perform service provisioning when changing passwords of Controller database accounts.
Prerequisites
Conditions
 You have obtained the management and IP addresses of the controller node.
 You have obtained the current database password of the controller node.
The default passwords of users gandalf and root are IaaS@OS-CLOUD9! and IaaS@OS-CLOUD8!,
respectively.
Procedure
CAUTION
Do not attempt to interrupt the password change process by pressing Ctrl+C or Ctrl+Z.
Otherwise, service processes may fail to access the database, and service exceptions may
occur. If such an exception occurs, reset the password by performing the operations provided
in section 10.18"Resetting the Password for Accessing Common Services in GaussDB on the
Controller Node."
Ensure that the management plane floating IP address and username gandalf are used to
establish the connection.
su - root
Step 3 Run the following command to disable logout on timeout:
TMOUT=0
Step 4 Run the following command to change the database password of the Controller:
sh /opt/galax/gms/common/modsysinfo/modifyPcsDbPwd.sh
Step 5 Enter the old database password as prompted and press Enter.
Step 6 Enter a new database password based on requirements in the following table and press Enter.
Table 10.17.1.1.1.6.1.1.1 Password description
New password Value: a string of 8 to 30 Galax@123

characters
The password must contain
at least one of the following
special characters: ~!@#$
%^&*()-_=+|{};:<.>
at least two of the following
character types:
Uppercase letters
Lowercase letters
Digits
the same as the old
password.
the latest 60 days.
reversed order.
The database password for the Controller node is changed if the following information is
displayed:
Result:Success
----End
10.18 Resetting the Password for Accessing Common

Services in GaussDB on the Controller Node
Scenarios
On PCS, reset the database passwords of the Controller nodes to improve system security.
This is a high-risk operation. You can reset the password if you have forgotten it. During
routine maintenance, you are advised only to change the password.
The default password of user pcsuser is SingleLOUD!1.

When this operation is performed, all service processes must be stopped. Therefore, do not
perform service provisioning when changing passwords of Controller database accounts.
Prerequisites
Conditions
 You have obtained the management and floating IP addresses of the controller node.
 You have obtained the current database password of the controller node.
The default passwords of users gandalf and root are IaaS@OS-CLOUD9! and IaaS@OS-
CLOUD8!, respectively.
Procedure
CAUTION
Do not attempt to interrupt the password change process by pressing Ctrl+C or Ctrl+Z.
Otherwise, service processes may fail to access the database, and service exceptions may
occur. If such an exception occurs, reset the password by performing the following operations.
If the exception persists after several retries, contact technical support.
Ensure that the management plane floating IP address and username gandalf are used to
establish the connection.
su - root
TMOUT=0
Step 4 Run the following command to reset the database password of the Controller node:
sh /opt/galax/gms/common/modsysinfo/modifyPcsDbPwd.sh reset
Step 5 Enter the administrator password as prompted and press Enter.
The default username of the administrator is postgres, and its default password is
cloudos@123.
Step 6 Enter a new database password based on requirements in the following table and press Enter.
Table 10.18.1.1.1.6.1.1.1 Password description
New password Value: a string of 8 to 30 Galax@123

characters
at least one of the following
special characters: ~!@#$
%^&*()-_=+|{};:<.>
at least two of the following
character types:
Uppercase letters
Lowercase letters
Digits
the same as the old
password.
the latest 60 days.
reversed order.
The database password for the Controller node is reset if the following information is
displayed:
Result:success.
----End
11 Appendix 2 Troubleshooting
11.1 Failure to Access the System After a UEFI VM Is

Switched
After the UEFI VM is switched, the UEFI boot items need to be configured for some guest
OSs.
After the VM is started, if OS type is Red Hat, press Delete to enter the UEFI setup screen, if
Suse, input “exit” command, Other OS please refer to their official documents. enter the UEFI
setup screen and perform operations provided in "A VM Running the Linux OS Fails to Start
After Its Boot Firmware Is Set to UEFI" in the FusionSphere Virtualization Suite 6.5.0
Product Documentation.
11.2 Message "Failed to create a VM on the cloud

platform" Is Displayed During VM Drill and Switchover
Tasks
During the VM drill or switchover, VMs are created on the target KVM platform based on the
configuration of the source VM and the target compute and network resources specified in the
switchover plan. When a VM creation task fails to be initiated on the target KVM platform,
the corresponding VM drill or switchover task fails, and a message similar to "Failed to create
a VM on the cloud platform: The entered parameter VM CPU limit is invalid…." is displayed.
Information after the colon (:) indicates the specific failure cause returned by the target KVM
platform.
The following sections describe the common causes of the VM drill and switchover failures.
For details about all possible causes, see the description of creating a VM interface in the
VRM APIs of the target KVM platform. To obtain the documentation, log in to the
corresponding website, search for the FusionSphere virtualization suite, and locate and click
the target KVM version (for example, 6.5.0).
 For enterprise users: http://support.huawei.com/enterprise
 For carrier users: http://support.huawei.com
Failed to Create a VM on the Cloud Platform While Message "The entered
parameter VM CPU limit is invalid. Please enter a valid value" Is Displayed
If such message is displayed, handle the issue based on the Recommended Handling
Method column in the following table.
Cause Description Recommended Handling

Method
The physical CPU The CPU upper limit Delete the setting of the CPU
frequency of the configured for the source upper limit of the source VM
compute resource VM is greater than the and then perform a drill or
(cluster or host) number of CPUs of the switchover. After the switchover
selected by the target source VM multiplied by is complete, set a proper CPU
platform cannot meet the physical CPU frequency upper limit for the VM based on
the CPU upper limit of the target compute the physical CPU frequency of
configured for the resource (cluster or host). the target compute resource.
source VM.

parameter reserved CPU is invalid. Please enter a valid value" Is Displayed

Method
The physical CPU The CPU reservation Delete the setting of the CPU
frequency of the configured for the source reservation of the source VM
compute resource VM is greater than the and then perform a drill or
(cluster or host) number of CPUs of the switchover. After the
selected by the target source VM multiplied by switchover is complete, set a
platform cannot meet the physical CPU frequency proper CPU reservation value
the requirements of of the target compute for the VM based on the
the CPU reservation resource (cluster or host). physical CPU frequency of the
configured for the target compute resource.
source VM.

parameter VM memory limit is invalid. Please enter a valid value" Is Displayed

Method
Memory When memory Enable memory

overcommitment is overcommitment is overcommitment for the target
disabled for the disabled for the target compute resource and then
compute resource compute resource, the perform a drill or switchover.
(cluster or host) maximum memory size of Alternatively, change the
selected by the target the VM must be unlimited. maximum memory size of the
platform. However, VM to unlimited and then
the maximum memory perform a drill or switchover.
size is configured for
the source VM.
The maximum The maximum memory size Adjust the maximum memory
memory size configured for the VM size of the source VM and then
configured for the cannot be less than 128 perform a drill or switchover.
source VM is too MB. Otherwise, the VM
small (< 128 MB). cannot be started properly.
11.3 Initial Configuration for a Template VM on the

KVM Platform Before Confirmation Is Performed
Once being switched to the KVM, a template VM is automatically changed to the KVM
template VM after the confirmation. To ensure that the VMs provisioned from the template
can be customized, you need to initialize the VM on the KVM platform before the
confirmation.
You can search for FusionSphere virtualization suite at the following website and find the
documents of the required KVM version (for example, 6.5.0):
 Enterprise users: http://support.huawei.com/enterprise
 For carriers: http://support.huawei.com
11.3.1 Linux Template VM

The initialization configuration required for the Linux template VM involves disabling the
customized DHCP host name, deleting the network rule file, and disabling the
NetworkManager service. The operation commands vary according to the Linux series.
For details, see Linux VM attribute configuration and VM template creation requirements in
section "Creating a Template" in the product documentation (KVM).
11.3.2 Windows Template VM

Basic Configuration
The initial configuration required for the Windows template VM involves enabling the
Windows core memory dump function and retaining only the administrator user.
For details, see Windows VM attribute configuration and VM template creation requirements
in section "Creating a Template" in the product documentation (KVM).
Advanced Settings
The Windows OS has restrictions on the identification mechanism of NIC devices and NICs.
For details, see https://support.microsoft.com/en-gb/help/269155/error-message-when-you-
try-to-set-an-ip-address-on-a-network-adapter.
If the Windows template VM of the Xen type has a NIC before the switchover, VMs
provisioned by the template may have the following problems after the switchover:
 The NIC name is Local Area Connection N, rather than Local Area Connection, where
N is a number.
 When you rename the NIC Local Area Connection, a message similar to "Cannot
rename this connection. A connection with the name you specified already exists.
Specify a different name." is displayed on the Windows OS.
 If a static IP address has been configured for a NIC on the Windows template VM on the
Xen platform, an error message "The IP address XXX.XXX.XXX.XXX you have
entered for this network adapter is already assigned to another adapter Name of adapter.
Name of adapter is hidden from the network and Dial-up Connections folder because it is
not physically in the computer or is a legacy adapter that is not working. If the same
address is assigned to both adapters and they become active, only one of them will use
this address. This may result in incorrect system configuration. Do you want to enter a
different IP address for this adapter in the list of IP addresses in the advanced dialog
box? "is displayed when you set the same static IP address for the VMs provisioned from
the template after the switchover. XX.XX.XX.XX indicates the IP address, and #N may be
empty or a number.
To avoid the preceding problems, perform the following steps:
Step 1 Go to the Windows CLI.
Step 2 Run the set devmgr_show_nonpresent_devices=1 command and press Enter.
Step 3 Run the Start DEVMGMT.MSC command and press Enter.
The Device Manager window is displayed.
Step 4 In the Device Manager window, click View and then select Show hidden devices.
Step 5 Click Network adapters, and check whether network adapters Realtek RTL8139C+ Fast
Ethernet NIC and Xen Net Device Driver #N in the red boxes are displayed in the following
figure.
#N may be empty or a number, that is, multiple network adapters of Xen Net Device Driver
may exist.
Step 6 Right-click Realtek RTL8139C+ Fast Ethernet NIC and all network adapters of Xen Net
Device Driver, and then click Uninstall. In the displayed Confirm Device Uninstall dialog
box, click OK.
After the uninstallation is complete, the two types of devices are not displayed under
Network adapters in the Device Manager window.
Then, you can change the VM NIC name and network configuration as required. For example,
you can change Local Area Connection 3 to Local Area Connection and set the static IP
address that has been configured in the template for the network adapter.
----End
11.4 Agent status display for Abnormal
If the agent is registered before IP address of the controller node is modified, perform the
following operation on the agent node:
Step 1 Use PuTTY to log in to the active agent node as user gandalf, run the su - root command to
timeout.
Step 2 Run the sed -i 's/^controller-ip=.*/controller-ip=controller Floating IP address/g'
/opt/cloudos/pcs/agent/conf/controller.conf command to change the controller-ip to
controller Floating IP address.
Step 3 Run the service pcs-agent restart command on the agent node to restart the pcs-agent
process.
Step 4 Wait for 3 minutes and check whether the agent node is normal.
 If yes, no further action is required.

 If no, contact Huawei technical support.
11.5 Failed to Execute the Disk Configuration Injection

Task During the Drill and Switchover
During the batch drill or switchover, unexpected exceptions may occur on an agent VM when
disks are frequently attached to or detached from the VM. Consequently, the task fails to be
executed. This section describes how to handle a specific failure.
Procedure
Step 1 On PCS, choose VM Switchover > Switchover Task and check whether causes for the
injection task failure are as follows:
 The Linux disk fails to be attached to the agent.
 Failed to detach the disk from the agent, try to perform the operation again.
 The injection tool fails to find the system root partition.
 The injection tool fails to decompress the kernel file. The possible cause is that there is
not enough space in the partition where the kernel file is located.
Step 2 Execute the task again.
 If the fault persists, go to Step 3.
 If the task execution succeeds, no further action is required.
Step 3 On the Cloud Platform Management page of PCS, choose the target platform, view agent
information, and check whether the agent VM is in the normal status.
 If no, go to Step 4.
 If yes, contact technical support.
Step 4 Log in to FusionCompute where the agent VM resides, locate the agent VM, and restart the
VM, as shown in the following figure.
 If the restart fails, go to Step 5.
 If the restart succeeds, go to Step 6.
Step 5 Log in to FusionCompute where the agent VM resides, locate the agent VM, and forcibly
restart the VM, as shown in the following figure.
Step 6 On the Cloud Platform Management page of PCS, choose the target platform, view agent
information, and check whether the agent VM is in the normal status.
 If no, contact technical support.
Step 7 Execute the task again.
 If the task execution succeeds, no further action is required.
 If the fault persists, contact technical support.
----End
11.6 Faulty OS During the Deployment of Controller

VM
Scenarios
When controller VMs are faulty, perform the operations provided in this section to rectify the
fault and quickly restore services.

Services cannot be provided.
Prerequisites
You have obtained the administrator account and password of the FusionCompute system.
You have obtained the IP address and name of the faulty controller node.
You have obtained the password of the admin user for logging in to the faulty PCS system.
Procedure
Step 1 Stop the faulty controller VMs by following the instructions provided in "Stopping a VM" in
FusionSphere Virtualization Suite 6.5.0 Product Documentation.
Step 2 Deploy a controller VM by following the instructions provided in "Creating a VM from a
Template" in FusionSphere Virtualization Suite 6.5.0 Product Documentation.
Before the installation, record the original IP address and node name of the faulty controller VM. During
the reinstallation, the information must be the same as the original IP address and node name.
Step 3 Restore the data of the third-party backup server on the controller node. For details, see
"10.10Restoring Data".
Step 4 After the restoration, log in to the PCS to check whether the services are normal and whether
the data is correct.
 If no, contact technical support.
Step 5 Delete the faulty controller VM. For details, see section "Deleting a VM" in FusionSphere
Virtualization Suite 6.5.0 Product Documentation.
12 Appendix 3 Obstacle Item Description
This section describes all the obstacle items supported by PCS, impacts on the drill and
switchover, supported handling actions, and drill and operation suggestions.
12.1 VM Has vCPU Binding Enabled

Obstacle Item Description
Bind a VM and physical CPU cores on a host to limit the range where the CPU cores on the
host can be used. For VMs that have vCPU binding enabled, they are not automatically bound
to physical CPU cores of the host after the switchover.
Impacts on Drill and Handling Actions

 Default impact: Minor
 Default handling action: Ignore
 Optional handling action: Ignore or Adjust VM Later
Impacts on Switchover and Optional Actions

Drill Suggestions
The drill aims to check whether the guest OS and services of the drill VM can be started
properly.
You are advised not to manually bind the drill VM to the physical CPU cores of the host. If
the drill VM must be bound to a core, you can set the binding on the KVM platform.
Switchover Suggestions
After a VM is switched to the KVM platform, if the VM must be bound to a core, you can set
the binding on the KVM platform.
12.2 VM Is Bound to Host
You can bind a VM to a host to run the VM on a specific host or use a specific peripheral on
the host. After a VM that is bound to a host on the Xen platform is switched over to the target
KVM platform, the VM is not automatically bound to the host.


Drill Suggestions
Switchover aims to check whether the guest OS and services of the drill VM can be properly
started.
You are advised not to manually bind the drill VM to the host. If the VM still needs to be
bound to a specific host, you can migrate the VM to the host through the KVM platform and
set the binding.
After a VM is switched to the KVM platform, if the VM still needs to be bound to a specific
host, you can migrate the VM to the host through the KVM platform and set the binding.
12.3 Reserving Resources upon VM Stop Is Enabled for a

VM
After a VM is bound to a host, you can select Permanently reserve resources for the VM to
ensure that the VM still occupies compute resources of the host after the VM is stopped or
hibernated and that the VM can be started or woken up successfully. FusionSphere
Virtualization Suite 6.5.0 (KVM) does not support resource reservation for VMs. Therefore,
for VMs for which Permanently reserve resources for the VM is enabled on the Xen
platform, the function cannot be enabled for them on the target KVM platform after the
switchover.


Drill Suggestions
The drill aims to check whether the guest OS and services of the VM can be properly started.
You are advised not to manually bind the drill VM to the host.
If the VM still needs to be bound to a specific host, you can migrate the VM to the host using
the KVM platform and bind the VM to the host. However, you cannot select Permanently
reserve resources for the VM for the VM.
After a VM is switched to the KVM platform, if the VM still needs to be bound to a specific
host, you can migrate the VM to the host using the KVM platform and bind the VM to the
host. However, you cannot select Permanently reserve resources for the VM for the VM.
12.4 VM Is a Template VM
A VM template can be used to implement quick VM deployment. PCS does not support VM
template drill because the VM template is in the shutdown state. You can switch over the VM
template directly. If the VM template is faulty after the switchover, you can perform rollback
on PCS.

 Default impact: Major
 Default handling action: Adjust VM Later
 Optional handling action: Adjust VM Later

 Default impact: None
 Default handling action: N/A
 Optional handling action: N/A
Drill Suggestions
You can switch over the VM template directly. If the VM template is faulty after the
switchover, you can perform rollback on PCS.
During the template VM switchover, the VM is a common VM on the KVM platform.
If the VM is normal, select Finish Confirmation to complete the switchover. PCS
automatically converts the VM to a template.
If the VM is abnormal, perform rollback on PCS to roll back the switchover process. PCS will
restore the Xen template VM to the state before the switchover.
12.5 VM Uses an Independent Persistent Disk

Independent & persistent can be selected for a VM disk to avoid the impact of the snapshot
on the disk. That is, the disk does not support the volume snapshot function, and snapshots
cannot be created for the independent persistent disk.
During the VM drill and switchover, a VM or volume snapshot needs to be created, and the
Independent & persistent mode of disks is temporarily changed to the Dependent mode.
After the VM drill and switchover, restore the disk mode to the original mode.
Pay attention to the following special cases:
 All shared disks are in Independent & persistent mode. VMs that use shared disks do
not support the drill. For details, see 12.65"VM Uses a Shared Disk."
During the switchover, the shared disk mode is not changed, no snapshot is created for
the shared disk.
 When a snapshot is created for a VM that uses an independent persistent disk, the
FusionSphere virtualization suite does not support the change of the VM disk mode to
the Dependent mode. Therefore, the drill is not supported. For details, see 12.67"Source
VM Uses an Independent Persistent Disk and Has a VM Snapshot."


Drill Suggestions
properly.
During the drill, PCS restricts the operation rights of the source VM, new snapshots cannot be
created for the source VM, and therefore, you are advised to ignore the obstacle item. During
the drill, PCS changes the Independent & persistent mode of the disk to the Dependent
mode temporarily.
During the switchover, PCS restricts the operation rights of the source VM, new snapshots
cannot be created for the source VM, and therefore, you are advised to ignore the obstacle
item. During the switchover, PCS changes the Independent & persistent mode of the disk to
the Dependent mode temporarily and restores the disk mode to the original mode after
confirmation.
12.6 VM Uses a Non-Persistent Disk

The VM disk can be in the Independent & nonpersistent mode to avoid the impact of the
snapshot on the disk. In addition, after the VM is shut down or the snapshot is restored,
restore the disk mode. PCS does not support the drill and switchover of disks in the
Independent & nonpersistent mode.


Drill Suggestions
You are advised to perform the switchover by referring to the following "Switchover
Suggestions". If the VM is abnormal after the switchover, use the PCS rollback function.
The switchover is not supported.
First stop the VM, and change Independent & nonpersistent mode of the disk to Dependent
mode. Then perform the switchover. Once the switchover complete, change the disk mode
back on the target platform manually.
12.7 VMs that Use Shared Disks Are Not All Stopped
If a VM uses a shared disk, the VM cannot be subject to a drill, but can be subject to a
switchover. However, all VMs to which the shared disk is mounted must be shut down. In
addition, during the switchover, no snapshot is created for the shared disk, and data is directly
written to the shared disk. Therefore, after the rollback function of PCS is used to roll back
the VM using the shared disk, the data will be saved on the shared disk and cannot be rolled
back.
If the shared disk is on the RDM data store, that is, the shared disk is an RDM disk, the VM to
which the RDM shared disk is attached does not need to be shut down during the switchover.
However, data is written to the RDM disk during the switchover and cannot be rolled back.
If cluster services, such as Oracle RAC and MSCS, are running on a VM that uses a shared
disk, you are advised to use the capacity expansion capability at the service layer to perform
the switchover, thus avoiding the potential impact of disk controller changes on services after
the VM switchover.


Drill Suggestions
The drill is not supported.
If cluster services, such as Oracle RAC and MSCS, are running on a VM that uses a shared
disk, you are advised to use the capacity expansion capability at the service layer to perform
the switchover, thus avoiding the potential impact of disk controller changes on services after
the VM switchover.
If PCS is used for the switchover and the shared disk is an RDM disk, you can directly
perform the switchover. Otherwise, you need to shut down all the VMs to which the shared
disk is mounted and perform the switchover at the same time in a window.
12.8 VM is a Linked Clone VM

PCS does not support the drill and switchover of linked clone VMs.


Drill Suggestions
Linked clone VMs cannot be directly switched.
Switch over a template that is used for provisioning linked clone VMs to the KVM platform
using PCS and then use the template to provision linked clone VMs after the template is
converted into the VHD format.
12.9 ISO File Is Mounted to the VM

The ISO or physical DVD-ROM drive can be mounted to a VM in shared mode or local
mode. After the drill and switchover is performed on the VM, the CD-ROM drive is not
automatically mounted to the target VM.


Drill Suggestions
properly.
You are advised to ignore the obstacle item. If the source DVD-ROM drive is required for the
drill, mount the DVD-ROM drive to the drill VM on the target KVM platform.
You are advised to ignore the obstacle item. If the source CD-ROM drive is required for the
switchover, mount the CD-ROM drive to the drill VM on the target KVM platform.
12.10 Tools ISO File Is Mounted to the VM

You can install Tools on a VM by mounting Tools. During this process, an ISO file containing
Tools is mounted to the VM. After a drill and switchover, the Tools ISO file cannot be
automatically mounted to the target VM.

Drill Suggestions
properly. You are advised to ignore the obstacle item.
It is recommended that this item be ignored.
12.11 USB Device Is Mounted to a VM

A VM can be bound to a USB device on the host to access the USB device, thus meeting
service requirements. The target VM cannot be automatically bound to the USB device after
the drill and switchover because the USB device is on the source host.


Drill Suggestions
properly.
You are advised to ignore the obstacle item. If the drill depends on the USB device but does
not strongly depend on the source USB device, you can bind the USB device of the target
KVM host to the drill VM.
If the drill VM is not on the target KVM host with USB devices, you can migrate the VM to
the target host.
It is recommended that this obstacle item be ignored. If a USB device is required for the
switchover, install the source USB device on the target KVM host where the VM to be
switched is located, or bind the USB device on the target KVM host to the VM to be
switched.
If the drill VM is not on the target KVM host with USB devices, you can migrate the VM to
the target host.
12.12 VM Is a DR VM
PCS does not support drill or switchover VMs whose DR feature was enabled.


Drill Suggestions
12.13 VM Is an Antivirus Guest VM (GVM)

Since FusionSphere virtualization suite V100R006C10 (Xen) and 6.5.0 (KVM) support
different antivirus mechanisms and vendors (for details, see the FusionSphere virtualization
suite compatibility list.), you need to uninstall GVM driver then switch over GVM to the
target KVM platform. After the switchover, adjust the configuration to implement the
interconnection to the secure VM based on the product documentation 6.5.0 (KVM).
The GVM driver needs to be uninstalled first. Therefore, PCS does not support the online drill
of the GVM.


Drill Suggestions
Uninstall the GVM driver from the VM and perform the switchover. After the switchover is
complete, reconfigure the antivirus service by referring to FusionSphere product
documentation 6.5.0 (KVM).
12.14 VM Is a Secure VM (SVM)

Since FusionSphere virtualization suite V100R006C10 (Xen) and 6.5.0 (KVM) support
different antivirus mechanisms and vendors (for details, see the FusionSphere virtualization
suite compatibility list.), SVM cannot be switched over to the target KVM platform.


Drill Suggestions
12.15 GPU Device Is Mounted to a VM

With the evolution of GPU device and GPU virtualization technologies, FusionSphere
virtualization suite V100R006C10 (Xen) and 6.5.0 (KVM) support different GPU models and
virtualization technologies. Therefore, after Xen VMs using GPU devices are switched over to
the target KVM platform, GPU devices are not automatically configured. For details about
how to configure GPU devices, see the product documentation 6.5.0 (KVM). You need to
select a suitable vGPU or passthrough GPU device for the VM.
In addition, VMs with GPU devices do not support the drill.


Drill Suggestions
After the switchover is complete, adjust the configuration by referring to the product
documentation 6.5.0 (KVM) and select a suitable vGPU or passthrough GPU device for the
VM.
12.16 HANA Configuration Is Enabled on the VM

FusionSphere virtualization suite V100R006C10 (Xen) supports the HANA optimization
function to improve VM performance in the HANA service cluster. Currently, FusionSphere
virtualization suite 6.5.0 (KVM) is not certified by HANA. Therefore, after Xen VMs with
HANA optimization function enabled are switched over to the KVM platform, the HANA
service running requirements may not be met.


Drill Suggestions
Check whether VMs that are switched over to the KVM platform meet the requirements based
on the actual performance requirements of VM services. If the service requirements are met,
ignore the obstacle item and perform the drill.
Check whether VMs that are switched over to the KVM platform meet the requirements based
on the actual performance requirements of VM services. If the service requirements are met,
ignore the obstacle item and perform the switchover.
12.17 VM Uses Local Disk (Non-Virtualization) Storage

VMs that use local disks (non-virtualization) storage cannot be subject to the drill and
switchover.


Drill Suggestions
On the source platform, change the storage mode used by the source VM to that supported by
PCS, namely, virtualized SAN storage, through storage migration. Then, you can perform the
drill.
switchover.
12.18 VM Uses SAN Storage (Non-Virtualization)

VMs that use SAN storage (non-virtualization) cannot be subject to the drill and switchover.


Drill Suggestions
drill.
switchover.
12.19 VM Uses the Advanced SAN Storage

VMs that use the Advanced SAN storage cannot be subject to the drill and switchover.


Drill Suggestions
12.20 VM Uses FusionStorage

VMs that use FusionStorage cannot be subject to the drill and switchover.


Drill Suggestions
drill.
switchover.
12.21 VM Uses Local RAM Disks

VMs that use local RAM disks cannot be subject to the drill and switchover.


Drill Suggestions
Switch over the template used for provisioning the VM using the local RAM disk to the target
KVM platform and then provision VMs again on the KVM platform.
Switch over the template used for provisioning the VM using the local RAM disk to the target
KVM platform and then provision VMs again on the KVM platform.
12.22 VM Uses Virtualized Local Hard Disks
VMs that use virtualized local hard disks cannot be subject to the drill and switchover.


Drill Suggestions
drill.
switchover.
12.23 HA Function Is Enabled for the VM, but Not

Enabled for the Target Cluster
After the VM with HA enabled is switched to the target KVM platform, whether the HA
function is enabled depends on the configuration of the target cluster. Therefore, if the HA
function is disabled for the target cluster, the HA function for the VM is disabled by default


Drill Suggestions
Before the switchover, plan a cluster with the HA function enabled. Then, you can switch over
the VMs with the HA function to be enabled to the cluster.
If the HA function cannot be enabled for the target cluster but must be enabled for the VM,
you can enable the HA function for the VM by setting the HA substitute item on the KVM
platform after the VM is switched to the KVM.
12.24 A Fault Handling Policy Is Set for the VM, but Not
Set for the Target Cluster, or Different Policies Are Set for
the VM and Cluster
After the source VM configured with the fault handling policy is switched to the target KVM
platform, the fault handling policy depends on the configuration of the target cluster.
Therefore, after the Xen VM configured with the fault handling policy is switched to the
cluster with different VM fault handling policies, the VM fault handling policy changes.


Drill Suggestions
Plan a target KVM cluster that has the same fault handling policy as the source VM before the
switchover. Then, you can perform VM switchover.
If the target cluster cannot be configured with the same fault handling policy as the source
VM but the VM must use the original fault handling policy, you can configure the original
fault handling policy by setting the substitute item of the VM fault handling policy on the
KVM platform.
12.25 VM Has a VM Snapshot or Volume Snapshot
After a source VM with a VM snapshot or volume snapshot is switched to the KVM platform,
these snapshot points are invisible on the KVM platform, and VMs cannot be restored to these
points.


Drill Suggestions
VM snapshots or volume snapshots affect VM I/O performance. Therefore, you are advised to
retain only important VM snapshots and volume snapshots before the switchover. If a fault
occurs during the switchover, rollback can be performed and these snapshots can be used for
restoration.
After the switchover, you are advised to use the format conversion function of the VM on the
KVM platform to combine the snapshot points created on the Xen platform before the
switchover to avoid the impact of these snapshot points on the VM I/O performance.
12.26 Tools (PV Driver) Is Not Running

During the online drill, online snapshots are taken for the VM. To achieve this, Tools must be
installed and be running properly on the VM. During VM switchover, shut down the source
VM in graceful mode to ensure that data on the source VM is stored on the disk. Also, Tools
must be installed and be running properly on the VM.
Therefore, when the VM is in the running state and Tools (PV driver) is not running, the drill
and switchover cannot be performed.


Drill Suggestions
Install Tools on the VM and ensure that Tools is running properly.
Install Tools on the VM and ensure that the VM is running properly. Alternatively, log in to
the VM, shut down the VM in graceful mode, and then perform the VM switchover.
12.27 Source VM Is Not in the Running or Stopped State

VMs in only running or stopped state can be subject to the drill and switchover.


Drill Suggestions
If a VM is in the transient state (for example, switching or creating), perform the drill after the
VM is in the running or stopped state. If a VM is in the hibernated state, you can wake up or
shut down the VM, change the VM to the running or stopped state, and then perform the drill.
If a VM is in the transient state (for example, switching or creating), perform the switchover
after the VM is in the running or stopped state. If a VM is in the hibernated state, you can
wake up or shut down the VM, change the VM to the running or stopped state, and then
perform the switchover.
12.28 VM Does Not Support Snapshot Creation Because
the Number of CPUs Exceeds 64
If the number of CPUs of a VM exceeds 64, snapshots cannot be created for the VM.
Therefore, PCS does not support the online drill for such VMs.


Drill Suggestions
This obstacle item has no impacts on the switchover. PCS can be used to perform switchover.
12.29 VM or Template Uses an MAC Address Used by

the Target Platform
During the VM or template drill and switchover, PCS creates a VM or template with the same
configuration as the source VM or template on the target KVM platform. If the MAC address
exists on the target KVM platform, the drill and switchover cannot be performed.


Drill Suggestions
The drill cannot be performed directly.
When planning the target KVM resource pool, change its MAC address range to the one not
used by the Xen VM or template resource pool. If a VM or template with the same MAC
address as the Xen resource pool exists in the KVM resource pool, you are advised to change
the MAC address of the VM or template in the Xen resource pool or KVM resource pool
based on the site requirements. Ensure that no MAC address conflict occurs and then perform
the drill.
When planning the target KVM resource pool, you are advised to adjust its MAC address
range to the one not used by the Xen VM or template resource pool. If a VM or template with
the same MAC address as the Xen resource pool exists in the KVM resource pool, you are
advised to change the MAC address of the VM or template in the Xen resource pool or KVM
resource pool based on the site requirements. Ensure that no MAC address conflict occurs and
then perform the switchover.
12.30 NIC Configuration of the Source VM Changes

After the VM Is Added to a Switchover Plan
During the VM switchover, you need to specify the target network (port group) and target drill
network (port group) used by each VM NIC on the target KVM platform for. After the source
VM is added to a switchover plan but before the drill or switchover is performed, if the NIC
configuration changes (for example, a NIC is added), you must select the target network and
target drill network again for the VM. Otherwise, the drill and switchover cannot be
performed.


Drill Suggestions
The drill cannot be performed directly.
Modify the information of the switchover plan to which the source VM belongs, select the
target network and target drill network for each NIC of the source VM, and perform the drill
again.
Modify the information of the switchover plan to which the source VM belongs, select the
target network and target drill network for each NIC of the source VM, and perform the
switchover again.
12.31 Source and Target Port Groups Are Different in

Types
During the VM switchover, you need to specify the target network (port group) used by each
VM NIC on the target platform. When the source port group and the target port group are
different in types (command or trunk), the network communication may fail after the
switchover.


Drill Suggestions
This obstacle item has no impacts on the drill. You can use PCS to perform the drill.
You are advised to ignore the obstacle item and perform the switchover directly if the source
and target port group types are different in the plan. Otherwise, set the default action of this
obstacle item to Adjust VM Later so that you can identify the error target network in
advance before the switchover.
12.32 Source and Target Port Groups Are of Common

Type, but Their VLAN IDs Are Different
VM NIC on the target KVM platform. If the source and target port groups are of the common
type but their VLAN IDs are different, the network may be disconnected after the switchover.


Drill Suggestions
The drill is not affected. You can use PCS to perform the drill.
You are advised to ignore the obstacle item and perform the switchover directly if the VLAN
IDs for source and target port groups are different in the plan. Otherwise, set the action of this
obstacle item to Adjust VM Later so that you can identify the error target network in
advance before the switchover.
In addition, even if the VLAN IDs of the source and target port groups are the same, the
configuration of the physical network may cause network disconnection. Therefore, you need
to ensure that the physical network is correctly configured.
12.33 Source and Target Port Groups Are of Trunk Type,

but Their VLAN Ranges Are Different
VM NIC on the target KVM platform. If the source and target port groups are of the trunk
type but their VLAN ranges are different, the network may be disconnected after the
switchover.


Drill Suggestions
The drill is not affected. You can use PCS to perform the drill.
You are advised to ignore the obstacle item and perform the switchover directly if the VLAN
ranges for source and target port groups are different in the plan. Otherwise, set the default
action of this obstacle item to Adjust VM Later so that you can identify the error target
network in advance before the switchover.
In addition, even if the VLAN ranges of the source and target port groups are the same, the
configuration of the physical network may cause network disconnection. Therefore, you need
to ensure that the physical network is correctly configured.
12.34 TCP Checksums for Source and Target Port

Groups Are Different
During the switchover, you need to specify the target network (port group) used by each VM
NIC on the target KVM platform. If the TCP checksums of the source and target port groups
are different and internal services of a VM depend on the TCP checksum, network
communication may be abnormal after the switchover.


Drill Suggestions
If the internal services of the VM do not depend on the TCP checksum, you are advised to
ignore the obstacle item and perform the switchover directly. Otherwise, set the default action
of this item to Adjust VM Later to identify that difference.
12.35 Source and Target Port Groups Are Different in IP

Address and MAC Address Binding Configuration
NIC on the target KVM platform. When the source and target port groups are different in IP
address and MAC address binding, the network communication may abnormal and a security
risk may occur after the switchover.


Drill Suggestions
If the VM does not depend on the binding between IP addresses and MAC addresses, you are
advised to ignore the obstacle item and perform the switchover directly. Otherwise, set the
default action of this item to Adjust VM Later to identify the binding configuration
difference in advance.

DHCP Isolation Configuration
NIC on the target KVM platform. When the source and target port groups are different in
DHCP isolation configuration, a security risk may occur after the switchover.


Drill Suggestions
If the VM does not depend on the DHCP isolation configuration, you are advised to ignore the
obstacle item and perform the switchover directly. Otherwise, set the default action of this
item to Adjust VM Later to identify the configuration difference in advance.

IP/ARP Broadcast Suppression Configuration
NIC on the target KVM platform. When the source port group and target port group are
different in IP/ARP broadcast suppression configuration, a security risk may occur after the
switchover.


Drill Suggestions
If the VM does not depend on the IP/ARP broadcast suppression configuration, ignore the
obstacle item and perform the switchover directly. Otherwise, set the default action of this
item to Adjust VM Later to identify the configuration difference in advance.
12.38 Source and Target Port Group Are Different in

QoS (Outbound and Inbound Traffic Shaping)
Configuration
NIC on the target KVM platform. When the group and target port groups are different in QoS
(outbound and inbound traffic shaping) configuration, the network QoS configuration may
change after the switchover.


Drill Suggestions
If the VM does not depend on the QoS (outbound and inbound traffic shaping) configuration,
you are advised to ignore the obstacle item and perform the switchover directly. Otherwise,
set the default action of this item to Adjust VM Later to identify the QoS configuration
difference in advance.
12.39 IP-MAC Binding Is Enabled for the Source Port

Group
The port group to which the source VM belongs supports the binding between IP addresses
and MAC addresses. The binding is valid for only the customized VM in FusionSphere 6.5.0
(KVM). Therefore, the binding becomes invalid after the switchover.


Drill Suggestions
If the VM does not strongly depend on the binding between IP addresses and MAC addresses,
you are advised to ignore the obstacle item and perform the switchover directly. Otherwise,
set the default action of this item to Adjust VM Later to identify the binding configuration in
advance.
12.40 Source Port Group Is of the Subnet Type
The source VM supports a subnet port group, and VRM manages and allocates NIC IP
addresses of VMs that use the subnet port group. As FusionSphere virtualization suite 6.5.0
(KVM) does not support this type of port group, IP addresses may fail to be assigned after the
switchover.


Drill Suggestions
Based on the physical network plan of the target KVM platform, configure the DHCP relay on
the switch connected to the KVM platform and ensure that VRM of the source Xen platform
can be used as the DHCP server to allocate IP addresses after the switchover.
You can ignore the obstacle item and switch the VMs that use the subnet port group to the VM
groups that use common port group on the target KVM platform.
When all VMs that use subnet port groups on the source Xen platform are switched to the
target KVM platform, to bring the VRM node on the source platform offline, you need to
create an external DHCP server and configure it based on the DHCP configuration file
(/etc/galax/dhcp_conf/nrm-dhcp.conf on the VRM node) and lease file
(/etc/galax/dhcp/nrm-dhcp.leases on the VRM node).
For details, see 10.11"Switching VMs that Use the Port Group of the Subnet Type."
12.41 Source Port Group Uses VXLAN

FusionSphere virtualization suite V100R006C10 (Xen) supports the configuration of VTEP
networks for uplinks of DVSs so that VMs can use VXLAN networks when FusionManager
is used. FusionSphere virtualization suite 6.5.0 (KVM) does not support this configuration.
Therefore, VXLAN cannot be used after VMs are switched over to the target KVM platform.
Therefore, PCS does not support the drill and switchover of such VMs.

Drill Suggestions
12.42 Number of Disks on the Source VM Exceeds 25,

There Are IDE Disks Whose Slot IDs Are Greater Than 25,
or the Source VM Uses RDM Disks, and the Guest OS
Does Not Support virtio-scsi Disks
In FusionSphere virtualization suite V100R006C10 (Xen), a single VM supports a maximum
of 60 IDE disks. In FusionSphere 6.5.0 (KVM), a single VM supports a maximum of 25
virtio-blk disks, or a maximum of 60 virtio-scsi disks. In addition, the RDM disk can be used
only together with the virtio-scsi controller.
Therefore, if the number of disks on the source Xen VM exceeds 25, there are IDE disks
whose slot IDs are greater than 25, or RDM disks are used, the virtio-scsi disk must be used
after the switchover. In this scenario, if the guest OS does not support virtio-scsi disks, the
VM cannot be subject to the drill and switchover.


Drill Suggestions
If the VM does not use the RDM disk, change the number of IDE disks in the source VM to
less than 25 and ensure that there is no IDE disk whose slot ID exceeds 25. Then, you can
perform the switchover. If RDM disks must be used, the switchover is not supported.
12.43 Target Cloud Platform Does Not Support Guest

OS of Source VM
As the life cycle of the guest OS changes, the guest OSs supported by FusionSphere
virtualization suite 6.5.0 (KVM) and V100R006C10 (Xen) are different. VMs using guest
OSs that are not supported by the KVM platform cannot be subject to the drill and switchover.


Drill Suggestions
12.44 Data Store Used by the Source VM Is Not Added

to the Target Cloud Platform
When PCS switches over VMs from FusionSphere virtualization suite V100R006C10 (Xen)
to FusionSphere virtualization suite 6.5.0 (KVM), the data store where the source VM resides
must be mounted to the target KVM platform. If the data store used by the source VM is not
added to the target KVM platform, the VM cannot be subject to the drill and switchover.


Drill Suggestions
The drill is not supported. The data store used by the source VM must be mounted to the
target KVM platform before the drill.
The switchover is not supported. The data store used by the source VM must be mounted to
the target KVM platform before the switchover.
12.45 CPU Quota Set for the Source VM Exceeds that

Supported by the Target Cloud Platform
The maximum CPU quota that can be configured for the source VM exceeds that supported
by FusionSphere virtualization suite 6.5.0 (KVM). If that happens, the drill and switchover
cannot be performed.


Drill Suggestions
The drill is not supported. To perform the drill, change the CPU quota of the source VM to a
value supported by the target KVM platform.
The switchover is not supported. To perform the switchover, change the CPU quota of the
source VM to a value supported by the target KVM platform.
12.46 Maximum Number of Read or Write Bytes
Configured for the Source VM Disks Exceeds the Value
Range Supported by the Target Cloud Platform
The maximum number of read or write bytes configured for the source VM disk exceeds that
supported by FusionSphere virtualization suite 6.5.0 (KVM). If that happens, the drill and
switchover cannot be performed.


Drill Suggestions
The drill is not supported. To perform the drill, change the number of read or write bytes of
the source VM disk to a value supported by the target KVM platform.
The switchover is not supported. To perform the switchover, change the number of read or
write bytes of the source VM disk to a value supported by the target KVM platform.
12.47 Configurations of Whether Memory

Overcommitment Is Enabled Are Different for the Source
and Target Clusters
If the configurations about whether the memory overcommitment is enabled are different for
the source cluster and the target cluster selected in the switchover plan, the memory
overcommitment rate of the host where the VM is located may be different after the
switchover.

Drill Suggestions
You are advised to ignore the obstacle item.
On the target KVM platform, set a cluster with the same configuration about whether the
memory overcommitment is enabled as that of the Xen platform. For VMs whose the
configuration about whether memory overcommitment is enabled must be retained, switch
over them to the cluster that you set. For other VMs, switch over them to other clusters.
12.48 Configurations of Whether HA Is Enabled Are

Different for the Source and Target Clusters
If the configurations about whether HA is enabled are different for the source cluster and the
target cluster selected in the switchover plan, the HA function attribute may change.


Drill Suggestions
On the target KVM platform, set a cluster with the same configuration about whether HA is
enabled as that of the Xen platform. For VMs whose the configuration about whether HA is
enabled must be retained, switch over them to the cluster that you set. For other VMs, switch
over them to other clusters.
12.49 Configurations of Whether IMC Is Enabled Are
Different for the Source and Target Clusters
If the configurations about whether IMC is enabled are different for the source cluster and the
target cluster selected in the switchover plan, the CPU model may change after the
switchover.


Drill Suggestions
If the VM internal services strongly depend on the specific CPU model, on the target KVM
platform, create a cluster with the same configuration about whether IMC is enabled as that of
the Xen platform and select the target cluster with the same configuration about whether IMC
is enabled for the VM.
Retain the default impact of the item so that you can identify the impact before the switchover
to avoid selecting an incorrect target cluster.
If VM internal services do not have strong dependency on specific CPU models, you are
advised to ignore the obstacle item and perform a switchover directly.
12.50 IMC Configurations Are Different for the Source

and Target Clusters
If the IMC configurations are different for the source VM cluster and the target cluster
selected in the switchover plan, the CPU model may change after the switchover.


Drill Suggestions
If the VM internal services strongly depend on the specific CPU model, create a cluster with
the same IMC configuration as the Xen platform on the target KVM platform and select the
target cluster with the same IMC configuration for the VM.
Retain the default impact of the item so that you can identify the impact before the switchover
to avoid selecting an incorrect target cluster.
If VM internal services do not have strong dependency on specific CPU models, you are
advised to ignore the obstacle item and perform a switchover directly.
12.51 Type of the DVS Connected to the Source VM Is

Different from that of the DVS Connected to the Target
VM
PCS does not support the change of the type of the DVS connected to the VM during the VM
switchover.


Drill Suggestions
The drill is not supported. You need to use the target DVS of the same type as the source
DVS.
The switchover is not supported. You need to use the target DVS of the same type as the
source DVS.
12.52 Source and Target VMs May Have Different Guest

NUMA Topologies
As the Xen and KVM engines have different guest NUMA implementation mechanisms, the
number of NUMA nodes may change after the switchover.


Drill Suggestions
You are advised to check whether services that strongly depend on the internal NUMA
topology exist in the guest NUMA VM. If the service cannot be modified, you are not advised
to perform VM switchover. Otherwise, you are advised to ignore the obstacle item and
perform VM switchover.
12.53 Affinity or Anti-affinity Rule Is Configured for the

Source VM
If the source VM is configured with affinity or anti-affinity rules such as resource groups and
rule groups, these rules will not be retained after the switchover. You need to reconfigure
these rules on the target platform.

Drill Suggestions
After the VM is switched to the KVM platform, reconfigure affinity and anti-affinity rules
based on the actual situation of hosts in the target KVM cluster.
12.54 Object Operation Permissions Are Configured for

the Source VM
If object operation permissions are configured for the source VM, these permissions are not
retained after the switchover. You need to reconfigure the permissions on the target platform.


Drill Suggestions
During the drill, you need to perform operations, such as creating and deleting a VM
snapshot, on the source VM. Before the drill, ensure that the operation permissions are not
disabled.
During the switchover, you need to perform operations, such as powering off and powering
on, on the source VM. Before the switchover, ensure that the operation permissions are not
disabled.
You are advised to ignore the obstacle item. Before the switchover, record the operation
permissions that need to be disabled on the VM. After the VM is switched to the KVM
platform, reconfigure the object permissions of the VM.
12.55 Source VM Uses a Passthrough DVS

If the source VM uses the port group of the VMDQ-enabled DVS, the switchover of the VM
is not supported.


Drill Suggestions
12.56 Source VM Uses the Port Group of a DVS in

Network Enhancement Mode
If the source VM uses the port group of the DVS in the network enhancement mode, the
switchover of the VM is not supported.


Drill Suggestions
12.57 QoS (Upper Limit of IOPS) Is Configured for

Disks of the Source VM, Which May Affect the Driver
Injection Speed During the Switchover
If the QoS (upper limit of IOPS) is configured for disks of the source VM, the driver injection
speed is affected during the switchover and drill. As a result, the VM switchover and drill
slow down.


Drill Suggestions
Before the drill, cancel the IOPS upper limit of the disk.
Before the switchover, cancel the IOPS upper limit of the disk.
12.58 Source VM or Disk Has 32 Snapshots, and No

Snapshot Can Be Created
During the online VM drill, snapshots are created online for the VM. If 32 snapshots have
been created for the VM or VM disk, new snapshots cannot be created. Therefore, PCS does
not support the online drill for such VMs.

Drill Suggestions
Delete the unimportant snapshots of the source VM and perform the drill.
Delete the unimportant snapshots of the source VM and then perform the switchover.
You can also perform the switchover directly.
12.59 RDM Disk Slot IDs of the Source VM Change

After the Switchover
If the source VM uses the RDM disk and the following conditions are met, after VMs are
switched over to KVM, slot IDs of RDM disks will be re-allocated and the disk drive letters
of the VM change accordingly.
 The number of disks on the source VM exceeds 25, and the slot ID of the IDE disk
conflicts with that of the RDM disk.
 The source VM has more than 25 IDE disks, and the IDE disk slot IDs conflict with that
of RDM disks.


Drill Suggestions
 If cluster applications, such as Oracle RAC and MSCS, are running in the VM, you are
advised to perform the switchover by application. No drill or switchover is involved.
 If PCS must be used for the drill, check the dependency of the service on the drive letter
or RDM disk slot ID in advance, set the handling action of the item to Ignore, and then
perform the drill.
 If cluster applications, such as Oracle RAC and MSCS, are running in the VM, you are
advised to perform the switchover by application. No drill or switchover is involved.
 If PCS must be used for the drill, check the dependency of the service on the drive letter
or RDM disk slot ID in advance, set the handling action of the item to Ignore, and then
perform the switchover.
12.60 Source VM Is Configured with a Free Clock

The clock policy of the source VM does not need to be synchronized with the host clock. That
is, a free clock is configured, and you can set the VM time. If the time set on the VM is
different from that on the host, the difference is cleared after the VM is switched over to the
KVM platform. In this way, the time on the target VM is different from that on the source
VM.


Drill Suggestions
 If the internal time of the VM depends on the periodic synchronization of the third-party
NTP server, ignore the obstacle item and perform the drill.
 If the internal time of the VM is manually configured and is different from the host time,
check the impact of the time change on services. If the impact is acceptable, ignore the
obstacle item and perform the drill.
 If the internal time of the VM depends on the periodic synchronization of the third-party
NTP server, ignore the obstacle item and perform the switchover.
 If the internal time of the VM is manually configured and is different from the host time,
check the impact of the time change on services. If the impact is acceptable, ignore the
obstacle item and perform the switchover.
12.61 Network Configurations of the Drill Port Group
and Source Port Group May Conflict
During the drill of the source VM, the MAC address of the drill VM is the same as that of the
source VM. To avoid the impact of the drill VM on the source VM, the NIC of the drill VM is
added to the specified drill port group. If the VLAN ranges configured for the drill port group
and source port group overlap, the drill VM may affect the network of the source VM.


Drill Suggestions
If the VLAN ranges configured for the drill port group and source port group overlap and this
has no impacts on the source VM, ignore the obstacle item and perform the drill.
In addition, even if the VLAN ranges configured for the drill port group and source port group
do not overlap, the drill port group and source port group may belong to the same Layer 2
physical network due to the physical network configuration, and as a result, the source VM is
affected during the drill. For example, VLAN 0 is configured for the source port group and
VLAN 100 for the drill port group. However, the physical switch connected to the host where
the source VM is located incorrectly sets VLAN 100 of the drill port group to untagged.
Therefore, you need to ensure that the physical network is correctly configured, rather than
completely depending on the pre-check of the item.
This obstacle item has no impact on the switchover, and the switchover can be performed.
12.62 Guest OS of the Source VM Does Not Support

Online Disk Snapshots
If the guest OS of a VM does not support online disk snapshots, PCS does not support online
drill of such VM.


Drill Suggestions
Online drill cannot be performed.
This obstacle item has no impacts on the switchover. You can perform the switchover.
12.63 Source VM Does Not Exist

If the source VM has been deleted from the source platform during VM switchover, the
switchover task will fail.


Drill Suggestions
The source VM has been deleted and no drill is required. You are advised to delete the VM
from PCS.
The source VM has been deleted and no switchover is required. You are advised to delete the
VM from PCS.
12.64 Target Compute Resources Are Unavailable

During VM switchover, the target compute resource (cluster or host) selected for the VM
during the switchover plan creation is deleted from the target platform, and the switchover
task fails.


Drill Suggestions
Modify the switchover plan to which the VM is added, select target compute resources for the
VM, and perform the drill.
Modify the switchover plan to which the VM is added, select target compute resources for the
VM, and perform the switchover.
12.65 VM Uses a Shared Disk

During the online drill, online snapshots are taken for a VM. If a VM has shared disks, a
snapshot cannot be created for the VM. Therefore, the PCS does not support online drill for
such VMs.


Drill Suggestions
The drill cannot be performed.
This obstacle item has no impacts on the switchover. For details, see "VMs that Use Shared
Disks Are Not All Stopped". To perform the switchover, stop all VMs that use the shared
disks.
12.66 Source VM Uses the UEFI Boot Firmware, but the

Guest OS Does Not Support UEFI on the Target Cloud
Platform
In FusionSphere virtualization suite 6.5.0 (KVM) and V100R006C10 (Xen), the guest OS
ranges that support the UEFI boot firmware are different. For example, a guest OS of the
source Xen VM uses the UEFI boot firmware, but the guest OS does not support UEFI boot
on the KVM platform. In this case, the VM cannot be subject to the drill and switchover.


Drill Suggestions
The switchover cannot be performed.
12.67 Source VM Uses an Independent Persistent Disk

and Has a VM Snapshot
Independent & persistent can be selected for a VM disk to avoid the impact of the snapshot
on the disk. That is, the disk does not support the volume snapshot function, and snapshots
cannot be created for the independent persistent disk. During the VM drill and switchover, a
VM or volume snapshot needs to be created, and the Independent & persistent mode of
disks is temporarily changed to the Dependent mode. After the VM drill and switchover, the
system restores the disk mode to the original mode.
When a snapshot is created for a VM that uses an independent persistent disk, the
FusionSphere virtualization suite does not support the change of the VM disk mode to the
Dependent mode. In this case, the drill is not supported.


Drill Suggestions
The switchover can be performed directly. During the switchover, the independent persistent
disk is temporarily changed to the dependent disk. For details, see 12.5"VM Uses an
Independent Persistent Disk."
12.68 The Guest OS Does Not Support Online Drill

During online drill, the VM system disk needs to be mounted for driver injection. However,
the system disk cannot be mounted when the OS is running.

Default impact: Major
Default handling action: Adjust VM Later
Optional handling action: Adjust VM Later

Default impact: None
Default handling action: N/A
Optional handling action: N/A
Drill Suggestions
The drill can be performed after safe shutdown.
The switchover can be performed.
12.69 The Hardware Configuration of Source VM
Exceeds the Specifications Supported by Guest OS
The FusionSphere Virtualization Suite V100R006C10 (Xen) can create VM with hardware
configurations that exceed the guest OS support specifications. For example, the 32-bit guest
OS memory configuration can be larger than 4G. This hardware configuration causes a waste
of the entire system resources. FusionSphere Virtualization Suite 6.5 (KVM) manages the
hardware configuration of different guest OS in more detail. If the VM hardware
configuration does not meet the KVM virtual machine creation conditions, the VM of the
same specification fails to be created on the KVM platform. Therefore, switchover is not
possible.


Drill Suggestions
Based on the OS requirements, modify the source VM hardware parameters and then perform
the drill. For details about the OS requirements, see the FusionSphere SIA Huawei Guest OS
Compatibility Guide (KVM Enterprise Virtualization).
The switchover cannot be performed.
Based on the OS requirements, modify the source VM hardware parameters and then perform
the switchover. For details about the OS requirements, see the FusionSphere SIA Huawei
Guest OS Compatibility Guide (KVM Enterprise Virtualization).
Obtain the document as follows:

For enterprise user: Visit http://support.huawei.com/enterprise and search for the document name.
For carrier users: Visit http://support.huawei.com and search for the document name.
12.70 iCache Is Configured for a Template VM

The source VM configured with iCache cannot be deleted during the confirmation of VM
switchover.


Drill Suggestions
You can switch over the VM template. If the VM template is faulty after the switchover, you
can perform rollback on PCS.
Perform the switchover after the iCache is deleted from the source VM.

FusionSphere PCS 6.5.1.1 Operation Guide (Virtualization Xen To KVM)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FusionSphere PCS 6.5.1.1 Operation Guide (Virtualization Xen To KVM)

Uploaded by

Copyright:

Available Formats

FusionSphere PCS

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2019-08-30) Copyright © Huawei Technologies Co., i

About This Document

Indicates an imminently hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

About This Document....................................................................................................................ii

6 Installation and Deployment....................................................................................................13

6.3.6 (Optional) Configuring a Backup Server..................................................................................................................19

8 VM Drill and Switchover..........................................................................................................28

9 Operations After Finish Confirmation....................................................................................37

10 Appendix 1 Common Operations..........................................................................................41

10.9 Using PuTTY to Log In to a Node in Key Pair Authentication Mode.......................................................................53

12 Appendix 3 Obstacle Item Description.................................................................................90

12.22 VM Uses Virtualized Local Hard Disks.................................................................................................................103

12.60 Source VM Is Configured with a Free Clock.........................................................................................................128

1.2 Switchover Process Overview

Upgrade the Xen plat form.

Prepare for the KVM platform.

Check whether VI MS uses hardware-

Yes Change it t o hardware-assisted locking.

Deploy the P CS environment.

Perf orm the drill.

Perf orm the switchover.

Perf orm service conf irmation.

Confirm the switch.

Disable dual-site management.

Convert the disk format from VHD to RAW.

A professional technical team is responsible for switchover evaluation, switchover solution

3.1 Introduction to the Switchover Service

3.1.1 Information Collection and Feasibility Analysis

3.1.2 Switchover Plan and Solution Design

3.1.3 Core Service Switchover Test

3.2 Switchover Risk

4.3 Switchover Pre-implementation Requirements

4.4 Switchover Implementation Requirements

4.6 Function Restrictions

5.1 Platform Compatibility

FusionCompute V100R006C10SPH108 FusionCompute 6.5.0

5.2 Guest OS Support Policies

6.1 Software Obtaining

Table 6.1.1.1.1.1.1.1.1 Switchover tool software

FusionSphere_PCSA_Virtualization- PCS Agent template file

Table 6.1.1.1.1.1.1.1.2 Switchover tool software material

FusionSphere PCS 6.5.1.1 Operation FusionSphere PCS 6.5.1.1 Operation Guide

6.2 Switchover Software Specifications

Table 6.2.1.1.1.1.1.1.1 Specifications of the controller VM

CPU 4 CPUs and above

Table 6.2.1.1.1.1.1.1.2 Specifications of the injection agent VM

CPU 2 CPUs and above

6.3 Installation and Deployment

Create a FusionCompute platform according to FusionSphere Virtualization Suite 6.5.0 Product

6.3.2 Upgrading the Xen Platform to V100R006C10SPH108

For details, see FusionCompute V100R006C10SPH108 Upgrade Guide.

6.3.4 Configuring Dual-site Management to Allow Source and

Configuring Dual-site Management

Changing VIMS Cluster Node IDs in FusionCompute 6.5.0

6.3.5 Deploying Controller and Agent VMs on the Target

Step 2 Configure PCS controller and agent VM object permissions.