Project

General

Profile

Actions

action #130922

closed

Provide a way to get a VM snapshot at a certain step size:M

Added by jsegitz 11 months ago. Updated 9 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Feature requests
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Motivation

for SELinux testing I need to get the system into a state that is equivalent to a certain openQA
state to allow me to do manual testing. Is there a way to get openQA to provide me a snapshot of
a VM at a certain step in openQA testing? If not: Is that something that can be added as a feature?
That would save me (and probably others) a lot of time

Suggestions

  • Refresh the knowledge about "openQA snapshots"
  • Try out if that currently works and what is the best option right now what to do
  • Consider extending the openQA documentation accordingly as required
  • Create new feature requests where necessary for missing parts

Further details

Related os-autoinst feature pull request https://github.com/os-autoinst/os-autoinst/pull/1543 "Support FORCE_PUBLISH_HDD_ when the job fails"

Actions #1

Updated by szarate 11 months ago

  • Project changed from 46 to openQA Project
  • Description updated (diff)

I think we already do this, Johannes, in your use case, would you like to be able to connect to the running machine? or you would prefer to download the qcow2 and then later run it locally?

Actions #2

Updated by okurz 11 months ago

  • Category set to Support
  • Target version set to Ready
Actions #3

Updated by jsegitz 11 months ago

awesome :) Connecting to the machine is fine. Downloading the qcow2 would be better, but if I can hook in in any way at a certain step this would already be 95%

Actions #4

Updated by okurz 10 months ago

  • Subject changed from Provide a way to get a VM snapshot at a certain step to Provide a way to get a VM snapshot at a certain step size:M
  • Description updated (diff)
  • Status changed from New to Workable
  • Priority changed from Normal to High
Actions #5

Updated by osukup 10 months ago

https://github.com/os-autoinst/os-autoinst/blob/master/testapi.pm#LL1927C1-L1927C1 -- save_storage_drives can be way , but now is limited to post_fail_hook .. because it needs stopped VM

so for export drivers we need add ability to stop VM , then save drives and then resume run ..

Actions #6

Updated by osukup 10 months ago

so after some testing --> save_storage_drives ins't used by test code anywhere in our codebases and probably it also never worked, even inside post_fail_hook call as qemu-image convert command needs to be on unlocked image, so only after VM itself is destroyed ...

the current workaround for this feature request is:

  • change test to stop in required step ( in own instance, add die or change schedule)
  • clone job with FORCE_PUBLISH_HDD.. and PUBLISH_HDD_.. defined
  • profit...
Actions #7

Updated by okurz 10 months ago

Ok, sounds like you can try to come up with a proof of concept in os-autoinst-distri-opensuse or a plain new test distribution for experimentation and then we can decide what to put as convenience functions into os-autoinst

Actions #8

Updated by osukup 10 months ago

  • Status changed from Workable to In Progress
  • Assignee set to osukup

the current implementation is incorrect so we can resolve this with the removal of non-functional code and new poo for feature request.

this link should be the inspiration base for feature request implementation:
--> https://www.qemu.org/docs/master/interop/live-block-operations.html#id20

Actions #9

Updated by openqa_review 10 months ago

  • Due date set to 2023-07-07

Setting due date based on mean cycle time of SUSE QE Tools

Actions #11

Updated by okurz 10 months ago

Actions #12

Updated by okurz 10 months ago

  • Status changed from In Progress to Workable

This is effectively not in progress right now

Actions #13

Updated by livdywan 10 months ago

  • Due date deleted (2023-07-07)

okurz wrote:

This is effectively not in progress right now

Ack. Also resetting the due date. Let's discuss next week.

Actions #14

Updated by livdywan 10 months ago

  • Category changed from Support to Feature requests
  • Status changed from Workable to In Progress

We should be able to test this tomorrow. As we were briefly discussing it on the call I'm taking notes on the list of what we want to achieve in the end:

  • backup of discs
  • qemu docs are a bit lacking, extend openQA docs
  • re-introduce test api (which used to exist but never worked)
  • ensure we have unit test and/or integration tests proving that it works this time

Ok, sounds like you can try to come up with a proof of concept in os-autoinst-distri-opensuse or a plain new test distribution for experimentation and then we can decide what to put as convenience functions into os-autoinst

As I understand we need to have this in os-autoinst. It's not about "convenience". I guess that wasn't clear before.

Actions #15

Updated by openqa_review 10 months ago

  • Due date set to 2023-07-25

Setting due date based on mean cycle time of SUSE QE Tools

Actions #17

Updated by osukup 10 months ago

logs from test instance:

