디지문닷넷 DigiMoon 맘대로 닦고 조이고 기름치는 재미가 있는 DigiMoon만의 기억 저장소

원문 링크:
http://kashyapc.com/2012/09/14/externaland-live-snapshots-with-libvirt/


External(and Live) snapshots with libvirt


Previously, I posted about snapshots here, which briefly discussed different types of snapshots. In this post, let's explore how external snapshots work. Just to quickly rehash, external snapshots are a type of snapshots where, there's a base image(which is the original disk image), and then its difference/delta (aka, the snapshot image) is stored in a new QCOW2 file. Once the snapshot is taken, the original disk image will be in a 'read-only' state, which can be used as backing file for other guests.
이전에, 나는 여기에 스냅샷에 관해 기고하였습니다. 이는 다른 종류의 스냅샷을 간략히 거론한 것이었습니다. 이 기고를 통해, external snapshot이 어떻게 동작하는지를 탐구해 봅시다. 단지 빠르게 다시 말하자면, external snapshot은 기본 이미지(그것은 오리지날 디스크 이미지)가 있는 스냅샷 종류입니다. 그리고 그러고나서 그것의 차이점/delta (일명, 스냅샷 이미지)은 새로운 QCOW2 파일에 저장되었습니다. 일단 스냅샷이 이루어지면,  오리지날 디스크 이미지는 'read-only' 상태로 들어갑니다. 이것은 다른 guest를 위한 기반 파일로 사용됩니다.

It's worth mentioning here that:
여기 언급하는 그것의 가치는:

    The original disk image can be either in RAW format or QCOW2 format. When a snapshot is taken, 'the difference' will be stored in a different QCOW2 file.
    그 오리지날 디스크 이미지는 RAW 포맷 또는 QCOW2 포맷 중 어느 한 쪽일 수 있습니다. 스냅샷이 실행되면, '그 차이점'은 다른 QCOW2 파일에 저장될 것입니다.

    The virtual machine has to be running, live. Also with Live snapshots, no guest downtime is experienced when a snapshot is taken.
    그 가상 머신은 실시간 실행 상태이어야 합니다. 또한 라이브 스냅샷과 함께, 스냅샷이 이루어질 때 다운타임이 발생하는 guest는 없습니다.

    At this moment, external(Live) snapshots work for 'disk-only' snapshots(and not VM state). Work for both disk and VM state(and also, reverting to external disk snapshot state) is in-progress upstream(slated for libvirt-0.10.2).
    이 순간, external(Live) snapshot은 'disk-only' 스냅샷(그리고 VM 상태가 아닌)을 위하여 동작합니다. 디스크와 VM 상태 모두를 위한 동작은 진행 중인 업스트림입니다(libvirt-0.10.2에서 도입 예정).

Before we go ahead, here's some version info, I'm testing on Fedora-17(host), and the guest(named 'daisy') is running Fedora-18(Test Compose):
우리가 진행하기 전에, 여기에 몇몇 버전 정보가 있습니다. 나는 Fedora-17(host)에서 테스트 중이고, guest('daisy'라 명명)는 Fedora-18(Test Compose)을 실행 중입니다.


External disk-snapshots(live) using QCOW2 as original image:
오리지날 이미지로 QCOW2를 사용하는 External disk-snapshots(live)

Let's see an illustration of external(live) disk-only snapshots. First, let's ensure the guest is running:
external(live) disk-only snapshot의 실례를 봅시다. 첫째, guest가 실행 중임을 확실히 합시다.


Then, list all the block devices associated with the guest:
그 때, guest에 관련된 모든 블록 장치들을 목록에 나열하시오:


Next, let's create a snapshot(disk-only) of the guest this way, while the guest is running:
다음으로, guest가 실행 중일 때, guest의 스냅샷(disk-only)을 이제 생성합시다.


Some details of the flags used:
사용되는 flag의 몇몇 세부사항:

- Passing a '--diskspec' parameter adds the 'disk' elements to the Snapshot XML file
- '--diskspec' 파라미터 전달은 스냅샷 XML 파일에 'disk' 요소를 추가합니다.

- '--disk-only' parameter, takes the snapshot of only the disk
- '--disk-only' 파라미터는 오직 디스크의 스냅샷에만 해당합니다.

- '--atomic' just ensures either the snapshot is run completely or fails w/o making any changes
- '--atomic'은 스냅샷이 완전히 실행되거나 어떤 변화를 만드는 w/o를 실패하는 것 중 한 가지를 보장합니다.

Let's check the information about the just taken snapshot by running qemu-img:
qemu-img 실행에 의해 수행된 스냅샷에 대한 정보를 체크해 봅시다.


Apart from the above, I created 2 more snapshots(just the same syntax as above) for illustration purpose. Now, the snapshot-tree looks like this:
이상의 사실을 제외하고, 실목적을 위해 나는 2개의 스냅샷(단지 위와 같은 동일 구문)을 더 생성하였습니다

