Project

General

Profile

coordination #40058

[EPIC] Store VM state when reusing published image

Added by riafarov almost 3 years ago. Updated 10 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Feature requests
Target version:
Start date:
2018-08-21
Due date:
% Done:

0%

Estimated time:
Difficulty:

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.


Related issues

Related to openQA Project - action #42677: Keep virtual machines running on demand/failure (was: Don't just power off virtual machines upon job timeout)Rejected2018-10-18

Related to openQA Project - coordination #41045: [EPIC] Offer publishing a snapshotted qcow from developer modeRejected2018-09-14

History

#1 Updated by riafarov almost 3 years ago

  • 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

#2 Updated by riafarov almost 3 years ago

  • 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

#3 Updated by coolo almost 3 years ago

  • Subject changed from [tools] Store VM state when reusing published image to [EPIC] Store VM state when reusing published image

#4 Updated by okurz over 1 year ago

  • Related to action #42677: Keep virtual machines running on demand/failure (was: Don't just power off virtual machines upon job timeout) added

#5 Updated by okurz over 1 year ago

  • Related to coordination #41045: [EPIC] Offer publishing a snapshotted qcow from developer mode added

#6 Updated by okurz about 1 year ago

  • 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

#7 Updated by szarate 10 months ago

  • Tracker changed from action to coordination

Also available in: Atom PDF