coordination #40058
open
[EPIC] Store VM state when reusing published image
Added by riafarov over 5 years ago.
Updated over 3 years ago.
Category:
Feature requests
Description
Motivation¶
When we boot into the image, we suppose to have user use-case when customer simply starts machine with installed system. However, currently we do it in a way that is more like taking HDD drive, getting new server and plug it in, so some things, like device ids do not match. For many scenarios it's not supported by the installer.
As of now we have to introduce workaround other users would have to do when the move HDD to new server. However, we should test scenario with same hardware setup.
To break any scenario with multiple HDDs, it's enough to switch HDD_1 with HDD_2.
Suggestions¶
We could start using libvirt to manage VMs, and use virt-clone to get to the same state, which will be stored in xml files by hypervisor.
- Subject changed from [tools] Use guest xml to clone VM sintead of creating new VM and attaching cloned disk to [tools] Use guest xml to clone VM instead of creating new VM and attaching cloned disk
- Subject changed from [tools] Use guest xml to clone VM instead of creating new VM and attaching cloned disk to [tools] Store VM state when reusing published image
- Subject changed from [tools] Store VM state when reusing published image to [EPIC] Store VM state when reusing published image
- Related to action #42677: Keep virtual machines running on demand/failure (was: Don't just power off virtual machines upon job timeout) added
- Related to coordination #41045: [EPIC] Offer publishing a snapshotted qcow from developer mode added
- Priority changed from Normal to Low
- Target version set to future
Considering other systems: in many cases booting is cleaner and especially for VMs is fast, in most cases comparable to loading a system state which also takes time, which we can see when os-autoinst reverts to a snapshot. I merely see the use case when services on top of the OS take long to initialize but this is not something I commonly see in our tests. The use case is still valid but IMHO low pro
- Tracker changed from action to coordination
Also available in: Atom
PDF