From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9ih6-0004dn-Hd for qemu-devel@nongnu.org; Fri, 30 Sep 2011 15:24:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R9ih4-0002Ud-Ao for qemu-devel@nongnu.org; Fri, 30 Sep 2011 15:24:24 -0400 Received: from mail-fx0-f45.google.com ([209.85.161.45]:37754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9ih3-0002UN-Sh for qemu-devel@nongnu.org; Fri, 30 Sep 2011 15:24:22 -0400 Received: by fxh13 with SMTP id 13so3465520fxh.4 for ; Fri, 30 Sep 2011 12:24:20 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20110930081627.GA12834@stefanha-thinkpad.localdomain> Date: Fri, 30 Sep 2011 21:24:18 +0200 Message-ID: From: Robert P Content-Type: multipart/alternative; boundary=0015174485006de1bf04ae2d9264 Subject: Re: [Qemu-devel] QEMU Live Snapshots / Commiting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Marcelo Tosatti , qemu-devel --0015174485006de1bf04ae2d9264 Content-Type: text/plain; charset=ISO-8859-1 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 > --0015174485006de1bf04ae2d9264 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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> w= rote:
>
>
> 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&= quot; feature of QEMU ....
>> >> > and
>> >> > before migrating to XEN, VMware or something similar= e, 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=3D<NameO= fBaseImage>
>> >> > <Snapshotname>
>> >> >
>> >> > If i stop the KVM Machine later, and i commit <Sn= apshotname> into
>> >> > <NameOfBaseImage>, all the new changes are in = the <NameOfBaseImage>.
>> >> > That would be ok.
>> >> >
>> >> > ---
>> >> >
>> >> > The Problem:
>> >> >
>> >> > Actually i'm trying to create "live snapsho= ts" periodically =A0while
>> >> > the
>> >> > machine is running, like this (host2Qemu is just a s= pecial function
>> >> > of
>> >> > mine
>> >> > (it works), to send a string to qemu-monitor).
>> >> >
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "cont= "
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "gues= t-agent-fsfreeze"
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "stop= "
>> >> >
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "info= block"
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "snap= shot_blkdev ide0-hd0 <Snapshot1
>> >> > (example)>
>> >> > qcow2"
>> >> >
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "cont= "
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "gues= t-agent-fsthaw"
>> >> >
>> >> > My idea is, to commit them one by one afterwards, wh= en 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&q= uot; snapshot.
>> >> > BUT, committing of that live-snapshots fails, and i&= #39;ve no idea why ?!
>> >> >
>> >> > I would commit it like that:
>> >> > =A0qemu-img commit -f qcow2 <Snapshot, with KVM w= as 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> -> <Snapshot= 2> -> ... -> <SnapshotN>
>>
>> The qemu-img commit command merges down an image file into its bac= king
>> 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 d= elta have
>> been committed to their backing files. =A0You 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 ol= dest
> 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. =A0Each snapshot has a backing file linking back to= the
previous snapshot. =A0You need to push the latest data all the way back
to the base backing file.

Ok, i've = tried that also.=A0
My testcase:=A0

-) s= tart the kvm
"aptitude -f install" reports no error, an= d the data gets written to "snapshot-zeus-KVM_APH-2011-09-30-211303.ovl= =A0"

-) inside the kvm
"aptitude install csh&= quot; 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:
=A0 =A0 =A0 =A0 &= quot;sync")
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeLog info &q= uot;USER: somebody triggered a sync"

=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "cont"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "guest-agent-fsfreeze&q= uot;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "stop"

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeLog dbg "= Getting the Parameters of qemu-disk"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host2Qemu "info block"
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeLog dbg "Creating new =A0Sna= pshot $OVL_NAME for writing ..."

=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 host2Qemu "snapshot_blkdev ide0-hd0 $SNAPSHOT_DIR/= $OVL_NAME qcow2"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 qemu-img create -f qcow2 -o backing_fi= le=3D"$BASE_IMG" "$SNAPSHOT_DIR/$OVL_NAME" 1>/dev/nu= ll

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeLog dbg &q= uot;Success. It's now safe to take the last snapshot. "
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeLog dbg "RSyncing Snapshots = to ha-hpsrv-slave"

=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 host2Qemu "cont"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 host2Qemu "guest-agent-fsthaw"

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 transferSnapshots;;
)=A0
So that means in that way i've described ea= rlier.=A0

Now we should write into the next snapsh= ot "snapshot-zeus-KVM_APH-2011-09-30-211424.ovl".=A0

-) inside the vm
"aptitude install <s= omeotherpackage>" -> triggering sync again.=A0

New Snapshot:=A0=A0snapshot-zeus-KVM_APH-2011-09-30-211451.ovl<= div>
-) one more time inside the vm
"aptitude inst= all <someotherinterestingpackage>" -> sync.=A0

=
New Snapshot:
"snapshot-zeus-KVM_APH-2011-09-30-211= 527"

