coordination #40058: [EPIC] Store VM state when reusing published image - openQA Project (public) - openSUSE Project Management Tool

Actions

Copy link

coordination #40058

open

[EPIC] Store VM state when reusing published image

Added by riafarov over 6 years ago. Updated about 4 years ago.

Status:

New

Priority:

Low

Assignee:

Category:

Feature requests

Target version:

QA (public) - future

Start date:

2018-08-21

Due date:

% Done:

Estimated time:

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 2 (0 open — 2 closed)

Actions

Copy link

Updated by riafarov over 6 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

Actions

Copy link

Updated by riafarov over 6 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

Actions

Copy link

Updated by coolo over 6 years ago

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

Actions

Copy link

Updated by okurz about 5 years ago

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

Actions

Copy link

Updated by okurz almost 5 years ago

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

Actions

Copy link

Updated by okurz over 4 years 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

Actions

Copy link