Quoting Peter Oberparleiter <ober...@linux.ibm.com>:
Peter, thank you for your excellent analysis and clarification of how this works. It now makes perfect sense to me. Based on your comments, I have a few questions/comments:
The moment that you enable the cloned disk in Linux, the system is in an inconsistent state. You will find that persistent block device links in /dev/disk/by-id, by-uuid and potentially by-label immediately point to the cloned device. Any operation that relies on a correct association of these persistent block device links will not perform correctly. This includes a rebuild of the initial RAM-disk via dracut.
I tested the what you said above. Sure enough, if you have dasda1 as your root device for the active system, you will find properly defined device names in by-id, by-path and by-uuid for this disk. Then if you were to activate/enable a clone of that disk, say as dasdf1, what happens is that by-id and by-path are still correct (they point to dasdf1) but chzdev will replace the existing symbolic link in by-uuid pointing to dasda1 with a new one pointing to dasdf1 (as it should) so now you will overwrite the previous UUID symbolic link that pointed to dasda1 with one that points to dasdf1. We no longer have one for dasda1 which is the true root file system since we can't have two files with the same name here. chzdev does this without any warning. Shouldn't it at least give a message or better yet, no replace the file in by-uuid? Perhaps it would be good to present the same warning as it currently does when you try to disable/deactivate a disk and it detects conflicting UUIDs. In my opinion, that would be a good thing as it prompts the user that they are about to do something that may result in a system being in a inconsistent state. Not creating the link in by-uuid in situations like this would avoid the problem all together. Interestingly, at boot time, if you have two devices that have the same UUID (as in above) only the first device will end up having a by-uuid link created. Apparently, at boot, when the second device is created, it does not cause the by-uuid link of the first device to get replaced. This is assuming they second device is not created first and then the first but I don't know how I can tell.
dracut tries to determine the device number and persistent ID of the block device that provides the root file system and stores the result inside the initial RAM-disk. Since the persistent links are incorrect, the wrong data is used during boot, even if the cloned disk is removed.
This makes perfect sense now. I somehow think it is unlikely we can get dracut developers to change this behavior or at least check for it. Since on z/VM we do a lot of cloning of disks/severs, I think we may have a lot of disks lurking around with matching UUIDs. That's why I thought a message or change in behavior for chzdev would be helpful. Or by not creating the by-uuid links, we can still allow access to the device but not create confusion for dracut and other utilities that reference disks by uuid.
The evaluation of file system UUIDs by chzdev was specifically added to support correct handling of multi-disk btrfs file systems. Also given that a file system UUID is supposed to uniquely identify a file system, I don't consider the current behavior a problem in chzdev.
I think moving forward, I will implement a procedure to change the disk UUIDs after cloning. I don't see this mentioned in any of the past cookbooks but feel it is a prudent thing to do. Thank you again for your input. Aria
Regards, Peter -- Peter Oberparleiter Linux on Z Development - IBM Germany ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
