similar to: Rollback to running VM

On 9/19/2017 9:56 AM, Martin Kletzander wrote: > On Tue, Sep 19, 2017 at 01:28:45PM +0000, Jackson, Gary L. wrote: >> >> I would like to make a snapshot of a running VM, let it continue to run >> after the shapshot, and then at some later time roll back the VM to >> that previous running state. Can I do that with libvirt? If so, how? I >> understand that this will

Will snapshot-revert restore the processor and memory state of the VM as it was at the time of the snapshot? -- Gary Jackson On 9/19/17, 11:10 AM, "libvirt-users-bounces@redhat.com on behalf of Doug Hughes" <libvirt-users-bounces@redhat.com on behalf of doug.hughes@keystonenap.com> wrote: On 9/19/2017 9:56 AM, Martin Kletzander wrote: > On Tue, Sep 19, 2017

On Tue, Sep 19, 2017 at 01:28:45PM +0000, Jackson, Gary L. wrote: > >I would like to make a snapshot of a running VM, let it continue to run >after the shapshot, and then at some later time roll back the VM to >that previous running state. Can I do that with libvirt? If so, how? I >understand that this will cause all kinds of havoc with things like >ongoing TCP connections, and I

Thanks! The vanilla snapshot-create-as and revert commands work just exactly the way I’d want them to. I’d gotten a bit confused by the documentation and went down a rabbit hole with external snapshots. Is there any way to make the snapshot and restore faster, like maybe by a decimal order of magnitude? For example, will PXE booting the VM and running it entirely off of a RAM disk and also using

I thought I recalled reading somewhere that in the situation where you have several zfs filesystems under one top level directory like this: rpool rpool/ROOT/osol-112 rpool/export rpool/export/home rpool/export/home/reader you could do a shapshot encompassing everything below zpool instead of having to do it at each level. (Maybe it was in a dream...)

My question is this: If you have an ongoing blockcopy (drive-mirror) of a running transient VM, and the VM kernel panics, can you restart the VM without interrupting the ongoing blockcopy? A virsh reboot won't work since if the VM is kernel panicked, its not going to respond to ACPI requests.

Hi everyone! I use the libvirt(version: 1.2.2) and QEMU(version: 2.2.1) to test qemu snapshot features: I tried virsh blockcommit when VM offline, the virsh blockcommit failed: the error messase as below: error: Requested operation is not valid: domain is not running when I start the VM, the virsh blockcommit work fine! my question is：we need

Hi. I'm following here a conversation that was initiated on Kashyap's website [1]. We have a server we use as a host for virtual machines using KVM (virt-manager used for VM creation) and we would like to setup VM backups. Basically, we're thinking of a backup schedule like "keep 7 daily and 4 weekly backups". We'd rather not shutdown the VM every day so live backups

I have an automatic process setup. It's still pretty new and obviously in need of better error handling because now I find myself in a bad state. I run snapshot-create-as across all my vms, then do zfs replication to the target backup system, then blockcommit everything. virsh snapshot-create-as --domain $vm snap --diskspec $DISK,file=$VMPREFIX/"$vm"-snap.qcow2 --disk-only --atomic

Hi Kashyap Chamarthy: thank you very much for answer my question: 一： lead to VM filesystem becoming read-only 1： test case it lead to VM filesystem becoming read-only test case as follows: we want to snapshot for VM , to obtain VM incremental data，and use virsh blockcommit，qemu-img commit，qemu-img rebase to shorten snapshot chain. Details are as follows（when VM running state， we perform the

Hi, Recently We've upgraded some KVM hosts from Fedora 29 to Fedora 30 and now experience broken VM configurations on filesystem after virsh blockcommit. Commands "virsh dumpxml ..." and "virsh dumpxml --inactive ..." is showing diffrent configuration than the one on filesystem. In case of restart libvirtd or system reboot, there are broken VM xml configurations on

Hi Eric. Thank you so much for your quick and relieving answer. Le 2015-09-11 17:05, Eric Blake a écrit : > Yes, using active block-commit is the ideal way to perform a live backup. Great. > Yep, that about covers it. Note that the --quiesce step in snapshot > creation requires qemu-guest-agent running in the guest, and that you > trust interaction with your guest. Yes, I think

Hello all, I was wondering if there is an existing mechanism in Xen for restoring a saved/checkpointed VM lazily. By that, I mean that the pages of the VM should be mapped only on access. Currently, restoring a VM from a snapshot seems to take a long time [~20 seconds for 2 GB]. Assuming that there is no lazy-restore functionality, what would be a good way to implement this? Using parts

See MAINTAINERS file Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu> diff --git a/MAINTAINERS b/MAINTAINERS index 094fe9e..f562efa 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -261,6 +261,21 @@ S: Supported F: tools/xentrace/ F: xen/common/trace.c +VTPM +M: Matthew Fioravante <matthew.fioravante@jhuapl.edu> +S: Supported +F: tools/vtpm +F:

> -----Oorspronkelijk bericht----- > Van: Lentes, Bernd [mailto:bernd.lentes@helmholtz-muenchen.de] > Verzonden: donderdag 3 december 2015 13:54 > Aan: libvirt-ML > CC: Dominique Ramaekers > Onderwerp: RE: snapshot of running vm's > > > ... > > > > > > Hi, > > > > > > i have inserted: > > > > > > <channel

Hi all, I'm investigating the ways to improve the live migration performance in libvirt. I have a question about the vm live storage migration. the platform is libvirt + qemu + kvm If we want to migrate a running vm with its virtual disk images to another node. we can use 'virsh migrate ....' commands. What if this vm has a number of disk-only external snapshots? In the current

Hi, currently i'm following https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit. I 'm playing around with it and it seems to be quite nice. What i want is a daily consistent backup of my image file of the guest. I have the idea of the following procedure: - Shutdown the guest (i can live with a downtime of a few minutes, it will happen in the night). And i think

You've answered my question 2 about why the manual was in odd order > R CMD check was more of a check of the latex version of the files, not > the final manual. I was looking at the result of R CMD check, and it was in random order (perhaps file date?), not just a different collation choice. Very odd. I will cease worrying about what I might have "done wrong". I omitted the