Require extra 8 GiB free space on the destination Storage Domain in the LSM flows

[barpavel]

Update Live Storage Migration flow validation to require additional 3 chunks (approximately 8 GiB) of free space on the destination Storage Domain.

Bug-Url: https://bugzilla.redhat.com/2116309

[barpavel]

@bennyz @ahadas
IMHO the whole LiveMigrateDiskCommand::validateDestDomainsSpaceRequirements() can be removed, since MoveOrCopyDiskCommand::validateSpaceRequirements() runs on both source & destination Storage Domains and checks both isDomainWithinThresholds() and Storage Domains available space.

I already removed isDomainWithinThresholds() check above, since it's exactly what the MoveOrCopyDiskCommand::validateSpaceRequirements() does (for both source and destination SDs).

But I want to be careful and be sure before I remove the rest of the method, there are 2 slight differences between what MoveOrCopyDiskCommand::validateSpaceRequirements() performs on both source and destination SDs and what this method does on destination only:

1. In the MoveOrCopyDiskCommand::validateSpaceRequirements(), the DiskImage that is used to retrieve the snapshots is initialized using a getImage() call, that uses the CopyImageGroupCommand::getImage() implementation:
   

   ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/disk/image/CopyImageGroupCommand.java

   Line 91 in b54471d

   protected DiskImage getImage() {

   
   While in LiveMigrateDiskCommand::validateDestDomainsSpaceRequirements() the getDiskImageByImageId() is called:
   

   ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/lsm/LiveMigrateDiskCommand.java

   Line 674 in b54471d

   private DiskImage getDiskImageByImageId(Guid imageId) {

   
   But at the end it looks like they are returning pretty much the same diskImageDao.get(imageId);...

2. In the MoveOrCopyDiskCommand::validateSpaceRequirements(), the available free space validation is performed by the hasSpaceForDisksWithSnapshots():
   

   ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/validator/storage/StorageDomainValidator.java

   Line 245 in b54471d

   public ValidationResult hasSpaceForDisksWithSnapshots(Collection<DiskImage> diskImages) {

While in LiveMigrateDiskCommand::validateDestDomainsSpaceRequirements() the hasSpaceForClonedDisks() is called:

ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/validator/storage/StorageDomainValidator.java

Line 222 in b54471d

public ValidationResult hasSpaceForClonedDisks(Collection<DiskImage> diskImages) {

Trying to compare them very carefully, I see they are almost the same with very minor nuances, and though maybe both methods need to stay, but anyway, in current implementation both are called and I don't think that we should verify in 2 different ways the same disk & target domain to allow Live Migration.
So which version is correct? The one in LiveMigrateDiskCommand::validateDestDomainsSpaceRequirements() or the MoveOrCopyDiskCommand::validateSpaceRequirements()?

[ahadas]

yeah, they are similar yet different as you pointed out. I guess the validation in LiveMigrateDiskCommand should stay, but need to take a deeper look at the differences. @bennyz can you answer this from the top of you head? :)

[barpavel]

@bennyz is there some code that can be united - moved to the MoveOrCopyDiskCommand base class?
For me it looks like LiveMigrateDiskCommand::validateDestDomainsSpaceRequirements() is redundant, but there are 2 slight potential differences.

1. The way how DiskImage, used to retrieve the snapshots, is retrieved.
2. hasSpaceForDisksWithSnapshots vs. hasSpaceForClonedDisks(), that are currently used both to test the destination SD free space, and I added 3 chunks' addition only to one of them.

[barpavel]

/ost

[barpavel]

/ost

[barpavel]

/ost

[bennyz]

@barpavel can you please keep only the parts crucial for the fix? there are far too many changes here for what is actually needed

[barpavel]

This PR was verified in the following scenarios.

1. LSM - verified that extra 3 chunks (7.5 GiB) are required on the destination SD for LSM flow only. And if not exist, the LSM process doesn't even start - failing during validation phase.
2. Disk not attached to any VM / attached to a non-running VM - same behavior as before.

There are a few open question (above). The code refactoring that I did "on the way" allows to improve some old code, or even remove current duplicate checks.
I.e., double check for available space on destination SD using slightly different methods to calculate the "required size" and only in 1 of the checks (the one in LiveMigrateDiskCommand class) requires the extra 3 chunks.

[bennyz]

/ost