[2023-07-12T00:07:13.292633+02:00] [info] Uploading hd0-overlay0-openqa_webui.qcow2
[2023-07-12T00:08:21.518106+02:00] [info] Uploading hd0-overlay0-test_distribution.qcow2
[2023-07-12T00:09:31.629338+02:00] [info] Uploading hd0-overlay1-start_test.qcow2
[2023-07-12T00:10:47.539528+02:00] [info] Uploading video.ogv
[2023-07-12T00:10:47.939465+02:00] [info] Uploading vars.json
[2023-07-12T00:10:47.954035+02:00] [info] Uploading autoinst-log.txt

log looks good, but in the log & assets page are qcow2 missing and only an empty file named file appears ... ( problem with upload_logs for big files? )

interesting if test fails, upload passes ...

Actions #18

Updated by okurz 10 months ago

Not sure, check the worker log?

Actions #19

Updated by osukup 10 months ago

[2023-07-12T12:39:21.841528+02:00] [info] Registered and connected via websockets with openQA host http://quasar.suse.cz and worker ID 3
[2023-07-12T12:39:37.851435+02:00] [warn] Error uploading hd0-overlay0-openqa_webui.qcow2: Connection error: Premature connection close
[2023-07-12T12:39:42.851874+02:00] [warn] Uploading artefact hd0-overlay0-openqa_webui.qcow2 (attempts remaining: 59/60)
[2023-07-12T12:39:42.874359+02:00] [info] Uploading hd0-overlay0-test_distribution.qcow2
[2023-07-12T12:40:21.857073+02:00] [warn] Websocket connection to http://quasar.suse.cz/api/v1/ws/3 finished by remote side with code 1006, no reason - trying again in 10 seconds
[2023-07-12T12:40:31.885581+02:00] [info] Registering with openQA http://quasar.suse.cz
[2023-07-12T12:40:31.922453+02:00] [info] Establishing ws connection via ws://quasar.suse.cz/api/v1/ws/3
[2023-07-12T12:40:31.927225+02:00] [info] Registered and connected via websockets with openQA host http://quasar.suse.cz and worker ID 3
[2023-07-12T12:40:45.791320+02:00] [warn] Error uploading hd0-overlay0-test_distribution.qcow2: Connection error: Premature connection close
[2023-07-12T12:40:50.791726+02:00] [warn] Uploading artefact hd0-overlay0-test_distribution.qcow2 (attempts remaining: 59/60)
[2023-07-12T12:40:50.813342+02:00] [info] Uploading hd0-overlay1-start_test.qcow2
Actions #20

Updated by osukup 10 months ago

so ... upload from ulogs is using _upload_log_file which is more fragile than _upload_assets for big files ... because assets use chunks and have local instance optimization.

Actions #21

Updated by osukup 10 months ago

result qcow2 moved to assets_public which looks working without any problems , now .. discuss and add timeout into wait loop and docu + tests

Actions #22

Updated by osukup 9 months ago

ah, we probably don't want backup mounted CD :D

Actions #23

Updated by livdywan 9 months ago

  • Due date deleted (2023-07-25)
  • Status changed from In Progress to Workable
  • Assignee deleted (osukup)
  • Start date deleted (2023-06-15)

I believe someone forgot to unassign on account of being unavailable this week 😼

The draft is still open which is why I didn't put this in Feedback https://github.com/os-autoinst/os-autoinst/pull/2341

Actions #24

Updated by AdamWill 9 months ago

@osukup historical note: it is likely not correct to say save_storage_drives "never worked". It was added in 2016. I think the lock stuff that you ran into when trying it was added in qemu 2.10, in September 2017. So this stuff probably "worked" (though...I would expect it was pretty dicey...) for a while.

(no, don't worry, Fedora isn't using it for anything, just thought I'd mention it!)

Actions #25

Updated by livdywan 9 months ago

  • Status changed from Workable to Feedback
  • Assignee set to osukup

livdywan wrote:

I believe someone forgot to unassign on account of being unavailable this week 😼

The draft is still open which is why I didn't put this in Feedback https://github.com/os-autoinst/os-autoinst/pull/2341

Updated and merged!

Actions #26

Updated by jsegitz 9 months ago

you're all really awesome! That will save so much time. Do you know when this will be available?

Actions #27

Updated by okurz 9 months ago

jsegitz wrote:

you're all really awesome! That will save so much time. Do you know when this will be available?

The package is available and already updated in https://build.opensuse.org/package/show/devel:openQA/os-autoinst . Expect it to reach Tumbleweed in 2-3 days.

https://progress.opensuse.org/projects/openqav3/wiki/Wiki#Automatic-update-of-o3 describes our deployment strategy for https://openqa.opensuse.org . If you need it on OSD the deployment is daily, controlled in https://gitlab.suse.de/openqa/osd-deployment/-/pipelines

Actions #28

Updated by livdywan 9 months ago

  • Status changed from Feedback to Resolved

I assume we're good here - @jsegitz of course feel free to ask in the usual channels if you have any questions or file a follow-up ticket as necessary.

Actions

Also available in: Atom PDF