Thanks Alan. In all cases, the cloning is done with server down so this is not caused because of that. Also, note that I said all you have to do is format a test empty disk and then simply set the UUID of the disk to one of the existing OS disks, even when not mounted, it is seen as 'in use' by chzdev.
I am not too concerned about the chzdev behavior but more concerned with the fact that having a disk around with identical UUID could cause boot problems if you were to make changes to boot options. Thanks, Aria -----Original Message----- From: Linux on 390 Port <[email protected]> On Behalf Of Alan Altmark Sent: Sunday, October 3, 2021 11:00 AM To: [email protected] Subject: Re: Warning if upgrading SLES12 to SLES15 SP3 On Friday, 10/01/2021 at 08:20 GMT, "Aria Bamdad" <[email protected]> wrote: > It seems that there may be a problem with the new s390-tools chzdev command > at the least. Consider the following situation. You have a Linux guest > with root file system on device 150, usr on 151, var on 152. Then you make > a copy of these disk (DDR/flashcopy/Etc.), say you are cloning the guest. > The copied disks are now called F50, F51 and F52 respectively. Now consider > that you boot from your normal 15x disks while you have the F5x disks linked > and defined to the virtual machine. Then you use chzdev command to enable > any of the cloned disks, say F50 (clone of root). You can do this either > using commands like chzdev or via Yast DASD tool to activate. So far so > good. But if you then try to disable the same disk (F50) using chzdev (or > Yast DASD), chzdev complains with: > > Warning: ECKD DASD 0.0.0f50 is in use! > The following resources may be affected: > - Mount point / > Continue with operation? (yes/no) > > Well, it's neither in use (not mounted anywhere, just enabled), nor is it > the root mount point. The same will be true for F51 and F52. Chzdev states > that these are in use and mount points /usr and /var. This does not happen > when the disk is not a clone. Traditionally the file systems mark the disks as 'in use' when they are mounted so that that message can be issued, among other things. Consequently, if you clone it while it's mounted, the clone will have the same marking and appear to be in use. IMO, cloning should be done with the file system unmounted. Once the disk is cloned, it's no longer the same disk in terms of content, but if memory serves, the logical volume manager remembers UUIDs so that it can automatically form the logical volume. If it were to see a desired UUID on a different disk, it could grab the wrong disk, resulting in a corrupted file system. Timing is everything. If you're cloning and immediately giving it to a different server, then it wouldn't make any difference since the "universe" of UUIDs is limited to what the server has access to. Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services IBM Z Delivery Practice ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 [email protected] IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] 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 [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
