QA » openQA Project

I have new block device object model working under various scenarios including multipath. I have implemented saving external snapshots, but still need to implement loading them which requires restarting QEMU.

@rpalethorpe do you think that this manager class will help to be more flexible in multi-nic scenarios? See this comment for needed specs: https://progress.opensuse.org/issues/32959#note-3

If NICs, switches, routers etc. need to be added and removed during testing then yes, definitely. If not, then it will still be useful for better code organisation, but so far I have not touched networking. It doesn't appear that network devices can be added or removed during a test, or that the VLAN needs to be restarted with QEMU, so there is no state to revert during a snapshot. The current task is to move devices to the object model which have state (i.e. block devices which are added during a snapshot) or are closely related to devices with state.

rpalethorpe wrote:

If NICs, switches, routers etc. need to be added and removed during testing then yes, definitely. If not, then it will still be useful for better code organisation, but so far I have not touched networking. It doesn't appear that network devices can be added or removed during a test, or that the VLAN needs to be restarted with QEMU, so there is no state to revert during a snapshot. The current task is to move devices to the object model which have state (i.e. block devices which are added during a snapshot) or are closely related to devices with state.

Ok. Thanks for the clarification. At least, at a first glance it sounds like a solution. For the case I mentioned, we would need the network devices pre-setup before running the test, not during execution. Although that would be a nice feature for fail-over scenarios (maybe future)

status update: It can now restart QEMU and load an external snapshot: http://rpws.suse.cz/tests/170#

I'm surprised the code which rolls back the consoles after a snapshot has ever worked. It seems that if you activate consoles A then B, take a snapshot then active A, then load the snapshot, console A will still be selected even though console B was active at the time of the snapshot. In fact even if you activate console A, take a snapshot, then active console B, then revert to the snapshot, console B will be selected, although it will get 'reset'. However console A should be active. Probably this has not been noticeable because tests haven't mixed consoles much, but it is becoming more common.

AFAICT I have fixed that problem, but there is another issue. Consoles may have state which needs to be saved and restored during a snapshot. The only instance of this I have thought of so far is the virtio_console, which should save whatever 'unread' data qemu has output at the time of the snapshot. E.g. in the link above all there are a lot of non fatal failures after each snapshot because the test module expects '#', but this has already been consumed before the snapshot was loaded. The same problem will exist with other serial terminal consoles, but I don't think it is a problem for VNC. Note that this is not a problem with restarting QEMU, it is an existing problem in the current version of os-autoinst.

Finally the way we manage the QEMU process has a few race conditions, so I have incorporated some of Ettorie's changes so that we don't just instantly fail when a socket has not been created yet. Also we should probably start using the Mojo process management libraries.

I have a collection of other TODO's as well but at least the concept is fully proven now. It appears that the new method either works with virtio GPU's or QEMU now supports it in all cases as I was able to use snapshots with it enabled.

I made a PR to make it more visible: https://github.com/os-autoinst/os-autoinst/pull/942

Implemented snapshots for the virtio console so that the expected output is restored after a snapshot.

I have added the pflash vars to the OpenSUSE instance. Anton says that I should set the var inside main.pm instead. It should be quite easy to remove the vars if we decided to do that instead.

Please note that we haven't deployed yet :)