Morning, I have a KVM guest running Win 2012 with MS SQL 2012. In order to provide a quick method of restoring the service should the live server die, we've decided to clone it to a preserved state. Ideally, this clone should also be kept up to date and cloning should be done on a regular basis. Is there any reason not to do unattended cloning? As in, when I leave on a Friday afternoon, start a script to clone the guest and auto start the live guest? Thanks Adam King IT Systems Administrator
On Tue, Sep 16, 2014 at 08:19:36AM +0100, Adam King wrote:> Morning, > > I have a KVM guest running Win 2012 with MS SQL 2012. > In order to provide a quick method of restoring the service should the > live server die, we've decided to clone it to a preserved state. > Ideally, this clone should also be kept up to date and cloning should > be done on a regular basis. > > Is there any reason not to do unattended cloning? As in, when I leave > on a Friday afternoon, start a script to clone the guest and auto > start the live guest?I don't see why not. You can do live disk mirroring as below (untill you issue a graceful abort) . Maybe something like below (Eric or others will correct if I missed anything): You can invoke a live disk backup as below, which keeps on mirroring the disk content (untill you explicitly abort): $ virsh blockcopy --domain f20vm vda \ /export/dst/copy1.qcow2 \ --wait --verbose \ When you want to end the mirroring above, you can issue a graceful abort: $ virsh blockjob --domain f20vm vda \ --abort Then, script the `virsh` operations to create a libvirt XML and start the new guest with the copy of the disk image (/export/dst/copy1.qcow2) NOTE: You can also combine both the above (disk copy + abort) operations in one command (by providing the "--finish" flag): $ virsh blockcopy --domain f20vm vda \ /export/dst/copy1.qcow2 \ --wait --finish --verbose \ On a related note, if you want to take a live disk backup _and_ 'pivot' your live QEMU to that copy, you can try: $ virsh blockjob --domain f20vm vda \ /export/dst/copy1.qcow2 \ --wait --verbose --finish \ --pivot Hope that helps a bit. -- /kashyap
On 09/16/2014 01:19 AM, Adam King wrote:> Morning, > > I have a KVM guest running Win 2012 with MS SQL 2012. > In order to provide a quick method of restoring the service should the live server die, we've decided to clone it to a preserved state. > Ideally, this clone should also be kept up to date and cloning should be done on a regular basis. > > Is there any reason not to do unattended cloning? As in, when I leave on a Friday afternoon, start a script to clone the guest and auto start the live guest?Sounds more like you are interested in snapshots than actually cloning your guest, where you could resume execution from the point of the snapshot. And with external snapshots, it is indeed possible to automate the periodic capture of a snapshot of a running guest; where we still lack polish is the steps for reverting back to the state in a saved snapshot (it's doable, but requires effort outside of a simple libvirt API call). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
----- Original Message -----> From: "Eric Blake" <eblake@redhat.com> > To: "Adam King" <kinga@sghs.org.uk>, "libvirt-users" <libvirt-users@redhat.com> > Sent: Monday, 22 September, 2014 5:34:52 PM > Subject: Re: [libvirt-users] unattended cloning > > On 09/16/2014 01:19 AM, Adam King wrote: > > Morning, > > > > I have a KVM guest running Win 2012 with MS SQL 2012. > > In order to provide a quick method of restoring the service should > > the live server die, we've decided to clone it to a preserved > > state. > > Ideally, this clone should also be kept up to date and cloning > > should be done on a regular basis. > > > > Is there any reason not to do unattended cloning? As in, when I > > leave on a Friday afternoon, start a script to clone the guest and > > auto start the live guest? > > Sounds more like you are interested in snapshots than actually > cloning > your guest, where you could resume execution from the point of the > snapshot. And with external snapshots, it is indeed possible to > automate the periodic capture of a snapshot of a running guest; where > we > still lack polish is the steps for reverting back to the state in a > saved snapshot (it's doable, but requires effort outside of a simple > libvirt API call). > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > >Thanks Eric & Kashyap. Maybe I'm missing something with snapshots, my understanding is that if I did something like this: virsh snapshot-create-as VM snap1-vm --diskspec vda,file=/export/vmimgs/snap1-testvm.qcow2 And then do the same to create snap2-vm, I will get 2 snapshots, where snap2 has snap1 as its backing file. OK, so doing a virsh blockpull can pull out snap1 but it looks to me as if cleaning up old snapshots is quite tricky. Thanks Adam