Triggering a checkpoint from inside the VM

Leek, Jim leek2 at llnl.gov
Thu Sep 9 08:31:58 UTC 2021


I’ll try snapshot create, I didn’t know about that.

I understand your security concerns, but they don’t apply in this case. The target environment is air gapped and isolated. I can’t see any reason to fear an attack on the VM before an attack on the host.

2. Well, I was experimenting with getting libvirt out of the system to simplify things, but I didn’t have much luck yet.


---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>

On September 9, 2021 at 1:20:38 AM PDT, Daniel P. Berrangé <berrange at redhat.com> wrote:
On Wed, Sep 08, 2021 at 04:22:31AM +0000, Leek, Jim wrote:
> I'm on a RHEL 8 host, using virt-manager to run a CentOS 8 guest.  I need
> to be able to have a program on the guest trigger a checkpoint to save
> the guest.  I came up with a kludgy way to do this involving a script
> that ssh's to the host and runs 'virsh qemu-monitor-command --hmp
> centos8_1 "savevm savestate1"' and that works to some degree, but it
> takes a long time and sometimes I get an error.

This is a bad idea.

"savevm" completely stops execution of the guest for the duration
that it runs.....so your ssh conenction is suspended. Depending
on how long this takes, your ssh connection may take some time to
recover, or in the worst case fail.

Using qemu-monitor-command is not neccessary because libvirt already
has support for savevm via its domain snapshot APIs epxosed in virsh
using snapshot-* commands. Using qemu-monitor-command in this case
is likely to confuse libvirt because it is resulting in unexpected
state changes in the guest.

Allowing the guest to ssh into the host and connect to libvirt
throws away any security isolation your host has from the guest.
So if your guest is compromised it'll easily take over the host
too.

> So, I'm trying to think of ways to simplify the system.  If anyone has any ideas, I would love to have them.  All I can think of is:
>
>   1.  Connect to the qemu monitor with telnet from inside the VM.  (Therefore skipping the whole ssh remote command thing.)

Definitely don't want todo that - access to the QEMU monitor
again allows guest to attack the host in various ways. If
libvirt is connected to the QEMU monitor, you can't have a
second connection anyway.

Regards,
Daniel
--
|: https://urldefense.us/v3/__https://berrange.com__;!!G2kpM7uM-TzIFchu!lFVFSs5C2w6Vt5mss2OePJAnR8QGxohw4OvKhWVxKNwxttCUfPD5f7tPKtVgtmY$       -o-    https://urldefense.us/v3/__https://www.flickr.com/photos/dberrange__;!!G2kpM7uM-TzIFchu!lFVFSs5C2w6Vt5mss2OePJAnR8QGxohw4OvKhWVxKNwxttCUfPD5f7tPzRsfC3g$  :|
|: https://urldefense.us/v3/__https://libvirt.org__;!!G2kpM7uM-TzIFchu!lFVFSs5C2w6Vt5mss2OePJAnR8QGxohw4OvKhWVxKNwxttCUfPD5f7tPsx80x1w$          -o-            https://urldefense.us/v3/__https://fstop138.berrange.com__;!!G2kpM7uM-TzIFchu!lFVFSs5C2w6Vt5mss2OePJAnR8QGxohw4OvKhWVxKNwxttCUfPD5f7tPsGUnCCQ$  :|
|: https://urldefense.us/v3/__https://entangle-photo.org__;!!G2kpM7uM-TzIFchu!lFVFSs5C2w6Vt5mss2OePJAnR8QGxohw4OvKhWVxKNwxttCUfPD5f7tPTFrwcL0$     -o-    https://urldefense.us/v3/__https://www.instagram.com/dberrange__;!!G2kpM7uM-TzIFchu!lFVFSs5C2w6Vt5mss2OePJAnR8QGxohw4OvKhWVxKNwxttCUfPD5f7tPe1eBb0E$  :|

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20210909/e834fbf9/attachment.htm>


More information about the virt-tools-list mailing list