On Fri, Sep 30, 2011 at 4:54 PM, Stefan Hajnoczi wrote: > On Fri, Sep 30, 2011 at 2:46 PM, Robert P wrote: > > > > > > On Fri, Sep 30, 2011 at 2:04 PM, Stefan Hajnoczi > wrote: > >> > >> On Fri, Sep 30, 2011 at 11:32 AM, Robert P wrote: > >> > >> Please use Reply-All to keep qemu-devel CCed so that others can > >> contribute. > >> > >> > > >> > On Fri, Sep 30, 2011 at 10:16 AM, Stefan Hajnoczi > > >> > wrote: > >> >> > >> >> On Thu, Sep 29, 2011 at 09:07:19PM +0200, Robert P wrote: > >> >> > Hello, > >> >> > > >> >> > I still have a problem with the "Live Snapshot" feature of QEMU > .... > >> >> > and > >> >> > before migrating to XEN, VMware or something similare, a quick post > >> >> > here: > >> >> > > >> >> > OS: Ubuntu Natty 64bit > >> >> > > >> >> > First, i'm starting my KVM Machine with an image like this: > >> >> > qemu-img create -f qcow2 -o backing_file= > >> >> > > >> >> > > >> >> > If i stop the KVM Machine later, and i commit into > >> >> > , all the new changes are in the > . > >> >> > That would be ok. > >> >> > > >> >> > --- > >> >> > > >> >> > The Problem: > >> >> > > >> >> > Actually i'm trying to create "live snapshots" periodically while > >> >> > the > >> >> > machine is running, like this (host2Qemu is just a special function > >> >> > of > >> >> > mine > >> >> > (it works), to send a string to qemu-monitor). > >> >> > > >> >> > host2Qemu "cont" > >> >> > host2Qemu "guest-agent-fsfreeze" > >> >> > host2Qemu "stop" > >> >> > > >> >> > host2Qemu "info block" > >> >> > host2Qemu "snapshot_blkdev ide0-hd0 >> >> > (example)> > >> >> > qcow2" > >> >> > > >> >> > host2Qemu "cont" > >> >> > host2Qemu "guest-agent-fsthaw" > >> >> > > >> >> > My idea is, to commit them one by one afterwards, when the KVM > >> >> > Machine > >> >> > is > >> >> > down into the BaseImage. > >> >> > > >> >> > So, the Snapshots are beeing written, and everytime i call that > >> >> > function > >> >> > new > >> >> > data is beeing written to the new "alllocated" snapshot. > >> >> > BUT, committing of that live-snapshots fails, and i've no idea why > ?! > >> >> > > >> >> > I would commit it like that: > >> >> > qemu-img commit -f qcow2 > >> >> > qemu-img commit -f qcow2 > >> >> > qemu-img commit -f qcow2 > >> >> > ... > >> >> > and so on. > >> > >> You should have something like this: > >> -> -> -> ... -> > >> > >> The qemu-img commit command merges down an image file into its backing > >> file, so you would do: > >> > >> $ qemu-img commit > >> ... > >> $ qemu-img commit > >> $ qemu-img commit > >> > >> Now all the files contain no actual data - the delta have > >> been committed to their backing files. You can discard them and use > >> directly. > >> > >> How does this compare to what you were trying? > > > > Hm, that means you recommend to commit the snapshots from newest to > oldest > > into the base-Image? > > I am committing them (when the KVM is off) from oldest to newest, like > this: > > > > $ qemu-img commit > > $ qemu-img commit > > .... > > $ qemu-img commit > > > > Is that maybe causing that problem? > > Absolutely. Each snapshot has a backing file linking back to the > previous snapshot. You need to push the latest data all the way back > to the base backing file. > Ok, i've tried that also. My testcase: -) start the kvm "aptitude -f install" reports no error, and the data gets written to " snapshot-zeus-KVM_APH-2011-09-30-211303.ovl " -) inside the kvm "aptitude install csh" is also ok, then i trigger a "takeover" to a new snapshot: "snapshot-zeus-KVM_APH-2011-09-30-211424.ovl" (i do it like that in my bash-script: "sync") writeLog info "USER: somebody triggered a sync" host2Qemu "cont" host2Qemu "guest-agent-fsfreeze" host2Qemu "stop" writeLog dbg "Getting the Parameters of qemu-disk" host2Qemu "info block" writeLog dbg "Creating new Snapshot $OVL_NAME for writing ..." host2Qemu "snapshot_blkdev ide0-hd0 $SNAPSHOT_DIR/$OVL_NAME qcow2" qemu-img create -f qcow2 -o backing_file="$BASE_IMG" "$SNAPSHOT_DIR/$OVL_NAME" 1>/dev/null writeLog dbg "Success. It's now safe to take the last snapshot. " writeLog dbg "RSyncing Snapshots to ha-hpsrv-slave" host2Qemu "cont" host2Qemu "guest-agent-fsthaw" transferSnapshots;; ) So that means in that way i've described earlier. Now we should write into the next snapshot "snapshot-zeus-KVM_APH-2011-09-30-211424.ovl". -) inside the vm "aptitude install " -> triggering sync again. New Snapshot: snapshot-zeus-KVM_APH-2011-09-30-211451.ovl -) one more time inside the vm "aptitude install " -> sync. New Snapshot: "snapshot-zeus-KVM_APH-2011-09-30-211527" -) Then i make a commit like (this is an snipplet of my log-File) Fre Sep 30 21:15:27 CEST 2011 | [zeus:KVM_APH] [INFO] USER: somebody triggered a sync Fre Sep 30 21:15:27 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd: cont Fre Sep 30 21:15:28 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd: guest-agent-fsfreeze Fre Sep 30 21:15:28 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd: stop Fre Sep 30 21:15:29 CEST 2011 | [zeus:KVM_APH] [DEBUG] Getting the Parameters of qemu-disk Fre Sep 30 21:15:29 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd: info block Fre Sep 30 21:15:29 CEST 2011 | [zeus:KVM_APH] [DEBUG] Creating new Snapshot snapshot-zeus-KVM_APH-2011-09-30-211527.ovl for writing ... Fre Sep 30 21:15:29 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd: snapshot_blkdev ide0-hd0 /backup/KVM/Aphrodite//Snapshots/snapshot-zeus-KVM_APH-2011-09-30-211527.ovl qcow2 Fre Sep 30 21:15:30 CEST 2011 | [zeus:KVM_APH] [DEBUG] Success. It's now safe to take the last snapshot. Fre Sep 30 21:15:30 CEST 2011 | [zeus:KVM_APH] [DEBUG] RSyncing Snapshots to ha-hpsrv-slave Fre Sep 30 21:15:30 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd: cont Fre Sep 30 21:15:30 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd: guest-agent-fsthaw Fre Sep 30 21:15:31 CEST 2011 | [zeus:KVM_APH] [DEBUG] RSync Done. Fre Sep 30 21:15:36 CEST 2011 | [zeus:KVM_APH] [INFO] USER: somebody triggered a stop Fre Sep 30 21:15:36 CEST 2011 | [zeus:KVM_APH] [DEBUG] Sending a PowerDown to KVM (CMD: kvmtool.sh KVM-APH-test send system_powerdown)... Fre Sep 30 21:15:36 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd: system_powerdown Fre Sep 30 21:16:06 CEST 2011 | [zeus:KVM_APH] [DEBUG] RSyncing with other device ... Fre Sep 30 21:16:06 CEST 2011 | [zeus:KVM_APH] [DEBUG] RSync Done. Fre Sep 30 21:16:06 CEST 2011 | [zeus:KVM_APH] [DEBUG] Committing changes into own image, this may take a while ... Fre Sep 30 21:16:06 CEST 2011 | [zeus:KVM_APH] [INFO] USER: somebody triggered a commit Fre Sep 30 21:16:06 CEST 2011 | [zeus:KVM_APH] [DEBUG] Committing snapshot-zeus-KVM_APH-2011-09-30-211527.ovl to /backup/KVM/Aphrodite//KVM_Aphrodite_Ubuntu11.04_32bit_Master.img.qcow2 Fre Sep 30 21:16:07 CEST 2011 | [zeus:KVM_APH] [DEBUG] Commited. Fre Sep 30 21:16:07 CEST 2011 | [zeus:KVM_APH] [DEBUG] Committing snapshot-zeus-KVM_APH-2011-09-30-211451.ovl to /backup/KVM/Aphrodite//KVM_Aphrodite_Ubuntu11.04_32bit_Master.img.qcow2 Fre Sep 30 21:16:27 CEST 2011 | [zeus:KVM_APH] [DEBUG] Commited. Fre Sep 30 21:16:27 CEST 2011 | [zeus:KVM_APH] [DEBUG] Committing snapshot-zeus-KVM_APH-2011-09-30-211424.ovl to /backup/KVM/Aphrodite//KVM_Aphrodite_Ubuntu11.04_32bit_Master.img.qcow2 Fre Sep 30 21:16:40 CEST 2011 | [zeus:KVM_APH] [DEBUG] Commited. Fre Sep 30 21:16:40 CEST 2011 | [zeus:KVM_APH] [DEBUG] Committing snapshot-zeus-KVM_APH-2011-09-30-211303.ovl to /backup/KVM/Aphrodite//KVM_Aphrodite_Ubuntu11.04_32bit_Master.img.qcow2 Fre Sep 30 21:16:42 CEST 2011 | [zeus:KVM_APH] [DEBUG] Commited. Fre Sep 30 21:16:42 CEST 2011 | [zeus:KVM_APH] [INFO] Stopped Virtual Machine So that means, the order should be correct now, how the snapshots get commited into the base Image. -) i restart the machine, log in again and the state is almost like it was when we started initially, but when i make a "aptitude -f install" then the filesystem seems to be corrupt, and also none of that packages from before are installed: [root@aphrodite ~]# aptitude -f install No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. localepurge: Disk space freed in /usr/share/locale: 0 KiB du: cannot access `/usr/share/man/man1/ksh.1.gz': Input/output error 2011 Sep 30 21:17:44 aphrodite [ 41.250887] EXT4-fs (sda1): Remounting filesystem read-only 2011 Sep 30 21:17:44 aphrodite [ 41.444655] EXT4-fs error (device sda1): ext4_journal_start_sb:260: Detected aborted journal du: cannot access `/usr/share/man/man1/tcsh.1.gz': Input/output error du: cannot access `/usr/share/man/man1/ksh.1.gz': Input/output error du: cannot access `/usr/share/man/man1/tcsh.1.gz': Input/output error localepurge: Disk space freed in /usr/share/man: 0 KiB localepurge: Disk space freed in /usr/share/omf: 0 KiB Total disk space freed by localepurge: 0 KiB E: Failed to write temporary StateFile /var/lib/apt/extended_states.tmp W: Not using locking for read only lock file /var/lib/dpkg/lock W: Not using locking for read only lock file /var/lib/dpkg/lock E: Unable to write to /var/cache/apt/ E: The package lists or status file could not be parsed or opened. I guess there got something corrupted in the filesystem after the commits .... I've tried that a couple of times now, result is everytime the same :( Thanks. Robert > Stefan >