On Wed, Feb 22, 2017 at 11:45 AM, Gianluca Cecchi
<gianluca.cec...@gmail.com> wrote:
> On Wed, Feb 22, 2017 at 9:56 AM, Nir Soffer <nsof...@redhat.com> wrote:
>> Gianluca, what is domain 900b1853-e192-4661-a0f9-7c7c396f6f49?
>> is this the domain you are migrating to in the same time?
> That was the id of the storage domain created on the LUN with problems at
> storage array level.

This explains sanlock issues with this domain.

> It only contained one disk of a VM. I was able to previously move other 2
> disks I had on it to another storage domain
> The disk was a data disk of a VM; its system disk was on another storage
> domain without problems
> The order of my operations yesterday was:
> - try move disk to another storge domain-> failure in auto snapshot
> - try snapshot of VM selecting both disks --> failure

The first step in moving disk to another domain when the vm is online,
is creating a snapshot on old storage.

Then we start mirroring process of the active (empty) snapshot
to the destination storage domain.

Then we copy the rest of the chain (readonly) to the destination
storage domain.

Finally we switch the active layer to the snapshot on the destination
storage domain, and delete the old chain on the source domain.

If the source storage is broken you have to stop the vm to move the
disk. This is can also fail if we cannot read the disk from this storage.

Lesson, use only storage without problems ;-)

> - try snapshot of VM selecting only the system disk (the good one) --> ok
> and also snapshot deletion ok
> - try snapshot of VM selecting only the data disk --> failure
> - hot add disk (in a good storage domain) to the VM --> OK
> - try pvmove at VM OS level from problematic disk to new disk --> failure:
> VM paused at 47% of pvmove and not able to continue
> - power off VM --> OK
> - remove disk from VM and delete --> OK
> Only at this point, with storage domain empty, I started to work on storage
> domain itself, putting it to maintenance and removing it without problems;
> and then the related LUN removal at host level with the notes described in
> other thread
>> Can you share the output of:
>>     sanlock client renewal -s 900b1853-e192-4661-a0f9-7c7c396f6f49
> No, the storage domain has been removed

Next time when you have storage issues, please remember to grab
the output of this command.

Users mailing list

Reply via email to