Treat the sender’s local storage as shared storage during the live migration process.
When I perform a live migration between two physical machines, A and B, with A sending the virtual machine and B receiving it, I use shared storage migration. The NFS service is provided by A, and A has set the /home/test folder as a shared folder. B executes
mount -t nfs ip:/home/test /home/test
It is a single-disk virtual machine, and the disk is /home/test/test.qcow2. Its permissions are:
-rw-rw-r-- 1 root root 1.2G May 8 14:10 test.qcow2
After the migration is completed, I encounter a problem where the destination virtual machine (B) cannot write to the qcow2 file. The reason is that the sending end (A) has determined the virtual machine to be non-shared storage. Non-shared storage sets test.qcow2 to the following at virtual machine startup:
-rw-rw-r-- 1 qemu qemu 1.2G May 8 14:10 test.qcow2
After the migration is completed, the permissions are restored to the previous state:
-rw-rw-r-- 1 root root 1.2G May 8 14:10 test.qcow2
However, this is incorrect because test.qcow2 is shared storage.
I noticed that the implementation code for this function is located in the virSecurityDACRestoreImageLabelInt function in src/security/security_dac.c. The code is as follows:
if (migrated) {
int rc = 1;
if (virStorageSourceIsLocalStorage(src)) {
if (!src->path)
return 0;
if ((rc = virFileIsSharedFS(src->path)) < 0)
return -1;
}
if (rc == 1) {
VIR_DEBUG("Skipping image label restore on %s because FS is shared",
src->path);
return 0;
}
}
When virFileIsSharedFS makes a judgment, because virFileIsSharedFS's statfs(dirpath, &sb); returns sb.f_type=0x58465342 (XFS_SUPER_MAGIC), this shared storage located at the sending end is recognized as non-shared storage.
Is there a better way to identify test.qcow2 as shared storage?