Re: [DRBD-user] drbd raid stays at state peer: Connecting

[G. Milo]

I doubt there's something blocking the resource "hastig" as I assume the
resource was working fine in the past on both nodes? Disabling firewall on
both nodes temporarily would rule out that possibility.Most likely you are
facing some kind of network congestion on the replication network.

Does "drbdadm disconnect hastig" followed by "drbdadm adjust hastig" make a
difference? Otherwise you may need to check the syslog for further clues. I
noticed that you have 4 volumes in that resource. Is there a specific need
to have them configured on one resource rather than creating a separate
resource for each ? I'm not saying it's wrong, it's kind of unusual...



On Sun, 17 Oct 2021 at 10:07, Christoph Pleger <
christoph.ple...@cs.tu-dortmund.de> wrote:

> Hello,
>
> on two servers, I created two drbd resources, where one server is the
> primary for the first resource and the other server is the primary for
> the second resource. A dump of my setup is attached.
>
> Unfortunately, the drbd RAID works for the first resource, but it does
> not for the second. "drbdadm status" since almost two days now shows on
> the first machine:
>
> grobi role:Primary
>   volume:2 disk:UpToDate
>   peer role:Secondary
>
> volume:2 replication:Established peer-disk:UpToDate
>
> hastig
> role:Secondary
>   volume:1 disk:Inconsistent
>   volume:3 disk:Inconsistent
>
> volume:4 disk:Inconsistent
>   volume:5 disk:Inconsistent
>   peer: Connecting
>
> On the second machine, it shows:
>
> grobi role:Secondary
>   volume:2 disk:UpToDate
>   peer role:Primary
>
> volume:2 replication:Established peer-disk:UpToDate
>
> hastig role:Primary
>
> volume:1 disk:UpToDate
>   volume:3 disk:UpToDate
>   volume:4 disk:UpToDate
>
> volume:5 disk:UpToDate
>
>
> Any idea what is going on and what I can do now to make RAID hastig
> work? The two machines are in the same network and I have disabled all
> local ip filter rules, so I do not know what might be blocking the
> connection between the two servers ...
>
> Regards
>   Christoph
>
>
> ___
> Star us on GITHUB: https://github.com/LINBIT
> drbd-user mailing list
> drbd-user@lists.linbit.com
> https://lists.linbit.com/mailman/listinfo/drbd-user
>
___
Star us on GITHUB: https://github.com/LINBIT
drbd-user mailing list
drbd-user@lists.linbit.com
https://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] thin volume looses sparse during replication

[G. Milo]

Check the section in DRBD user guide, "4.1.8. Skipping initial
resynchronization". I think  that's what you are looking for, assuming that
there's no need to preserve the data on existing volumes (i.e you start
with blank LVM volumes).

On Sun, 24 Oct 2021 at 11:55, Pierre-Philipp Braun 
wrote:

> Hello
>
> when performing the initial synchronization of an thin-provisioned LVM2
> volume from primary to secondary, I can see data gets written on
> secondary and the resulting LVM2 volume, although supposedly "thin",
> ends up with 100% used data.
>
> To fix that, I need to `blkdiscard` it (even from the primary, that
> works too) after synchronization.  And this is an extraordinary painful
> step to go through.  Because of that limitation, I cannot create many
> drbd resources that would over-commit physically available space at
> once: I need to sync/discard the resources step by step...
>
> Is there a way to make the initial replication keep being thin (or
> sparse, as in file-system terminology, when dealing with zeroes)?
>
> Thank you!
>
> Best regards,
> --
> Pierre-Philipp Braun
> SMTP Health Campaign: enforce STARTTLS and verify MX certificates
> 
> ___
> Star us on GITHUB: https://github.com/LINBIT
> drbd-user mailing list
> drbd-user@lists.linbit.com
> https://lists.linbit.com/mailman/listinfo/drbd-user
>
___
Star us on GITHUB: https://github.com/LINBIT
drbd-user mailing list
drbd-user@lists.linbit.com
https://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] Proxmox with Linstor: Online migration / disk move problem

[G. Milo]

I was able to reproduce this issue on PVE 6.4 as well with the latest
packages installed. Never used this combination before, so I'm not sure if
it is something that started happening recently after updating PVE or
LINSTOR packages..The task is cancelled almost immediately, without
starting the migration process at all and the new linstor resource is
removed instantly as well.

https://pastebin.com/i4yuKYyp
___
Star us on GITHUB: https://github.com/LINBIT
drbd-user mailing list
drbd-user@lists.linbit.com
https://lists.linbit.com/mailman/listinfo/drbd-user

Re: [DRBD-user] Proxmox with Linstor: Online migration / disk move problem

[G. Milo]

Just in case it helps, I did some additional tests and the issue for me
seems to be narrowed down to the following...

Migration (online) from Local LVM/ZFS/DIR to ZFS backed LINSTOR storage
always succeeds, so the problem appears to be isolated when migrating from
local to a ThinLVM based LINSTOR storage.

On Thu, 25 Nov 2021 at 10:23, Roland Kammerer 
wrote:

> On Thu, Nov 25, 2021 at 08:57:45AM +0100, Roland Kammerer wrote:
> > On Wed, Nov 24, 2021 at 02:00:38PM +, G. Milo wrote:
> > > I was able to reproduce this issue on PVE 6.4 as well with the latest
> > > packages installed. Never used this combination before, so I'm not
> sure if
> > > it is something that started happening recently after updating PVE or
> > > LINSTOR packages..The task is cancelled almost immediately, without
> > > starting the migration process at all and the new linstor resource is
> > > removed instantly as well.
> > >
> > > https://pastebin.com/i4yuKYyp
> >
> > okay... so what do we have:
> > - it can happen from local lvm (Łukasz) and local zfs (Milo)
> > - it can happen with about 32G (Łukasz) and smaller 11G (Milo)
> >
> > Milo, as you seem to be able to reproduce it immediately, can you try
> > smaller volumes, like 2G? Does it happen with those as well?
> >
> > Does it need to be a running VM, or can it happen if the VM is turned
> > off as well?
> >
> > I will try to reproduce that later today/tomorrow, all information that
> > narrows that down a bit might help.
>
> I reproduced it (1G alpine image from local-lvm), let's see what I can
> find out, currently I don't need input from your side.
>
> Thanks, rck
> ___
> Star us on GITHUB: https://github.com/LINBIT
> drbd-user mailing list
> drbd-user@lists.linbit.com
> https://lists.linbit.com/mailman/listinfo/drbd-user
>
___
Star us on GITHUB: https://github.com/LINBIT
drbd-user mailing list
drbd-user@lists.linbit.com
https://lists.linbit.com/mailman/listinfo/drbd-user