File README.issues_solved of Package suse-migration-test-vm-12

The change on the DMS design from an extra booted live system
into a container based approach on the same system solves the
following issues:

1. No black out period due to an extra boot process in the cloud.
   Access to the system via ssh or locally stays active

2. No change on the system bootloader setup, no reset of that
   change, no issues on kexec as it's no longer used

3. No access issues to see /var/log/distro_migration.log because
   we stay on the same system

4. No need for pre-checks because we stay on the same system,
   we start the process, can debug/adapt and repeat until
   success

5. No need for packaging a live ISO image into an RPM package.
   The migration container will be fetched from the SUSE registry
   and can also be updated there.

6. No conflicts on system mount due to special layouts, e.g LVM
   because we stay on the system, no mount service needed at all

7. No network conflicts when setting up the network in the live
   system. We stay on the system and use the network as it is already
   present. No network setup service needed at all

8. No extra grub config and or initrd setup needed. We stay on
   the same system, thus the package update scripts will work
   and produce correct bootloader and host based initrd

9. No cloud specific limitations. The concept would work as a
   general solution. Thus following DP's Mission and Vision :)

10. No system outage during upgrade. We stay on the same system
    while it upgrades. Of course running services could be influenced
    depending on how resilient they are when data gets moved under
    the hood