qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Rebase Running QCOW Image


From: Mike Lovell
Subject: Re: [Qemu-discuss] Rebase Running QCOW Image
Date: Tue, 27 Mar 2012 16:11:16 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20

On 03/14/2012 07:59 AM, Andrew Martin wrote:
I have been using qcow2 copy-on-write images for several VMs and it has been working very well. From time to time I would like to rebase the image to update the backing file and create a new, empty copy-on-write image. Is it possible to rebase a running or paused VM to minimize downtime? Or at the very least, create a separate snapshot file that could be used to create other VMs that are a clone of the running VM?

hrm. when i first read this question, i thought there isn't a way to do this. but after thinking about it, there maybe be a way. i don't think i've heard of anyone doing anything like this so i claim no responsibility if this messes something up. i'm not a developer and don't know all the internals of qemu to say for sure the data will be safe. it might be possible if were you were to follow a procedure like this.

 * freeze the filesystems in the guest and sync the disks. this will vary across operating systems. for a linux vm, i don't think all filesystems support freezing but the major ones do. the qemu guest agent (qemu-ga) can be useful here though i don't know how well it works on non-linux systems and documentation for it is somewhat weak. fsfreeze is a newer utility in the util-linux-ng package that can the filesystem freezing.
 * after the disks have been sync'ed, create a snapshot of the guest using the savevm command.
 * unfreeze the filesystem in the guest and check that its alright.
 * run `qemu-img convert -s <snapshot name> <existing vm file> <rebased vm file>`. the -s specifies which snapshot name or id to use. it would be a good idea to make sure the snapshot is seen in `qemu-img snapshot -l <existing vm file>` first.
 * check the resulting image. you can try booting it in another guest or use qemu-nbd to attach it to the host and then check the contents.

this procedure will probably only work with some of the image formats that qemu supports. also, i don't know if qemu-img will complain if the source disk image is open in another process. it would also be a good idea to stop any services that write much to disk in the guest before beginning this process. it could reduce the amount of data that is left in the guest's page cache. the resulting image is going to be one that is just like the VM crashed at the moment of the snapshot. so if you can guarantee the data is alright then, it might work.

i have not done this procedure. i don't even know if it would work. and don't blame me if it screws things up. if you do try it, and it does work, please let me know and also don't expect it to work in all scenarios.

mike

reply via email to

[Prev in Thread] Current Thread [Next in Thread]