similar to: virsh can't support VM offline blockcommit

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

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

On Tue, Oct 13, 2015 at 10:39:58AM +0800, justlibvirt@gmail.com wrote: > Hi everyone! Hi, Firstly, please don't post the same message multiple times in a row. If someone hasn't responded, they're either busy, or haven't noticed this message. > I use the libvirt(version: 1.2.2) and QEMU(version: 2.2.1) to > test qemu snapshot features: > > I

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 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

On 09/11/2015 06:45 AM, Jérôme wrote: > AFAIU, live backups using libvirt may be done thanks to blockcommit as > explained here on the wiki [2]. > > -> Considering our use case, is this the recommended way? Yes, using active block-commit is the ideal way to perform a live backup. > > Assuming yes, here is the plan. > > I wrote a script that does > > #

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. 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

Dear Liam, You need to upgrade to the latest LTS version of Ubuntu (16.04). I refer to my message to this mailing list on 17/03/2016: Hi everybody, Following this user mailing list over a period of time, I saw a few messages regarding not being able using the external snapshot feature. I refer to this procedure: http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit I would

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

On Mon, Aug 14, 2017 at 08:42:24 +0200, Dominik Psenner wrote: > Hi, Hi, > > a small update on this. We have migrated the virtualized host to use the > virtio drivers and now the drive performance is improved so that we can see > a constant transfer rate. Before it used to be the same rate but regularly > dropped to a few bytes/sec for a few seconds and then was fast again.

hi, i am trying to blockcommit a external qcow2 snapshot back into its raw backing file like: sudo virsh blockcommit myDomainName vda --wait --verbose the output just shows: Block Commit: [100 %] and stays like that (i waited about an hour or so...). No "Commit complete" message. - explicitly passing --base and/or --top arguments makes no difference. - did not find a related log

Hi, I have another question, when I do the blockcommit command and get the result " Top image as the active layer is currently unsupported ", is it being developed? root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1;echo $? error: internal error unable to execute QEMU command 'block-commit': Top image as the active layer is currently unsupported 1 But as I

[dropping libvir-list - this is a usage question, not a development question] On 09/02/2013 11:29 PM, Guozhonghua wrote: > I had test the command virsh blockcommit, but it failed, with the libvirt version 1.1.0, and qemu version 1.6.0. > Is this feature being developing? Thanks The feature is supported, but you have to use it correctly. In particular, your backing chain MUST label the

On 09/03/2013 06:56 PM, Guozhonghua wrote: > Hi, > > I have another question, when I do the blockcommit command and get the result " Top image as the active layer is currently unsupported ", is it being developed? > root@cvk-31:/vms/images# virsh blockcommit Vmtest /vms/images/Vmtest1;echo $? > error: internal error unable to execute QEMU command 'block-commit':

I had test the command virsh blockcommit, but it failed, with the libvirt version 1.1.0, and qemu version 1.6.0. Is this feature being developing? Thanks root at cvk-31:/vms/images# virsh -v 1.1.0 root at cvk-31:/vms/images# qemu-img -V qemu-img version 1.6.0, Copyright (c) 2004-2008 Fabrice Bellard usage: qemu-img command [command options] root at cvk-31:/vms/images# virsh blockcommit Vmtest

Hi, a small update on this. We have migrated the virtualized host to use the virtio drivers and now the drive performance is improved so that we can see a constant transfer rate. Before it used to be the same rate but regularly dropped to a few bytes/sec for a few seconds and then was fast again. However we still observe that the following fails regularily: $ virsh snapshot-create-as --domain

On 09/11/2015 10:18 AM, Jérôme wrote: >> 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 I get this. I don't really figure out what these cases > could be. We're using Debian Jessie and I installed

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

On 09/07/2018 12:06 PM, Lentes, Bernd wrote: > 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