5:10 a.m.
Hi,
How can I do if I want to schedule a daily live-snapshot of a VM for
backup purpose?
I have backup software inside my VMs (Netvault), but in some cases I
just want to do daily snapshots and use them as backups.
--
Ricky Schneberger
5:31 a.m.
On Mon, 04 Mar 2013 12:10:54 +0100
Ricky Schneberger <ricky(a)schneberger.se> wrote:
Hi,
How can I do if I want to schedule a daily live-snapshot of a VM for
backup purpose?
I have backup software inside my VMs (Netvault), but in some cases I
just want to do daily snapshots and use them as backups.
Live snapshot does not save memory state, IIRC. So either shutdown all
VMs or do not think about this as solid backup solution.
5:52 a.m.
On 2013-03-04 12:31, Jiri Belka wrote:
On Mon, 04 Mar 2013 12:10:54 +0100
Ricky Schneberger <ricky(a)schneberger.se> wrote:
> Hi,
>
> How can I do if I want to schedule a daily live-snapshot of a VM for
> backup purpose?
>
> I have backup software inside my VMs (Netvault), but in some cases I
> just want to do daily snapshots and use them as backups.
>
>
Live snapshot does not save memory state, IIRC. So either shutdown all
VMs or do not think about this as solid backup solution.
Hi, If I dont think about it as a solid solution, is it doable?
Even with a manual live snapshot I will lack this memory state, right?
All I want if I must restore a snapshot is to get the WM up on track in
an earlier state.
regards //Ricky
6:24 a.m.
On Mon, 04 Mar 2013 12:52:53 +0100
Ricky Schneberger <ricky(a)schneberger.se> wrote:
> Live snapshot does not save memory state, IIRC. So either
shutdown all
> VMs or do not think about this as solid backup solution.
>
Hi, If I dont think about it as a solid solution, is it doable?
Even with a manual live snapshot I will lack this memory state, right?
All I want if I must restore a snapshot is to get the WM up on track in
an earlier state.
The "snapshot" like in VMWare world which saves even memory is called
checkpoint in qemu-kvm world. And IIRC it is not implemented yet.
Live snapshot is doable, no problem. The problem can be your design. As
you know a lot of apps do not write to filesystem immediately, so
snapshot backup is useless. So either shutdown/think twice or forget it.
But others can have different view... Backup is thing you _must_ trust,
if you design is broken, the consequences are terrific! If your goal is
to have fast disaster recovery, then why not to have backup machine or
some clustered solution?
jbelka
6:57 a.m.
On 2013-03-04 13:24, Jiri Belka wrote:
On Mon, 04 Mar 2013 12:52:53 +0100 Ricky Schneberger
<ricky(a)schneberger.se> wrote:
>> Live snapshot does not save memory state, IIRC. So either
>> shutdown all VMs or do not think about this as solid backup
>> solution.
>>
>
> Hi, If I dont think about it as a solid solution, is it doable?
> Even with a manual live snapshot I will lack this memory state,
> right?
>
> All I want if I must restore a snapshot is to get the WM up on
> track in an earlier state.
The "snapshot" like in VMWare world which saves even memory is
called checkpoint in qemu-kvm world. And IIRC it is not implemented
yet.
Live snapshot is doable, no problem. The problem can be your
design. As you know a lot of apps do not write to filesystem
immediately, so snapshot backup is useless. So either
shutdown/think twice or forget it.
But others can have different view... Backup is thing you _must_
trust, if you design is broken, the consequences are terrific! If
your goal is to have fast disaster recovery, then why not to have
backup machine or some clustered solution?
jbelka
Thanks for your answer.
We have both Netvault and Acronis on the most of the VMs, but then we
have other VMs in the cluster that we want a daily scheduled snapshot
implementation on, but we dont want to setup a complete backup
solution on this VMs. It's testmachines, different virtual desktops,
OCR-readers and so on. We have no needs of snapshots like in VMWare
world for them, nor even a complete backup solution. There I think
Ovirts snapshot handling should be perfect.
//Ricky
7:02 a.m.
On 04/03/2013 14:57, Ricky Schneberger wrote:
On 2013-03-04 13:24, Jiri Belka wrote:
> On Mon, 04 Mar 2013 12:52:53 +0100 Ricky Schneberger
> <ricky(a)schneberger.se> wrote:
>
>>> Live snapshot does not save memory state, IIRC. So either
>>> shutdown all VMs or do not think about this as solid backup
>>> solution.
>>>
>>
>> Hi, If I dont think about it as a solid solution, is it doable?
>> Even with a manual live snapshot I will lack this memory state,
>> right?
>>
>> All I want if I must restore a snapshot is to get the WM up on
>> track in an earlier state.
>
> The "snapshot" like in VMWare world which saves even memory is
> called checkpoint in qemu-kvm world. And IIRC it is not implemented
> yet.
>
> Live snapshot is doable, no problem. The problem can be your
> design. As you know a lot of apps do not write to filesystem
> immediately, so snapshot backup is useless. So either
> shutdown/think twice or forget it.
>
> But others can have different view... Backup is thing you _must_
> trust, if you design is broken, the consequences are terrific! If
> your goal is to have fast disaster recovery, then why not to have
> backup machine or some clustered solution?
>
> jbelka
>
Thanks for your answer.
We have both Netvault and Acronis on the most of the VMs, but then we
have other VMs in the cluster that we want a daily scheduled snapshot
implementation on, but we dont want to setup a complete backup
solution on this VMs. It's testmachines, different virtual desktops,
OCR-readers and so on. We have no needs of snapshots like in VMWare
world for them, nor even a complete backup solution. There I think
Ovirts snapshot handling should be perfect.
in general, you are correct - you don't care about live snapshot with
memory, since you probably mostly care about backing up the disks.
you may care, depending on the type of guest, on having a
qemu-guest-agent installed, which would help with syncing the writes to
the disks before the live snapshot is taken.
something to test though is if a daily snapshot does not degrade the
performance of the running VM, due to more COW layers (until the backup
api and live merge are in place).
2:33 a.m.
On Mon, Mar 4, 2013 at 2:02 PM, Itamar Heim wrote:
in general, you are correct - you don't care about live snapshot
with
memory, since you probably mostly care about backing up the disks.
you may care, depending on the type of guest, on having a qemu-guest-agent
installed, which would help with syncing the writes to the disks before the
live snapshot is taken.
something to test though is if a daily snapshot does not degrade the
performance of the running VM, due to more COW layers (until the backup api
and live merge are in place).
hello, coming back to this topic.
when you say
"
you may care, depending on the type of guest, on having a
qemu-guest-agent installed, which would help with syncing the writes
to the disks
"
do you refer to something in particular already implemented as a
command or something similar?
I have a CentOS 6 guest with rhev-guest-agent taken by dreyu repoan
dwould like to test what available in case.
Thanks,
Gianluca
2:58 a.m.
On 04/19/2013 10:33 AM, Gianluca Cecchi wrote:
On Mon, Mar 4, 2013 at 2:02 PM, Itamar Heim wrote:
> in general, you are correct - you don't care about live snapshot with
> memory, since you probably mostly care about backing up the disks.
> you may care, depending on the type of guest, on having a qemu-guest-agent
> installed, which would help with syncing the writes to the disks before the
> live snapshot is taken.
>
> something to test though is if a daily snapshot does not degrade the
> performance of the running VM, due to more COW layers (until the backup api
> and live merge are in place).
hello, coming back to this topic.
when you say
"
you may care, depending on the type of guest, on having a
qemu-guest-agent installed, which would help with syncing the writes
to the disks
"
do you refer to something in particular already implemented as a
command or something similar?
I have a CentOS 6 guest with rhev-guest-agent taken by dreyu repoan
dwould like to test what available in case.
Thanks,
Gianluca
qemu-guest-agent isn't ovirt/rhev-guest-agent.
now that qemu started their own guest agent, ovirt/rhev-guest-agent
isn't used for things covered by the qemu-guest-agent.
3:46 a.m.
On Fri, Apr 19, 2013 at 9:58 AM, Itamar Heim wrote:
qemu-guest-agent isn't ovirt/rhev-guest-agent.
now that qemu started their own guest agent, ovirt/rhev-guest-agent isn't
used for things covered by the qemu-guest-agent.
Ah, ok.
SO after reading
http://wiki.libvirt.org/page/Qemu_guest_agent
some questions
can we use ootb qemu-guest-agent with ovirt 3.2.1 if we have for
example a CentOS 6 guest (with qemu-guest-agent-0.12.1.2-2.355)?
Does oVirt create a virtio-serial port to communicate with libvit and
does it use libvirt with any options to quiesce fs on guest?
Can one use as an alternative the command fsfreeze in CentOS 6.4 guest
(even if in tech preview) as in :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Lin...
Gianluca
3:53 a.m.
On 04/19/2013 11:46 AM, Gianluca Cecchi wrote:
On Fri, Apr 19, 2013 at 9:58 AM, Itamar Heim wrote:
>
> qemu-guest-agent isn't ovirt/rhev-guest-agent.
> now that qemu started their own guest agent, ovirt/rhev-guest-agent isn't
> used for things covered by the qemu-guest-agent.
Ah, ok.
SO after reading
http://wiki.libvirt.org/page/Qemu_guest_agent
some questions
can we use ootb qemu-guest-agent with ovirt 3.2.1 if we have for
example a CentOS 6 guest (with qemu-guest-agent-0.12.1.2-2.355)?
Does oVirt create a virtio-serial port to communicate with libvit and
does it use libvirt with any options to quiesce fs on guest?
iirc, it should work - testing/feedback would be welcome.
Can one use as an alternative the command fsfreeze in CentOS 6.4 guest
(even if in tech preview) as in :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Lin...
what i remember is that it supposed to be pluggable/configurable for you
to run the relevant commands you want.
ayal may remember better
7:42 a.m.
----- Original Message -----
On 04/19/2013 11:46 AM, Gianluca Cecchi wrote:
> On Fri, Apr 19, 2013 at 9:58 AM, Itamar Heim wrote:
>
>>
>> qemu-guest-agent isn't ovirt/rhev-guest-agent.
>> now that qemu started their own guest agent, ovirt/rhev-guest-agent isn't
>> used for things covered by the qemu-guest-agent.
>
> Ah, ok.
> SO after reading
> http://wiki.libvirt.org/page/Qemu_guest_agent
> some questions
>
> can we use ootb qemu-guest-agent with ovirt 3.2.1 if we have for
> example a CentOS 6 guest (with qemu-guest-agent-0.12.1.2-2.355)?
> Does oVirt create a virtio-serial port to communicate with libvit and
> does it use libvirt with any options to quiesce fs on guest?
iirc, it should work - testing/feedback would be welcome.
I believe vdsm does not create the virtio-serial port when starting the VM, so you'd
have to modify this behaviour with hooks [1].
Once you do that, whenever you create a live snapshot vdsm will notify libvirt to quiesce
first.
Note that afaik, quiesce in qemu-ga is only supported for Linux guests. VSS quiesce
support patches have been submitted, but I'm not sure what the status is there yet.
[1] Hooks preso: http://www.ovirt.org/File:OVirt-hooks-netapp-jan2013.odp
>
> Can one use as an alternative the command fsfreeze in CentOS 6.4 guest
> (even if in tech preview) as in :
>
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Lin...
>
what i remember is that it supposed to be pluggable/configurable for you
to run the relevant commands you want.
ayal may remember better
2:31 a.m.
--_000_5F9E965F5A80BC468BE5F40576769F0925511BC1exchange21_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
c8O2biAyMDEzLTA0LTIxIGtsb2NrYW4gMDg6NDIgLTA0MDAgc2tyZXYgQXlhbCBCYXJvbjoNCg0K
DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gT24gMDQvMTkvMjAxMyAxMTo0NiBB
TSwgR2lhbmx1Y2EgQ2VjY2hpIHdyb3RlOg0KPiA+IE9uIEZyaSwgQXByIDE5LCAyMDEzIGF0IDk6
NTggQU0sIEl0YW1hciBIZWltIHdyb3RlOg0KPiA+DQo+ID4+DQo+ID4+IHFlbXUtZ3Vlc3QtYWdl
bnQgaXNuJ3Qgb3ZpcnQvcmhldi1ndWVzdC1hZ2VudC4NCj4gPj4gbm93IHRoYXQgcWVtdSBzdGFy
dGVkIHRoZWlyIG93biBndWVzdCBhZ2VudCwgb3ZpcnQvcmhldi1ndWVzdC1hZ2VudCBpc24ndA0K
PiA+PiB1c2VkIGZvciB0aGluZ3MgY292ZXJlZCBieSB0aGUgcWVtdS1ndWVzdC1hZ2VudC4NCj4g
Pg0KPiA+IEFoLCBvay4NCj4gPiBTTyBhZnRlciByZWFkaW5nDQo+ID4gaHR0cDovL3dpa2kubGli
dmlydC5vcmcvcGFnZS9RZW11X2d1ZXN0X2FnZW50DQo+ID4gc29tZSBxdWVzdGlvbnMNCj4gPg0K
PiA+IGNhbiB3ZSB1c2Ugb290YiBxZW11LWd1ZXN0LWFnZW50IHdpdGggb3ZpcnQgMy4yLjEgaWYg
d2UgaGF2ZSBmb3INCj4gPiBleGFtcGxlIGEgQ2VudE9TIDYgZ3Vlc3QgKHdpdGggcWVtdS1ndWVz
dC1hZ2VudC0wLjEyLjEuMi0yLjM1NSk/DQo+ID4gRG9lcyBvVmlydCBjcmVhdGUgYSB2aXJ0aW8t
c2VyaWFsIHBvcnQgdG8gY29tbXVuaWNhdGUgd2l0aCBsaWJ2aXQgYW5kDQo+ID4gZG9lcyBpdCB1
c2UgbGlidmlydCB3aXRoIGFueSBvcHRpb25zIHRvIHF1aWVzY2UgIGZzIG9uIGd1ZXN0Pw0KPg0K
PiBpaXJjLCBpdCBzaG91bGQgd29yayAtIHRlc3RpbmcvZmVlZGJhY2sgd291bGQgYmUgd2VsY29t
ZS4NCg0KSSBiZWxpZXZlIHZkc20gZG9lcyBub3QgY3JlYXRlIHRoZSB2aXJ0aW8tc2VyaWFsIHBv
cnQgd2hlbiBzdGFydGluZyB0aGUgVk0sIHNvIHlvdSdkIGhhdmUgdG8gbW9kaWZ5IHRoaXMgYmVo
YXZpb3VyIHdpdGggaG9va3MgWzFdLg0KT25jZSB5b3UgZG8gdGhhdCwgd2hlbmV2ZXIgeW91IGNy
ZWF0ZSBhIGxpdmUgc25hcHNob3QgdmRzbSB3aWxsIG5vdGlmeSBsaWJ2aXJ0IHRvIHF1aWVzY2Ug
Zmlyc3QuDQpOb3RlIHRoYXQgYWZhaWssIHF1aWVzY2UgaW4gcWVtdS1nYSBpcyBvbmx5IHN1cHBv
cnRlZCBmb3IgTGludXggZ3Vlc3RzLg0KDQoNClJlYWxseSBjb29sIHRvIGhlYXIgaG93IHRoaW5n
cyBhcmUgcHJvZ3Jlc3NpbmchIFRoZSBxZW11LWdhIHF1aWVzY2VzIHdoYXQgZXhhY3RseT8gVGhl
IGd1ZXN0IGZpbGVzeXN0ZW0/IFdoYXQgYWJvdXQgcG90ZW50aWFsIGFwcGxpY2F0aW9ucyB0aGF0
IG1pZ2h0IGJlIHJ1bm5pbmcgaW5zaWRlIHRoZSBndWVzdD8gQ2FuIHlvdSBjYWxsIGxpdmUgc25h
cHNob3RzIG9mIGEgbGludXggZ3Vlc3QgIkFwcGxpY2F0aW9uIENvbnNpc3RlbnQiPw0KDQpUaGUg
Z29vZCB0aGluZyBhYm91dCBNaWNyb3NvZnQgVlNTIGlzIHRoYXQgTVMgYXBwbGljYXRpb25zIGFy
ZSByZWdpc3RlcmVkIHRvIFZTUyBzbyB0aGF0IHdoZW4geW91IHRyaWdnZXIgVlNTIHRvIHF1aWVj
ZSwgYWxsIG9mIHRoZSBvdGhlciBhcHBsaWNhdGlvbnMgYXJlIHRvbGQgdG8gcGF1c2UgYXMgd2Vs
bC4NCg0KL0thcmxpDQoNCg0KDQpWU1MgcXVpZXNjZSBzdXBwb3J0IHBhdGNoZXMgaGF2ZSBiZWVu
IHN1Ym1pdHRlZCwgYnV0IEknbSBub3Qgc3VyZSB3aGF0IHRoZSBzdGF0dXMgaXMgdGhlcmUgeWV0
Lg0KDQpbMV0gSG9va3MgcHJlc286IGh0dHA6Ly93d3cub3ZpcnQub3JnL0ZpbGU6T1ZpcnQtaG9v
a3MtbmV0YXBwLWphbjIwMTMub2RwDQoNCj4NCj4gPg0KPiA+IENhbiBvbmUgdXNlIGFzIGFuIGFs
dGVybmF0aXZlIHRoZSBjb21tYW5kIGZzZnJlZXplIGluIENlbnRPUyA2LjQgZ3Vlc3QNCj4gPiAo
ZXZlbiBpZiBpbiB0ZWNoIHByZXZpZXcpIGFzIGluIDoNCj4gPiBodHRwczovL2FjY2Vzcy5yZWRo
YXQuY29tL3NpdGUvZG9jdW1lbnRhdGlvbi9lbi1VUy9SZWRfSGF0X0VudGVycHJpc2VfTGludXgv
Ni9odG1sL1RlY2huaWNhbF9Ob3Rlcy9zdG9yYWdlLmh0bWwNCj4gPg0KPg0KPiB3aGF0IGkgcmVt
ZW1iZXIgaXMgdGhhdCBpdCBzdXBwb3NlZCB0byBiZSBwbHVnZ2FibGUvY29uZmlndXJhYmxlIGZv
ciB5b3UNCj4gdG8gcnVuIHRoZSByZWxldmFudCBjb21tYW5kcyB5b3Ugd2FudC4NCj4gYXlhbCBt
YXkgcmVtZW1iZXIgYmV0dGVyDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KVXNlcnMgbWFpbGluZyBsaXN0DQpVc2Vyc0BvdmlydC5vcmc8bWFpbHRv
OlVzZXJzQG92aXJ0Lm9yZz4NCmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5m
by91c2Vycw0KDQoNCi0tDQoNCk1lZCBWw6RubGlnYSBIw6Rsc25pbmdhcg0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KS2FybGkgU2rDtmJlcmcNClN3ZWRpc2ggVW5pdmVyc2l0eSBvZiBBZ3JpY3Vs
dHVyYWwgU2NpZW5jZXMNCkJveCA3MDc5IChWaXNpdGluZyBBZGRyZXNzIEtyb27DpXN2w6RnZW4g
OCkNClMtNzUwIDA3IFVwcHNhbGEsIFN3ZWRlbg0KUGhvbmU6ICArNDYtKDApMTgtNjcgMTUgNjYN
CmthcmxpLnNqb2JlcmdAc2x1LnNlPG1haWx0bzprYXJsaS5zam9iZXJnQGFkbS5zbHUuc2U+DQo=
--_000_5F9E965F5A80BC468BE5F40576769F0925511BC1exchange21_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv
L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv
bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii
IGNvbnRlbnQ9Ikd0a0hUTUwvNC40LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQpzw7ZuIDIwMTMtMDQt
MjEga2xvY2thbiAwODo0MiAtMDQwMCBza3JldiBBeWFsIEJhcm9uOg0KPGJsb2NrcXVvdGUgdHlw
ZT0iQ0lURSI+DQo8cHJlPgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQomZ3Q7IE9uIDA0
LzE5LzIwMTMgMTE6NDYgQU0sIEdpYW5sdWNhIENlY2NoaSB3cm90ZToKJmd0OyAmZ3Q7IE9uIEZy
aSwgQXByIDE5LCAyMDEzIGF0IDk6NTggQU0sIEl0YW1hciBIZWltIHdyb3RlOgomZ3Q7ICZndDsK
Jmd0OyAmZ3Q7Jmd0OwomZ3Q7ICZndDsmZ3Q7IHFlbXUtZ3Vlc3QtYWdlbnQgaXNuJ3Qgb3ZpcnQv
cmhldi1ndWVzdC1hZ2VudC4KJmd0OyAmZ3Q7Jmd0OyBub3cgdGhhdCBxZW11IHN0YXJ0ZWQgdGhl
aXIgb3duIGd1ZXN0IGFnZW50LCBvdmlydC9yaGV2LWd1ZXN0LWFnZW50IGlzbid0CiZndDsgJmd0
OyZndDsgdXNlZCBmb3IgdGhpbmdzIGNvdmVyZWQgYnkgdGhlIHFlbXUtZ3Vlc3QtYWdlbnQuCiZn
dDsgJmd0OwomZ3Q7ICZndDsgQWgsIG9rLgomZ3Q7ICZndDsgU08gYWZ0ZXIgcmVhZGluZwomZ3Q7
ICZndDsgPGEgaHJlZj0iaHR0cDovL3dpa2kubGlidmlydC5vcmcvcGFnZS9RZW11X2d1ZXN0X2Fn
ZW50Ij5odHRwOi8vd2lraS5saWJ2aXJ0Lm9yZy9wYWdlL1FlbXVfZ3Vlc3RfYWdlbnQ8L2E+CiZn
dDsgJmd0OyBzb21lIHF1ZXN0aW9ucwomZ3Q7ICZndDsKJmd0OyAmZ3Q7IGNhbiB3ZSB1c2Ugb290
YiBxZW11LWd1ZXN0LWFnZW50IHdpdGggb3ZpcnQgMy4yLjEgaWYgd2UgaGF2ZSBmb3IKJmd0OyAm
Z3Q7IGV4YW1wbGUgYSBDZW50T1MgNiBndWVzdCAod2l0aCBxZW11LWd1ZXN0LWFnZW50LTAuMTIu
MS4yLTIuMzU1KT8KJmd0OyAmZ3Q7IERvZXMgb1ZpcnQgY3JlYXRlIGEgdmlydGlvLXNlcmlhbCBw
b3J0IHRvIGNvbW11bmljYXRlIHdpdGggbGlidml0IGFuZAomZ3Q7ICZndDsgZG9lcyBpdCB1c2Ug
bGlidmlydCB3aXRoIGFueSBvcHRpb25zIHRvIHF1aWVzY2UgIGZzIG9uIGd1ZXN0PwomZ3Q7IAom
Z3Q7IGlpcmMsIGl0IHNob3VsZCB3b3JrIC0gdGVzdGluZy9mZWVkYmFjayB3b3VsZCBiZSB3ZWxj
b21lLgoKSSBiZWxpZXZlIHZkc20gZG9lcyBub3QgY3JlYXRlIHRoZSB2aXJ0aW8tc2VyaWFsIHBv
cnQgd2hlbiBzdGFydGluZyB0aGUgVk0sIHNvIHlvdSdkIGhhdmUgdG8gbW9kaWZ5IHRoaXMgYmVo
YXZpb3VyIHdpdGggaG9va3MgWzFdLgpPbmNlIHlvdSBkbyB0aGF0LCB3aGVuZXZlciB5b3UgY3Jl
YXRlIGEgbGl2ZSBzbmFwc2hvdCB2ZHNtIHdpbGwgbm90aWZ5IGxpYnZpcnQgdG8gcXVpZXNjZSBm
aXJzdC4KTm90ZSB0aGF0IGFmYWlrLCBxdWllc2NlIGluIHFlbXUtZ2EgaXMgb25seSBzdXBwb3J0
ZWQgZm9yIExpbnV4IGd1ZXN0cy4gCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KUmVhbGx5
IGNvb2wgdG8gaGVhciBob3cgdGhpbmdzIGFyZSBwcm9ncmVzc2luZyEgVGhlIHFlbXUtZ2EgcXVp
ZXNjZXMgd2hhdCBleGFjdGx5PyBUaGUgZ3Vlc3QgZmlsZXN5c3RlbT8gV2hhdCBhYm91dCBwb3Rl
bnRpYWwgYXBwbGljYXRpb25zIHRoYXQgbWlnaHQgYmUgcnVubmluZyBpbnNpZGUgdGhlIGd1ZXN0
PyBDYW4geW91IGNhbGwgbGl2ZSBzbmFwc2hvdHMgb2YgYSBsaW51eCBndWVzdCAmcXVvdDtBcHBs
aWNhdGlvbiBDb25zaXN0ZW50JnF1b3Q7Pzxicj4NCjxicj4NClRoZSBnb29kIHRoaW5nIGFib3V0
IE1pY3Jvc29mdCBWU1MgaXMgdGhhdCBNUyBhcHBsaWNhdGlvbnMgYXJlIHJlZ2lzdGVyZWQgdG8g
VlNTIHNvIHRoYXQgd2hlbiB5b3UgdHJpZ2dlciBWU1MgdG8gcXVpZWNlLCBhbGwgb2YgdGhlIG90
aGVyIGFwcGxpY2F0aW9ucyBhcmUgdG9sZCB0byBwYXVzZSBhcyB3ZWxsLg0KPGJyPg0KPGJyPg0K
L0thcmxpPGJyPg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iQ0lURSI+DQo8cHJlPgpWU1MgcXVp
ZXNjZSBzdXBwb3J0IHBhdGNoZXMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCwgYnV0IEknbSBub3Qgc3Vy
ZSB3aGF0IHRoZSBzdGF0dXMgaXMgdGhlcmUgeWV0LiAKClsxXSBIb29rcyBwcmVzbzogPGEgaHJl
Zj0iaHR0cDovL3d3dy5vdmlydC5vcmcvRmlsZTpPVmlydC1ob29rcy1uZXRhcHAtamFuMjAxMy5v
ZHAiPmh0dHA6Ly93d3cub3ZpcnQub3JnL0ZpbGU6T1ZpcnQtaG9va3MtbmV0YXBwLWphbjIwMTMu
b2RwPC9hPgoKJmd0OyAKJmd0OyAmZ3Q7CiZndDsgJmd0OyBDYW4gb25lIHVzZSBhcyBhbiBhbHRl
cm5hdGl2ZSB0aGUgY29tbWFuZCBmc2ZyZWV6ZSBpbiBDZW50T1MgNi40IGd1ZXN0CiZndDsgJmd0
OyAoZXZlbiBpZiBpbiB0ZWNoIHByZXZpZXcpIGFzIGluIDoKJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0
dHBzOi8vYWNjZXNzLnJlZGhhdC5jb20vc2l0ZS9kb2N1bWVudGF0aW9uL2VuLVVTL1JlZF9IYXRf
RW50ZXJwcmlzZV9MaW51eC82L2h0bWwvVGVjaG5pY2FsX05vdGVzL3N0b3JhZ2UuaHRtbCI+aHR0
cHM6Ly9hY2Nlc3MucmVkaGF0LmNvbS9zaXRlL2RvY3VtZW50YXRpb24vZW4tVVMvUmVkX0hhdF9F
bnRlcnByaXNlX0xpbnV4LzYvaHRtbC9UZWNobmljYWxfTm90ZXMvc3RvcmFnZS5odG1sPC9hPgom
Z3Q7ICZndDsKJmd0OyAKJmd0OyB3aGF0IGkgcmVtZW1iZXIgaXMgdGhhdCBpdCBzdXBwb3NlZCB0
byBiZSBwbHVnZ2FibGUvY29uZmlndXJhYmxlIGZvciB5b3UKJmd0OyB0byBydW4gdGhlIHJlbGV2
YW50IGNvbW1hbmRzIHlvdSB3YW50LgomZ3Q7IGF5YWwgbWF5IHJlbWVtYmVyIGJldHRlcgomZ3Q7
IApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpVc2VycyBt
YWlsaW5nIGxpc3QKPGEgaHJlZj0ibWFpbHRvOlVzZXJzQG92aXJ0Lm9yZyI+VXNlcnNAb3ZpcnQu
b3JnPC9hPgo8YSBocmVmPSJodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8v
dXNlcnMiPmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VyczwvYT4K
PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8dGFibGUgY2VsbHNwYWNpbmc9IjAiIGNlbGxw
YWRkaW5nPSIwIiB3aWR0aD0iMTAwJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQ+LS0gPGJyPg0KPGJy
Pg0KTWVkIFbDpG5saWdhIEjDpGxzbmluZ2FyPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi
cj4NCkthcmxpIFNqw7ZiZXJnPGJyPg0KU3dlZGlzaCBVbml2ZXJzaXR5IG9mIEFncmljdWx0dXJh
bCBTY2llbmNlczxicj4NCkJveCA3MDc5IChWaXNpdGluZyBBZGRyZXNzIEtyb27DpXN2w6RnZW4g
OCk8YnI+DQpTLTc1MCAwNyBVcHBzYWxhLCBTd2VkZW48YnI+DQpQaG9uZTogJm5ic3A7JiM0Mzs0
Ni0oMCkxOC02NyAxNSA2Njxicj4NCjxhIGhyZWY9Im1haWx0bzprYXJsaS5zam9iZXJnQGFkbS5z
bHUuc2UiPmthcmxpLnNqb2JlcmdAc2x1LnNlPC9hPiA8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8
L3RhYmxlPg0KPC9ib2R5Pg0KPC9odG1sPg0K
--_000_5F9E965F5A80BC468BE5F40576769F0925511BC1exchange21_--
4:14 a.m.
----- Original Message -----
sön 2013-04-21 klockan 08:42 -0400 skrev Ayal Baron:
----- Original Message -----
> On 04/19/2013 11:46 AM, Gianluca Cecchi wrote:
> > On Fri, Apr 19, 2013 at 9:58 AM, Itamar Heim wrote:
> >
> >>
> >> qemu-guest-agent isn't ovirt/rhev-guest-agent.
> >> now that qemu started their own guest agent, ovirt/rhev-guest-agent
> >> isn't
> >> used for things covered by the qemu-guest-agent.
> >
> > Ah, ok.
> > SO after reading
> > http://wiki.libvirt.org/page/Qemu_guest_agent
> > some questions
> >
> > can we use ootb qemu-guest-agent with ovirt 3.2.1 if we have for
> > example a CentOS 6 guest (with qemu-guest-agent-0.12.1.2-2.355)?
> > Does oVirt create a virtio-serial port to communicate with libvit and
> > does it use libvirt with any options to quiesce fs on guest?
>
> iirc, it should work - testing/feedback would be welcome.
I believe vdsm does not create the virtio-serial port when starting the VM,
so you'd have to modify this behaviour with hooks [1].
Once you do that, whenever you create a live snapshot vdsm will notify
libvirt to quiesce first.
Note that afaik, quiesce in qemu-ga is only supported for Linux guests.
Really cool to hear how things are progressing! The qemu-ga quiesces what
exactly? The guest filesystem? What about potential applications that might
Yes, it quiesces xfs/ext3/ext4 (I don't recall wrt btrfs) file systems.
be running inside the guest? Can you call live snapshots of a linux
guest
"Application Consistent"?
Linux has no such infrastructure atm. There are upstream patches for qemu-ga to support
calling hooks before and after quiesce to allow users to freeze their apps so that the
snapshot would be application consistent. This will require users to place their scripts
inside the guest of course.
The good thing about Microsoft VSS is that MS applications are registered to
VSS so that when you trigger VSS to quiece, all of the other applications
are told to pause as well.
Indeed, there have been many discussions around this and there is a lot of interest around
this topic, but I haven't seen any accepted solution as of yet.
/Karli
VSS quiesce support patches have been submitted, but I'm not sure what the
status is there yet.
[1] Hooks preso: http://www.ovirt.org/File:OVirt-hooks-netapp-jan2013.odp
>
> >
> > Can one use as an alternative the command fsfreeze in CentOS 6.4 guest
> > (even if in tech preview) as in :
> >
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Lin...
> >
>
> what i remember is that it supposed to be pluggable/configurable for you
> to run the relevant commands you want.
> ayal may remember better
>
_______________________________________________
Users mailing list
Users@ovirt.org<mailto:Users@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users
--
Med Vänliga Hälsningar
-------------------------------------------------------------------------------
Karli Sjöberg
Swedish University of Agricultural Sciences
Box 7079 (Visiting Address Kronåsvägen 8)
S-750 07 Uppsala, Sweden
Phone: +46-(0)18-67 15 66
karli.sjoberg@slu.se<mailto:karli.sjoberg@adm.slu.se>
4184
days inactive
4239
days old
12 comments
6 participants
participants (6)
-
Ayal Baron -
Gianluca Cecchi -
Itamar Heim -
Jiri Belka -
Karli Sjöberg -
Ricky Schneberger