-) Then i make a commit like (this is an snipplet of my= log-File)
Fre Sep 30 21:15:27 CEST 2011 | [zeus:KVM_AP= H] [INFO] USER: somebody triggered a sync=A0
Fre Sep 30 21:15:27 = CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd: cont=A0
Fre Sep 30 21:15:28 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd= : guest-agent-fsfreeze=A0
Fre Sep 30 21:15:28 CEST 2011 | [zeus:K= VM_APH] [DEBUG] New QemuMon Cmd: stop=A0
Fre Sep 30 21:15:29 CEST= 2011 | [zeus:KVM_APH] [DEBUG] Getting the Parameters of qemu-disk=A0
Fre Sep 30 21:15:29 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd= : info block=A0
Fre Sep 30 21:15:29 CEST 2011 | [zeus:KVM_APH] [D= EBUG] Creating new =A0Snapshot snapshot-zeus-KVM_APH-2011-09-30-211527.ovl = for writing ...=A0
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-K= VM_APH-2011-09-30-211527.ovl qcow2=A0
Fre Sep 30 21:15:30 CEST 20= 11 | [zeus:KVM_APH] [DEBUG] Success. It's now safe to take the last sna= pshot. =A0
Fre Sep 30 21:15:30 CEST 2011 | [zeus:KVM_APH] [DEBUG] RSyncing Snapsh= ots to ha-hpsrv-slave=A0
Fre Sep 30 21:15:30 CEST 2011 | [zeus:KV= M_APH] [DEBUG] New QemuMon Cmd: cont=A0
Fre Sep 30 21:15:30 CEST = 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd: guest-agent-fsthaw=A0
Fre Sep 30 21:15:31 CEST 2011 | [zeus:KVM_APH] [DEBUG] RSync Done. =A0=
Fre Sep 30 21:15:36 CEST 2011 | [zeus:KVM_APH] [INFO] USER: some= body triggered a stop=A0
Fre Sep 30 21:15:36 CEST 2011 | [zeus:KV= M_APH] [DEBUG] Sending a PowerDown to KVM (CMD: kvmtool.sh KVM-APH-test sen= d system_powerdown)...=A0
Fre Sep 30 21:15:36 CEST 2011 | [zeus:KVM_APH] [DEBUG] New QemuMon Cmd= : system_powerdown=A0
Fre Sep 30 21:16:06 CEST 2011 | [zeus:KVM_A= PH] [DEBUG] RSyncing with other device ...=A0
Fre Sep 30 21:16:06= CEST 2011 | [zeus:KVM_APH] [DEBUG] RSync Done. =A0
Fre Sep 30 21:16:06 CEST 2011 | [zeus:KVM_APH] [DEBUG] Committing chan= ges into own image, this may take a while ... =A0
Fre Sep 30 21:1= 6:06 CEST 2011 | [zeus:KVM_APH] [INFO] USER: somebody triggered a commit=A0=
Fre Sep 30 21:16:06 CEST 2011 | [zeus:KVM_APH] [DEBUG] Committing snap= shot-zeus-KVM_APH-2011-09-30-211527.ovl to /backup/KVM/Aphrodite//KVM_Aphro= dite_Ubuntu11.04_32bit_Master.img.qcow2=A0
Fre Sep 30 21:16:07 CE= ST 2011 | [zeus:KVM_APH] [DEBUG] Commited. =A0
Fre Sep 30 21:16:07 CEST 2011 | [zeus:KVM_APH] [DEBUG] Committing snap= shot-zeus-KVM_APH-2011-09-30-211451.ovl to /backup/KVM/Aphrodite//KVM_Aphro= dite_Ubuntu11.04_32bit_Master.img.qcow2=A0
Fre Sep 30 21:16:27 CE= ST 2011 | [zeus:KVM_APH] [DEBUG] Commited. =A0
Fre Sep 30 21:16:27 CEST 2011 | [zeus:KVM_APH] [DEBUG] Committing snap= shot-zeus-KVM_APH-2011-09-30-211424.ovl to /backup/KVM/Aphrodite//KVM_Aphro= dite_Ubuntu11.04_32bit_Master.img.qcow2=A0
Fre Sep 30 21:16:40 CE= ST 2011 | [zeus:KVM_APH] [DEBUG] Commited. =A0
Fre Sep 30 21:16:40 CEST 2011 | [zeus:KVM_APH] [DEBUG] Committing snap= shot-zeus-KVM_APH-2011-09-30-211303.ovl to /backup/KVM/Aphrodite//KVM_Aphro= dite_Ubuntu11.04_32bit_Master.img.qcow2=A0
Fre Sep 30 21:16:42 CE= ST 2011 | [zeus:KVM_APH] [DEBUG] Commited. =A0
Fre Sep 30 21:16:42 CEST 2011 | [zeus:KVM_APH] [INFO] Stopped Virtual = Machine=A0

So that means, the order sh= ould be correct now, how the snapshots get commited into the base Image.=A0=

-) 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, an= d also none of that packages from before are installed:=A0

[root@aphrodite ~]# aptitude -f install
=
No packages will be installed, upgraded, or removed.
0 packa= ges 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.
lo= calepurge: Disk space freed in /usr/share/locale: 0 KiB
du: canno= t access `/usr/share/man/man1/ksh.1.gz': Input/output error
2011 Sep 30 21:17:44 aphrodite [ =A0 41.250887] EXT4-fs (sda1): Remounting = filesystem read-only
2011 Sep 30 21:17:44 aphrodite [ =A0 41.4446= 55] EXT4-fs error (device sda1): ext4_journal_start_sb:260: Detected aborte= d journal
du: cannot access `/usr/share/man/man1/tcsh.1.gz': Input/output er= ror
du: cannot access `/usr/share/man/man1/ksh.1.gz': Input/o= utput error
du: cannot access `/usr/share/man/man1/tcsh.1.gz'= : Input/output error
localepurge: Disk space freed in /usr/share/man: 0 KiB
local= epurge: Disk space freed in /usr/share/omf: 0 KiB

= Total disk space freed by localepurge: 0 KiB

E: Fa= iled to write temporary StateFile /var/lib/apt/extended_states.tmp
W: Not using locking for read only lock file /var/lib/dpkg/lock
<= div>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 th= e filesystem after the commits=A0
.... I've tried that a coup= le of times now, result is everytime the same =A0:(

Thanks.=A0
Robert


Stefan

--0015174485006de1bf04ae2d9264--