Starting and Uninstalling a Cloud Phone

Ensure that the kbox_config.cfg file exists in the startup path of the cloud phone instance. The container uses the configuration in this file. Therefore, ensure that the configuration in the kbox_config.cfg file is correct. If the configuration file does not exist in the startup path, the cloud phone cannot be started.

You can change map configurations (see Table 1) of a channel to select the GPU, CPU, and path to the data volume used by the container of this channel. In this way, you can flexibly configure resources used by cloud phones to achieve optimal performance.

To ensure the stable running and optimal performance of the Kbox cloud phone, ensure that the physical CPU cores and GPU rendering nodes bound to a container belong to the same CPU chip.

The Kbox cloud phone container allows users to customize and overwrite system properties as required. To use custom properties, create a local.prop file in the startup path to record custom system properties. After a container is started, properties in this file are read to overwrite the original properties during container initialization. For details, see "Customizing Android System Properties" in Kbox Cloud Phone Container Routine Maintenance.

1. Decompress Kbox-AOSP11.zip and upload the deploy_scripts directory in the Kbox-AOSP11 folder to the ~/dependency directory on the server.
2. (Optional) Enable hardware decoding.
   1. Modify the kbox_config.cfg file in the deploy_scripts directory by setting ENABLE_HARD_DECODE to 1.
      

      If software decoding is used when a cloud phone is started, that is, ENABLE_HARD_DECODE is set to 0, the decoding mode can be switched to hardware decoding after setting ENABLE_HARD_DECODE to 1 and restarting the cloud phone.

   2. (Configuration scheme 1) If hardware configuration scheme 1 is used, perform the following operations to configure NETINT card nodes:
      1. Run the following command to view the nodes of the NETINT card chips.

         1

         nvme list

         The following is an example of the command output. The information in bold indicates the NVMe nodes of the chips of the NETINT Quadra encoding card. One encoding card has two chips.

         1 2 3 4

         Node SN Model Namespace Usage Format FW Rev ------------- -------------------- ---------------- --------- ------------------------ ---------------- -------- /dev/nvme0n1 Q2A325A11DC082-0454A QuadraT2A 1 8.59 TB / 8.59 TB 4 KiB + 0 B 48F6rKr1 /dev/nvme1n1 Q2A325A11DC082-0454B QuadraT2A 1 8.59 TB / 8.59 TB 4 KiB + 0 B 48F6rKr1

      2. Check the mapping between NVMe nodes and PCIe bus numbers.
         {index} indicates the NVMe node number returned in 2.b.i. For example, in /dev/nvme0n1, the value of {index} is 0.

         1	find /sys/devices/ -name nvme{index}

         In the following command output, 0000:05:00.0 indicates the bus number of the device.

         1 2	/sys/devices/pci0000:00/0000:00:0e.0/0000:05:00.0/nvme/nvme0 /sys/devices/virtual/nvme-subsystem/nvme-subsys0/nvme0

      3. Check the mapping between the node and NUMA based on the bus number.
         {busID} indicates the bus number obtained in the previous step. For example, in the command output for nvme0, {busID} is 0000:05:00.0.

         1	lspci -vvvs {busID} | grep NUMA

         The command output is as follows:

         1	NUMA node: 0

      4. Change the value of NETINT in the kbox_config.cfg file based on the NUMA information corresponding to the NVMe node of the encoding card.

         For servers powered by Kunpeng 920 7260 processors, write NVMe nodes belonging to NUMA 0 and NUMA 1 in the NETINT0 field, and NVMe nodes belonging to NUMA 2 and NUMA 3 in the NETINT1 field.

         Two nodes need to be added for each device in a field. For example, for NVMe device 2, you need to add nodes /dev/nvme2 and /dev/nvme2n1.

         # Nodes of NETINT encoding card devices
         NETINT0="/dev/nvme0,/dev/nvme0n1,/dev/nvme1,/dev/nvme1n1"
         NETINT1="/dev/nvme2,/dev/nvme2n1,/dev/nvme3,/dev/nvme3n1"

         

         • If the value of NETINT is empty when the container is started for the first time, do not set ENABLE_HARD_DECODE to 1. Do not set ENABLE_HARD_DECODE to 1 also when the container is restarted. Otherwise, a black screen will occur for a short period of time when you play a video.
         • To enable hardware decoding of the NETINT encoding card, set ENABLE_HARD_DECODE to 1 in kbox_config.cfg.
         • For an environment where one Quadra T2A encoding card is installed, configure the device node information based on the site requirements. The following configuration is for reference.

           # Nodes of NETINT encoding card devices
           NETINT0="/dev/nvme0,/dev/nvme0n1,/dev/nvme1,/dev/nvme1n1"
           NETINT1="/dev/nvme0,/dev/nvme0n1,/dev/nvme1,/dev/nvme1n1"

3. Run the android_kbox.sh script to start containers.

   1 2 3

   cd ~/dependency/deploy_scripts chmod +x android_kbox.sh ./android_kbox.sh start {image_name:tag} ${index1} ${index2}

   Table 2 lists the default configurations of a Kbox basic cloud phone.

   Table 2 Default configurations

   Item	Kbox Basic Cloud Phone
   Scenario	Mobile office/hosting
   vCPU	2
   CPU core binding policy	2 containers, 2 cores
   Memory	6 GB
   System storage	16 GB
   Resolution	720 x 1280

   The following are examples of using the startup script:

   • Start instance 1.

     1	./android_kbox.sh start kbox:origin 1

   • Start instances 1 to 5.

     1	./android_kbox.sh start kbox:origin 1 5

     

     When a Kbox cloud phone container is started, the dynamic Kbox kernel switch is automatically enabled to enable necessary Linux kernel functions.

     You can run the following command to query the dynamic switch status:

     1	cat /sys/kernel/kbox/kbox_enable

     If 1 is displayed, the switch is enabled. If 0 is displayed, the switch is disabled.

     You can run the following command to manually enable the switch:

     1	echo 1 > /sys/kernel/kbox/kbox_enable

4. Run the following command to check whether a Kbox container is started successfully. ${index} indicates the ID of the instance.

   1	docker exec -it kbox_${index} getprop | grep boot_completed

   In the output, if the value of sys.boot_completed is 1, the startup is successful.

5. Stop and delete Kbox containers.

   In the Kbox solution, data volumes are mounted by default. The default docker stop and docker rm commands cannot completely clear container data. Run the following script to completely clear files on the host.

   Run the android_kbox.sh script to stop and delete running Kbox containers.

   • Stop and delete a container whose ID is ${index}.

     1	./android_kbox.sh delete ${index}

   • Stop and delete containers numbered from ${index1} to ${index2}.

     1	./android_kbox.sh delete ${index1} ${index2}

6. Restart Kbox containers.

   In the Kbox solution, data volumes are mounted by default. The default docker restart command cannot restart a container. Instead, run the following script to restart a container.

   Run the android_kbox.sh script to restart Kbox containers.

   • Restart a container numbered ${index}.

     1	./android_kbox.sh restart ${index}

   • Restart containers numbered from ${index1} to ${index2}.

     1	./android_kbox.sh restart ${index1} ${index2}