For the above example image file chain[base<-snap1<-snap2<-snap3], it has to be read as - snap3 has snap2 as its backing file, snap2 has snap1 as its backing file, and snap1 has the base image as its backing file. We can see the backing file info from qemu-img:
위의 이미지 파일 사슬[base<-snap1<-snap2<-snap3] 예를 보면, snap3는 기반 파일로써 snap2를, snap2는 기반 파일로써 snap1을, snap1은 기반 파일로써 base 이미지를 갖는 것으로 보아야 합니다. 우리는 qemu-img로부터 기반 파일 정보를 볼 수 있습니다:




Now, if we do not need snap2 any more, and want to pull all the data from snap1 into snap3, making snap1 as snap3's backing file, we can do a virsh blockpull operation as below:
지금, 우리가 snap2를 더 이상 필요로 하지 않고, snap1로부터 snap3를 향해 모든 데이터를 끌어주기를 원한다면, snap1을 snap3의 기반 파일로 만드는 것으로, 우리는 아래와 같이 virsh blockpull 오퍼레이션을 할 수 있습니다.

Where, --path = path to the snapshot file, and --base = path to a backing file from which the data to be pulled. So from above example, it's evident that we're pulling the data from snap1 into snap3, and thus flattening the backing file chain resulting in snap1 as snap3's backing file, which can be noticed by running qemu-img again.
--path = 스냅샷 파일의 경로, --base = 데이터를 제공할 기반 파일 경로. 그러므로 위 예로부터, 우리가 snap1에서 snap3로 데이터를 끌어주고 있고, 그러므로 snap3의 기반 파일로써 snap1에서의 결과인 백업 파일 사슬을 단조롭게 하는 것은 분명히 나타납니다. 그것은 qemu-img 재실행으로 notice될 수 있습니다.

Thing to note here,
여기에 기록할 것,

A couple of things to note here, after discussion with Eric Blake(thank you):
여기에 기록할 한 쌍, Eric Blake(고마워)와의 토론:

- If we do a listing of the snapshot tree again(now that 'snap2-daisy.qcow2' backing file is no more in use),
- 만약 우리가 스냅샷 트리 목록을 다시 나열한다면(지금 'snap2-daisy.qcow2' 기반 파일이 더 이상 사용되지 않는)

one might wonder, why is snap3 still pointing to snap2? Thing to note here is, the above is the snapshot chain, which is independent from each virtual disk's backing file chain. So, the 'virsh snapshot-list' is still listing the information accurately at the time of snapshot creation(and not what we've done after creating the snapshot). So, from the above snapshot tree, if we were to revert to snap1 or snap2 (when revert-to-disk-snapshots is available), it'd still be possible to do that, meaning:
왜 snap3는 snap2를 여전히 가리키고 있는 것인지 궁금할 것입니다. 여기에 노트하는 것, 위의 것은 스냅샷 체인입니다. 이는 각 가상 디스크의 기반 파일 체인으로부터 독립적입니다. 그래서, 'virsh snapshot-list'는 스냅샷 생성 시점에(그리고 우리가 스냅샷 생성 이후에 하는 것이 아닌) 정확히 그 정보를 여전히 나열하고 있습니다.


It's possible to go from this state:
이 상태로부터 진행하는 것이 가능합니다:

base <- snap123 (data from snap1, snap2 pulled into snap3)
base <- snap123 (snap1로부터의 data, snap3를 향해 당겨진 snap2)

we can still revert to:
우리가 여전히 되돌릴 수 있는 것:

base<-snap1 (thus undoing the changes in snap2 & snap3)
base<-snap1 (예를 들면 snap2 & snap3에서 변경을 하지 않는 것)


External disk-snapshots(live) using RAW as original image:
오리지날 이미지인 RAW를 사용하는 External disk-snapshots(live)

With external disk-snapshots, the backing file can be RAW as well (unlike with 'internal snapshots' which only work with QCOW2 files, where the snapshots and delta are all stored in a single QCOW2 file)
external disk-snapshot과 함께, 기반 파일 또한 RAW가 될 수 있습니다. (오직 QCOW2 파일과 함께 동작하는, 스냅샷과 delta가 단일 QCOW2 파일에 모두 저장되는 곳인 'internal snapshots'과는 달리)

A quick illustration below. The commands are self-explanatory. It can be noted the change(from RAW to QCOW2) in the block disk associated with the guest, before & after taking the disk-snapshot (when virsh domblklist command was executed)
아래에 빠른 도해가 있습니다. 그 명령들은 설명이 필요합니다. guest에 관련된 블록 디스크에서 변경사항(RAW에서 QCOW2로)에서, 디스크 스냅샷 실행 전후(virsh domblklist 명령이 실행될 때)를 알 수 있습니다.

Also note: All snapshot XML files, where libvirt tracks the metadata of snapshots are are located under /var/lib/libvirt/qemu/snapshots/$guestname (and the original libvirt xml file is located under /etc/libvirt/qemu/$guestname.xml)
추가 노트: 모든 스냅샷 XML 파일들, libvirt가 스냅샷 메타데이터를 트랙하는 곳은 /var/lib/libvirt/qemu/snapshots/$guestname 아래에 위치하였습니다. (그리고 오리지날 libvirt xml 파일은 /etc/libvirt/qemu/$guestname.xml 내에 위치하였습니다)

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.