更新母盘会影响学生已存的数据吗？

不会。母盘是共用的基础只读层，学生数据在独立的个人数据层 / 网络磁盘里，更新母盘只换基础系统层，个人数据独立保留。

更新时要停课吗？

不用。支持边下边用，终端一边接收新版本一边照常上课；也可把分发安排到夜间定时下发，白天完全不受影响。

下发到一半断电 / 重启会不会把镜像搞坏？

不会。V5 支持断点续传，断电 / 重启后自动从中断处续传，且不损坏当前正在使用的镜像版本。

更新后发现新版本有问题怎么办？

一键回滚。每次更新都生成版本快照、旧版本保留，在后台把对应终端的启动版本切回上一个稳定快照即可，无需重装。

几百台机器更新会不会很慢、老是 0 速？

不会。默认 BT 做种互传，机器越多传得越快、成功率远高于链传 / 广播；配合增量差异，只传改动部分。

异构 / 信创终端能一起更新吗？

可以。x86 与国产（鲲鹏 / 飞腾 / 统信 / 麒麟）终端在同一后台纳管，按架构分组下发对应镜像版本。

Operation Tutorial · IDV Image Update

How to Update IDV — 6-Step vDisk Image Update Guide (No Class Downtime)

Modify the master image once → all labs update automatically · incremental differences · use while downloading · resume from breakpoint · no class suspension

IDV / vDisk cloud desktop 'one-image unified management': installing software, applying patches, or changing courseware only requires modifying the master disk image once, then distributing it to the entire computer lab. This article explains, in the order of actual operations, the complete process of vDisk image updates, incremental differences and breakpoint resumption mechanisms, as well as how to schedule unattended updates and how to roll back if problems occur.

Check update steps Update FAQs

First understand: what is a vDisk update?

IDV / vDisk adopts the 'one master disk image → shared by entire lab' model; the essence of updates isChange master image, send differences。

Master Image (Base Layer):The entire lab shares the same read-only master disk. Installing software, applying patches, changing wallpapers/courseware—all are done by modifying the master disk once.

Incremental difference update:When saving the master image, only generate 'difference blocks from the previous version'; during distribution,Only transmit changed parts, no need to re-push the entire disk; an update of several GB may transmit only a few hundred MB.

Use while downloading + resume from breakpoint:Terminals receive the new version while continuing normal class use; cached content is read locally. After shutdown / power loss / reboot, automaticallyResume transferDoes not clear and restart, does not damage the current image.

Version snapshot:Each update generates a new version; old versions are retained, allowing forOne-Click RollbackTo the previous stable version.

Web management backend: centralized management of image versions and distribution strategies.

vDisk Image Update · Step-by-Step Operation

Standard 6-step process: modify the master image once, and the entire lab updates automatically.

Step 1 · Enter Master Image Edit Mode

In the web management backend, select the master disk image to update, set it to "Edit / Writable" mode, and assign a terminal (or a backend virtual machine) toWritable modeBoot the master image. Any changes made to the system at this point will be written to the master image.

Step 2 · Make changes in the master image

Just like operating a regular computer: install/uninstall software, apply OS and antivirus patches, update courseware and exam environments, change wallpapers and policies. It is recommended to complete all changes needed for the current round at once to reduce the number of update versions. After making changes,Normal shutdown(Do not force power off).

Step 3 · Save and generate new version (incremental difference).

The backend 'submits/archives' the master image as a new version, calculated automatically by the system.Difference blocks from previous versionand generate an incremental. Only the changed parts are archived; a software update of several gigabytes often produces only a few hundred megabytes of incremental data. It is recommended to add a note to the version (e.g., '0701 Install Office + Patches') for easy rollback and location.

Step 4 · Select distribution strategy and deploy

Specify the range of terminals to update (by lab / group / all), select distribution method: default BT seeding peer-to-peer, the more machines, the faster the transfer, with a much higher success rate than chain/broadcast transmission. You can set "use while downloading" to let terminals start class while receiving, or schedule a unified overnight distribution.

Step 5 · Gray Verification (Strongly Recommended)

First only forOne or two unitsDeploy new versions to a terminal first; confirm that software, peripherals, teaching, and restoration all work normally, then push to all. Avoids individual compatibility issues affecting the entire lab.

Step 6 · Full Switchover and Rollback

After successful gray release, deploy fully; terminals switch to the new version upon next reboot. If issues are found, revert the boot version for that group of terminals in the backend.Revert to previous snapshotOne-click rollback, no reinstallation required.

Key mechanism for worry-free updates

Incremental difference

Only transmit changed blocks from the previous version, not the entire disk, greatly saving time and bandwidth.

Use While Downloading

Terminals receive new versions while classes run normally; cache hits mean local reads, no class interruption.

Resumable Transfer

Automatic resume after shutdown / power loss / reboot, does not clear and restart, does not damage the current image.

BT seeding distribution

The more machines, the faster the transfer, success rate far higher than the 0-speed serial chain/broadcast of traditional methods.

Scheduled unattended operation

Standard cron scheduled tasks, arranged for automatic distribution and power on/off at night, the next day boots into the new version.

One-Click Rollback

Version snapshots are retained; in case of anomalies, simply switch the terminal's boot version back to the previous stable version, no reinstallation needed.

Recommendation: Scheduled updates at night, no disruption during the day

For computer rooms with tight schedules and inconvenient daytime updates, we recommend usingScheduled taskSchedule updates for night:

Make changes on the master image during the day, seal the new version (steps 1–3);
Use standard cron to set automatic execution at night (e.g., 23:30).Distribute New Version + Scheduled Shutdown；
On the next day's startup, terminals automatically switch to the new version, completely unattended;
If temporary verification is needed, use the WeChat Mini Program to remotely power on / restart a single terminal for confirmation.

IDV Update FAQ

Does updating the master image affect students' saved data?

No. The master image is a shared, read-only base layer; student data resides in an independent personal data layer/network disk. Updating the master image only replaces the base system layer, and personal data is preserved independently.

Do classes need to stop for updates?

Not needed. Supports use-while-downloading, terminals receive the new version while continuing class as usual; distribution can also be scheduled for overnight timed delivery, with no impact during the day.

If power is cut / reboot occurs during distribution, will the image be corrupted?

No. V5 supports resumable transfer; after a power outage or reboot, it automatically resumes from the interruption point without damaging the currently used image version.

What to do if a problem is found after updating to a new version?

One-click rollback. Each update generates a version snapshot, with old versions retained. In the backend, simply switch the boot version of the corresponding terminal back to the previous stable snapshot—no reinstallation required.

Will updates for hundreds of machines be slow, often stuck at 0 speed?

No. By default, it uses BT seeding for peer-to-peer transfer; more machines mean faster transfer and much higher success rates than chain/broadcast transmission. Combined with incremental differences, only changed parts are transmitted.

Can heterogeneous/domestic terminals be updated together?

Yes. x86 and domestic (Kunpeng / Phytium / UOS / Kylin) terminals are managed in the same backend, with corresponding image versions distributed to groups based on their architecture.