[DRBD-user] changing resource names

[David]

On 26/4/19 10:52 pm, Roland Kammerer wrote:
> On Thu, Apr 25, 2019 at 11:02:55AM +1000, David wrote:
>> On 24/4/19 5:44 pm, Roland Kammerer wrote:
>>> On Tue, Apr 23, 2019 at 10:22:16PM +1000, David wrote:
>>>> Sorry if this is a newbie question.
>>>>
>>>> I have a number of resources (VM's) on a two node system for which the
>>>> resource names are now misleading and I would like to change them. Is it
>>>> possible?
>>>>
>>>> Do I just change the .res files or some other config? Do I have to shutdown
>>>> all VM's and change both node configs at the same time?
>>>>
>>>> I can't find any documentation how to (safely) do it.
>>>>
>>>> Could anybody point me to it?
>>> You created these manually, right? No plugins/drbdmanage/LINSTOR involved?
>>>
>>> If so, sure, you can do that. "down" it on one side, rename it in the
>>> res file, and "up" it again. Check how you used the DRBD block device.
>>> Via the minor? Good. Via the udev generated symlink? You need to adapt
>>> your setup.
>>>
>>> And again, this is all for a manual setup. All plugins I can imagine/we
>>> provide would be horribly confused if somebody changes the name
>>> underneath them.
>> I have this udev rule:
>> KERNEL=="drbd*", IMPORT{program}="/sbin/drbdadm sh-udev minor-%m",
>> NAME="$env{DEVICE}", SYMLINK="drbd/by-res/$env{RESOURCE}
>> drbd/by-disk/$env{DISK}"
>>
>> but I admit I have no idea what to do with it :)
> Looks okay. So you most likely have some /dev/drbd/by-res/resname/0
> symlinks to to the actual device. And then it depends how DRBD is used.
> Maybe there is a file system on top and it gets mounted as "/dev/drbd123
> /mnt". Then you are fine. But if it got mounted as
> "/dev/drbd/by-res/.... /mnt", then obviously you have to change that
> when you rename the DRBD resource. But you have to know your system.
> "/etc/fstab" is one case where it might be necessary to change the block
> device.

Thanks for your continuing help....

fstab has only the host's root and swap. The guest called "acc" is 
represented thus:

    root at hostl1:~# ls -l /dev/drbd/by-res/acc-hda
    lrwxrwxrwx 1 root root 12 Apr 18 15:09 /dev/drbd/by-res/acc-hda ->
    ../../drbd15

    root at host1:~# ls -l /dev/drbd/by-disk/host1/acc-hda
    lrwxrwxrwx 1 root root 15 Apr 18 15:09
    /dev/drbd/by-disk/host1/acc-hda -> ../../../drbd15

    root at host1:~# ls -l /dev/drbd15
    brw-rw---T 1 libvirt-qemu libvirt-qemu 147, 15 Apr 27 18:42 /dev/drbd15

    root at host1:/etc/drbd.d# cat acc-hda.res
    resource acc-hda {
         on host1 {
             device        /dev/drbd15;
             disk        /dev/host1/acc-hda;
             address        169.254.88.21:44535;
             meta-disk    internal;
         }
         on host2 {
             device        /dev/drbd15;
             disk        /dev/host2/acc-hda;
             address        169.254.88.22:44535;
             meta-disk    internal;
         }

         net {
             allow-two-primaries;
         }
    }

    root at host1:~# ls -l /dev/host1/acc-hda
    lrwxrwxrwx 1 root root 8 Apr 18 15:06 /dev/host1/acc-hda -> ../dm-14

Am I right to assume that dm-14 being similar to the minor number (15) 
is coincidence? It's not clear to me how /dev/host1/acc-hda is set up or 
even what it does. Does that come from the udev rule somehow?

The change I need to make is of the form "acc" to "xyz", so the steps 
that make sense to me are:

    * edit acc --> xyz in /etc/drbd/acc-hda.res on BOTH hosts

    * shutdown xyz guest on both hosts

    * reload udev rule on both hosts <# udevadm trigger>

    * restart primary guest

Does that look right? I would hate to make changes that cause a crash I 
can't recover from.




>
> Regards, rck
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user

-- 
David McQuire
0418 310312

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20190428/c18b5a58/attachment.htm>