weizhouapache commented on PR #14426:
URL: https://github.com/apache/cloudstack/pull/14426#issuecomment-6268017180
> I don't have a Ceph test env at the moment. CCC is coming up in November,
can you give me a demo there so we can verify this together? Would love to see
it live.
sure @wido
Actually many cases are covered by a smoke test introduced in this PR:
`test_volume_migration_rbd_nfs.py`
### Coverage
14 tests in two classes: `TestVolumeMigrationRbdNfs` and
`TestEncryptedVolumeMigrationRbdNfs` run the same seven scenarios, the second
one with encrypted ROOT and DATA volumes.
| # | Scenario |
| --- | --- |
| 01 | Online: RBD (ROOT with chain) -> NFS -> NFS -> RBD -> RBD |
| 02 | Online: NFS (ROOT with chain) -> RBD |
| 03 | Online: NFS -> NFS is refused, as both pools are file based |
| 04 | Offline: RBD (ROOT with chain) -> NFS -> NFS -> RBD -> RBD |
| 05 | Offline: NFS (ROOT with chain) -> RBD |
| 06 | Offline: NFS (ROOT with chain) -> NFS |
| 07 | Detached DATA volume: RBD -> NFS -> NFS -> RBD -> RBD |
A refused hop asserts the message of the check that answers it, the live
migration one or the encrypted volume one, rather than any failure.
### What is verified after every migration
Every hop is verified twice: right after the migration, and once more after
the
Instance has been stopped and started again, so that a volume which is still
open in the running domain but is no longer usable from its recorded format
is
caught as well.
- the volume is on the destination pool and is `Ready`, and the Instance is
`Running`
- the pattern written to the DATA volume before the first migration is still
readable at the same offset, and the checksum of the boot area of the ROOT
volume is unchanged. Both are read through the disk of the running domain,
as
the Instance sees them, so an encrypted volume is read decrypted and
through
qemu rather than as a file on the pool
- for an encrypted volume, the disk in the XML domain still carries its
encryption, with the scheme of the destination: `luks2` with the `librbd`
engine on an RBD pool, `luks` with another engine on a file based one
### Test results
Run on a nested Trillian environment: KVM, two management servers, two hosts,
two permanent RBD (Ceph) primary pools, and the NFS pools the suite creates
itself.
On the current branch tip:
| Test | Result |
| --- | --- |
| `test_volume_migration_rbd_nfs.py` | 14/14 OK (`Ran 14 tests in
7461.509s`) |
| `test_volumes.py`
`TestVolumeEncryption.test_04_encrypted_volume_migration_between_rbd_pools` |
1/1 OK (`Ran 1 test in 1056.071s`) |
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
