How to move UCS server from one UCS FI domain to another UCS FI domain without losing local disk OS

jamdev120 · ‎05-30-2020

Hi all,

I'm currently in the process of having to move a physical rack server from one UCS FI domain to another UCS FI domain. This server is running Linux on a local disk policy. The disk policy is a storage profile with a disk group with 2 disks in a raid 1 mirror. I have no scrub policy defined in the current service profile, or new one where the server is been moved to. I want to make sure the installed OS does not get destroyed. Is it just as simple as;

1. Disassociate the service profile from current server in current UCS FI domain.

2. Decommission the server from the current UCS FI domain.

3. Move server to new UCS FI domain

4. Associate new service profile from new UCS FI domain

5. Boot server

Won't I have problems applying a new service profile that requires two disks that are in JBOD mode and since the current disks already have a mirror on it, won't the new service profile not be assigned? How can I avoid deleting the current storage profile? I want to make sure I do not lose the OS installed on it.

Wes Austin · ‎05-30-2020

The process you outlined is correct. On the new service profile, you would need to have the same or similar local disk configuration or storage profile in order to boot the host OS. On your new service profile that you plan to use JBOD, where do you plan to boot from if the disks are not in a RAID?

If this is a blade and not a rack server, you can just use the local disk configuration policy instead of a storage profile.

jamdev120 · ‎05-30-2020

Hi Wes,

Thanks for the response and thanks for confirming that my steps seem correct. Let me provide a few pictures of what I mean. Below is a picture of a rack system profile and the storage profile I have assigned.Storage Policy attached to Service Profile

Here is the Storage Profile defined:Storage Policy definition

Below is the Storage Disk Group policy that controls what disks get selected and what type.Storage Disk Group definition

As you can see, the use of JBOD Disks radio button is set to yes. I have noticed in the past that as soon as I apply a service profile with this type of storage profile to the server, the UCSM complains that there are not enough disks available to apply this storage profile to and it will not move forward. What I've had to do in the past, is go to the current inventory of the system that I'm applying the Service Profile to, go to storage and delete the LUN as well as reconfigure the disks to JBOD. Now I don't know if doing such a thing and just applying the Service Profile on top doesn't do much except just configure the disks again without erasing anything on them. But I'm going of a big if here. Don't want to assume that deleting the LUN and returning the disks to JBOD is just a cosmetic thing. I would think the UCSM will delete the LUN and reset the disks so that upon applying the service profile, the data on these disks would be gone.

Unless you are stating that what I should do is from the new service profile that I would apply to this server is to switch it from a storage profile to one that is a local storage profile that would allow me to use the current disks as they are. Is this what you mean?

Thanks again and I look forward to your response.

jamdev120 · ‎05-30-2020

Oh and by the way, I do not have blade servers. They are all rack servers.

Wes Austin · ‎05-30-2020

I believe that JBOD radio box just lets the storage profile know you can use JBOD disks.

If you only have two drives and you want to retain the info on the disks, I would just use a local disk config policy, set it to "any config" and then you can attempt to boot up. This way UCSM will not attempt to change any of the existing RAID settings on the disk. You can also go into the WEBbios and confirm the RAID is in tact while the server boots.

jamdev120 · ‎06-22-2020

Thanks for the info. I came to find out that in the new service profile, as long as the storage policy and the disk group have the same name as the old one, then the service profile implementation on a server moved will not touch the local disk. I guess this is the reason to have UCS Director so that you can move machines between UCSM domains while keeping the profiles.