Since I don't have the original email to reply-to, here is a link: https://www.redhat.com/archives/libvirt-cim/2012-December/msg00033.html libvirt-cim.conf Consider changing the following: +# Defines a temp key file which would be used as ssh key in ssh migration, +# Only valid when SSH_Key is set in migration call. +# If SSH_Key is not in a directory owned by root, set this value to a path +# owned by root, tells libvirt-cim copy it there before use it. The directory +# in the path must exist and totally owned by root. +# If SSH_Key is already in a valid place, don't set it to to tell libvirt-cim +# use SSH_Key directly. # Only valid when SSH_Key is set for the migration call. # # In order to allow using a non-root owned SSH Key during migration, set this variable # to a location to copy the SSH_Key from the SSH_Key path and file not owned by root # to a directory path and file owned by root. The target path must exist and it must # be owned by root. If it is not, the migration will fail. # # If the SSH_Key is already in a directory owned by root there is no need to set, thus # allowing libvirt-cim to use the SSH_Key directly. libxkutil/misc_util.c In libvirt_cim_config_get() * The 'default:' case should probably also which prop->name was being used for the prop->value_type In is_read_only() & get_mig_ssh_tmp_key() * Probably should initialize prop.value_string = NULL just to be clear * Call to libvirt_cim_config_get() does not check return status - perhaps make setting prop.have_read conditional on return value... src/Virt_VSMigrationService.c In ssh_key_cp(): * Do you need a path to 'cp' (eg /sbin/cp)? * Is it worth a stat() afterwards to ensure the copy occurred since your fgets() isn't returning anything? * Other thoughts - should there be a "stat" and "rm" before? Perhaps another safety ensure we copy something? In get_msd_values() * Since you already print the source ssh_key file, change the the copy src to dest message to just indicate the destination (e.g. "Copying ssh key to '%s'.", tmp_keyfile) So let's say this is successful, now we leave the 'migrate_ssh_temp_key' around? Is that a good idea? Shouldn't there be a corresponding 'unlink()' after we're done? We're really not a "temporary" file if we keep it around. In fact, after the connection is made, shouldn't we be able to safely delete the file? John Finally, this one seems to require/need an update to documentation "somewhere" to describe that new conf variable... That is how does one know how to use this unless they read the conf file?