* [Qemu-devel] QEMU Live Snapshots / Commiting [not found] <CAHEq_3PLXn2F015G-GisY7MjZS-f8mgrYxHymoCX3kD+0+=B4g@mail.gmail.com> @ 2011-09-29 19:07 ` Robert P 2011-09-30 8:16 ` Stefan Hajnoczi 0 siblings, 1 reply; 6+ messages in thread From: Robert P @ 2011-09-29 19:07 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 1985 bytes --] 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=<NameOfBaseImage> <Snapshotname> If i stop the KVM Machine later, and i commit <Snapshotname> into <NameOfBaseImage>, all the new changes are in the <NameOfBaseImage>. 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 <Snapshot1 (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 <Snapshot, with KVM was started first> qemu-img commit -f qcow2 <Snapshot1, newer> qemu-img commit -f qcow2 <Snapshot1, more new> ... and so on. So in that constellation, only changes from the Snapshot, with KVM was started are in the Base-Image. And another question: I have a Windows XP Guest also in KVM, but the write performance into the (qcow2 Image) (scp, rsync, e.g) Guest seems to be pretty poor - Are there any hints or is there a special Parameter to avoid this? The write Performance to a Linux Guest with a similar configuration and also qcow2 seems to very close to the "native" Performance. Thanks. Robert [-- Attachment #2: Type: text/html, Size: 2430 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] QEMU Live Snapshots / Commiting 2011-09-29 19:07 ` [Qemu-devel] QEMU Live Snapshots / Commiting Robert P @ 2011-09-30 8:16 ` Stefan Hajnoczi [not found] ` <CAHEq_3NNj_-h5+H3P=AGoz=aTcVken2gPhcxET4dGZnWn+zAdA@mail.gmail.com> 0 siblings, 1 reply; 6+ messages in thread From: Stefan Hajnoczi @ 2011-09-30 8:16 UTC (permalink / raw) To: Robert P; +Cc: qemu-devel 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=<NameOfBaseImage> <Snapshotname> > > If i stop the KVM Machine later, and i commit <Snapshotname> into > <NameOfBaseImage>, all the new changes are in the <NameOfBaseImage>. > 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 <Snapshot1 (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 <Snapshot, with KVM was started first> > qemu-img commit -f qcow2 <Snapshot1, newer> > qemu-img commit -f qcow2 <Snapshot1, more new> > ... > and so on. > > So in that constellation, only changes from the Snapshot, with KVM was > started are in the Base-Image. I'm not 100% clear that you know qemu-img commit cannot be used while QEMU is running and has the disk image file open. It's simply not safe to modify the image file with qemu-img while QEMU is running. > And another question: I have a Windows XP Guest also in KVM, but the write > performance into the (qcow2 Image) (scp, rsync, e.g) Guest seems to be > pretty poor - Are there any hints or is there a special Parameter to avoid > this? > The write Performance to a Linux Guest with a similar configuration and also > qcow2 seems to very close to the "native" Performance. Are you using the virtio drivers for Windows? Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CAHEq_3NNj_-h5+H3P=AGoz=aTcVken2gPhcxET4dGZnWn+zAdA@mail.gmail.com>]
* Re: [Qemu-devel] QEMU Live Snapshots / Commiting [not found] ` <CAHEq_3NNj_-h5+H3P=AGoz=aTcVken2gPhcxET4dGZnWn+zAdA@mail.gmail.com> @ 2011-09-30 12:04 ` Stefan Hajnoczi 2011-09-30 13:46 ` Robert P 0 siblings, 1 reply; 6+ messages in thread From: Stefan Hajnoczi @ 2011-09-30 12:04 UTC (permalink / raw) To: Robert P; +Cc: Kevin Wolf, Marcelo Tosatti, qemu-devel On Fri, Sep 30, 2011 at 11:32 AM, Robert P <robp236@gmail.com> 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 <stefanha@gmail.com> > 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=<NameOfBaseImage> >> > <Snapshotname> >> > >> > If i stop the KVM Machine later, and i commit <Snapshotname> into >> > <NameOfBaseImage>, all the new changes are in the <NameOfBaseImage>. >> > 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 <Snapshot1 >> > (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 <Snapshot, with KVM was started first> >> > qemu-img commit -f qcow2 <Snapshot1, newer> >> > qemu-img commit -f qcow2 <Snapshot1, more new> >> > ... >> > and so on. You should have something like this: <NameOfBaseImage> -> <Snapshot1> -> <Snapshot2> -> ... -> <SnapshotN> The qemu-img commit command merges down an image file into its backing file, so you would do: $ qemu-img commit <SnapshotN> ... $ qemu-img commit <Snapshot2> $ qemu-img commit <Snapshot1> Now all the <Snapshot*> files contain no actual data - the delta have been committed to their backing files. You can discard them and use <NameOfBaseImage> directly. How does this compare to what you were trying? Unfortunately this is an inefficient approach because the same data gets copied N times from <SnapshotN> all the way down to <NameOfBaseImage>. What's really needed is live merge support with the ability to merge down multiple layers of the backing file (e.g. do it all in one command and only copy data once). Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] QEMU Live Snapshots / Commiting 2011-09-30 12:04 ` Stefan Hajnoczi @ 2011-09-30 13:46 ` Robert P 2011-09-30 14:54 ` Stefan Hajnoczi 0 siblings, 1 reply; 6+ messages in thread From: Robert P @ 2011-09-30 13:46 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: Kevin Wolf, Marcelo Tosatti, qemu-devel [-- Attachment #1: Type: text/plain, Size: 3459 bytes --] On Fri, Sep 30, 2011 at 2:04 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote: > On Fri, Sep 30, 2011 at 11:32 AM, Robert P <robp236@gmail.com> 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 <stefanha@gmail.com> > > 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=<NameOfBaseImage> > >> > <Snapshotname> > >> > > >> > If i stop the KVM Machine later, and i commit <Snapshotname> into > >> > <NameOfBaseImage>, all the new changes are in the <NameOfBaseImage>. > >> > 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 <Snapshot1 > >> > (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 <Snapshot, with KVM was started first> > >> > qemu-img commit -f qcow2 <Snapshot1, newer> > >> > qemu-img commit -f qcow2 <Snapshot1, more new> > >> > ... > >> > and so on. > > You should have something like this: > <NameOfBaseImage> -> <Snapshot1> -> <Snapshot2> -> ... -> <SnapshotN> > > The qemu-img commit command merges down an image file into its backing > file, so you would do: > > $ qemu-img commit <SnapshotN> > ... > $ qemu-img commit <Snapshot2> > $ qemu-img commit <Snapshot1> > > Now all the <Snapshot*> files contain no actual data - the delta have > been committed to their backing files. You can discard them and use > <NameOfBaseImage> 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 <Snapshot1> $ qemu-img commit <Snapshot2> .... $ qemu-img commit <SnapshotN> Is that maybe causing that problem? Thanks. Robert > Unfortunately this is an inefficient approach because the same data > gets copied N times from <SnapshotN> all the way down to > <NameOfBaseImage>. What's really needed is live merge support with > the ability to merge down multiple layers of the backing file (e.g. do > it all in one command and only copy data once). > > Stefan > [-- Attachment #2: Type: text/html, Size: 5363 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] QEMU Live Snapshots / Commiting 2011-09-30 13:46 ` Robert P @ 2011-09-30 14:54 ` Stefan Hajnoczi 2011-09-30 19:24 ` Robert P 0 siblings, 1 reply; 6+ messages in thread From: Stefan Hajnoczi @ 2011-09-30 14:54 UTC (permalink / raw) To: Robert P; +Cc: Kevin Wolf, Marcelo Tosatti, qemu-devel On Fri, Sep 30, 2011 at 2:46 PM, Robert P <robp236@gmail.com> wrote: > > > On Fri, Sep 30, 2011 at 2:04 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote: >> >> On Fri, Sep 30, 2011 at 11:32 AM, Robert P <robp236@gmail.com> 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 <stefanha@gmail.com> >> > 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=<NameOfBaseImage> >> >> > <Snapshotname> >> >> > >> >> > If i stop the KVM Machine later, and i commit <Snapshotname> into >> >> > <NameOfBaseImage>, all the new changes are in the <NameOfBaseImage>. >> >> > 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 <Snapshot1 >> >> > (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 <Snapshot, with KVM was started first> >> >> > qemu-img commit -f qcow2 <Snapshot1, newer> >> >> > qemu-img commit -f qcow2 <Snapshot1, more new> >> >> > ... >> >> > and so on. >> >> You should have something like this: >> <NameOfBaseImage> -> <Snapshot1> -> <Snapshot2> -> ... -> <SnapshotN> >> >> The qemu-img commit command merges down an image file into its backing >> file, so you would do: >> >> $ qemu-img commit <SnapshotN> >> ... >> $ qemu-img commit <Snapshot2> >> $ qemu-img commit <Snapshot1> >> >> Now all the <Snapshot*> files contain no actual data - the delta have >> been committed to their backing files. You can discard them and use >> <NameOfBaseImage> 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 <Snapshot1> > $ qemu-img commit <Snapshot2> > .... > $ qemu-img commit <SnapshotN> > > 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. Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] QEMU Live Snapshots / Commiting 2011-09-30 14:54 ` Stefan Hajnoczi @ 2011-09-30 19:24 ` Robert P 0 siblings, 0 replies; 6+ messages in thread From: Robert P @ 2011-09-30 19:24 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: Kevin Wolf, Marcelo Tosatti, qemu-devel [-- Attachment #1: Type: text/plain, Size: 10258 bytes --] On Fri, Sep 30, 2011 at 4:54 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote: > On Fri, Sep 30, 2011 at 2:46 PM, Robert P <robp236@gmail.com> wrote: > > > > > > On Fri, Sep 30, 2011 at 2:04 PM, Stefan Hajnoczi <stefanha@gmail.com> > wrote: > >> > >> On Fri, Sep 30, 2011 at 11:32 AM, Robert P <robp236@gmail.com> 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 <stefanha@gmail.com > > > >> > 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=<NameOfBaseImage> > >> >> > <Snapshotname> > >> >> > > >> >> > If i stop the KVM Machine later, and i commit <Snapshotname> into > >> >> > <NameOfBaseImage>, all the new changes are in the > <NameOfBaseImage>. > >> >> > 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 <Snapshot1 > >> >> > (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 <Snapshot, with KVM was started first> > >> >> > qemu-img commit -f qcow2 <Snapshot1, newer> > >> >> > qemu-img commit -f qcow2 <Snapshot1, more new> > >> >> > ... > >> >> > and so on. > >> > >> You should have something like this: > >> <NameOfBaseImage> -> <Snapshot1> -> <Snapshot2> -> ... -> <SnapshotN> > >> > >> The qemu-img commit command merges down an image file into its backing > >> file, so you would do: > >> > >> $ qemu-img commit <SnapshotN> > >> ... > >> $ qemu-img commit <Snapshot2> > >> $ qemu-img commit <Snapshot1> > >> > >> Now all the <Snapshot*> files contain no actual data - the delta have > >> been committed to their backing files. You can discard them and use > >> <NameOfBaseImage> 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 <Snapshot1> > > $ qemu-img commit <Snapshot2> > > .... > > $ qemu-img commit <SnapshotN> > > > > 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 <someotherpackage>" -> triggering sync again. New Snapshot: snapshot-zeus-KVM_APH-2011-09-30-211451.ovl -) one more time inside the vm "aptitude install <someotherinterestingpackage>" -> 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 > [-- Attachment #2: Type: text/html, Size: 14511 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-09-30 19:24 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAHEq_3PLXn2F015G-GisY7MjZS-f8mgrYxHymoCX3kD+0+=B4g@mail.gmail.com> 2011-09-29 19:07 ` [Qemu-devel] QEMU Live Snapshots / Commiting Robert P 2011-09-30 8:16 ` Stefan Hajnoczi [not found] ` <CAHEq_3NNj_-h5+H3P=AGoz=aTcVken2gPhcxET4dGZnWn+zAdA@mail.gmail.com> 2011-09-30 12:04 ` Stefan Hajnoczi 2011-09-30 13:46 ` Robert P 2011-09-30 14:54 ` Stefan Hajnoczi 2011-09-30 19:24 ` Robert P
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.