I was testing some things and ran a zfs rename /tank/myzvol /tank/other/myzvol on my VM’s main OS disk zvol (/tank/myzvol) while my VM was active. There was no warning about device busy or anything. The VM kept running and did not complain and there were no error messages. I shut down the VM and tried to start it again. Of course, there was an error saying the /dev/zvol/tank/myzvol is not valid. I changed the disk target to the new zvol location in the VM > Devices settings and it started right up as if nothing happened. Does this corrupt something, either in the VM or elsewhere in the pool/filesystem? How can it just keep working? I thought this was not possible. Can someone on the team explain the mechanism of this to me? Thanks!
rename while the guest is live is allowed because zfs is renaming the dataset metadata. the open handles / zvol major:minor the kvm process already has stay valid until close. so the guest keeps running on the old device node even after the path name moves.
after shutdown the vm config still points at the old /dev/zvol/… path, which is why start failed until you retargeted Devices. nothing in the guest filesystem gets rewritten by the rename. pool integrity is fine as long as zpool status is clean.
if you want to double check: zfs get name,creation,volsize tank/other/myzvol and confirm the vm disk path matches that new name. next time stop the vm before renaming so the ui and the zvol stay in sync.
@nite_route thanks for this explanation, I will add it to my notes.
@nite_route thank you so much for the explanation. Is that a TrueNAS feature or just vanilla openZFS? And does that same functionality carry over to a zvol that is used with iSCSI or NVMEoF? And it’s for sure safe?
vanilla openzfs. truenas isnt doing anything special there.
same idea for iscsi / nvme-of. the target keeps the open handle while the session is up, so a rename of the backing zvol usually doesnt yank the live export. after the initiator reconnects or you restart the share, it has to point at the new dataset path / extent config though, same as the vm disk path did.
pool side is still safe if zpool status is clean. just keep the share/vm config in sync with the new name.
You say usually. Does it ever yank it? Is there a scenario where renaming something live will either drop the connection or cause corruption?
if the process already has the zvol open, rename almost never drops it. ive only seen a yank when something closes the handle and tries to reopen by the old path, like restarting the iscsi target or reloading the vm disk config mid flight.
rename itself doesnt rewrite guest data. zpool status clean means the pool side is fine. the messy part is admin confusion about which path is current, so stop the vm or offline the extent, rename, then retarget and start.
Thank you. Can you point me to any openZFS documentation that describes this behavior?