단순 게스트 도메인의 외부 스냅샷

Question

2022년에도 내부 스냅샷은 수정되지 않았습니다. 유일한 해결책은 외부 스냅샷을 사용하는 것입니다. 자세한 내용은 다음을 방문하세요.KVM: libvirt 외부 스냅샷 생성 및 복원. 외부 스냅샷 예시에 대한 모든 크레딧은 다음으로 이동합니다.파비안 리.

단순 게스트 도메인의 외부 스냅샷

외부 스냅샷 만들기

게스트 도메인이 모든 것을 포함하는 단순 VM인 경우 <disk>아래와 type="file"같이 시작된 VM 상태(RAM 제외)의 외부 스냅샷을 생성합니다. 이 예에서는 하드 드라이브가 에 있고 hdaCD-ROM이 에 있다고 가정합니다 hdb.

# name of domain, snapshot, and target disk device
thedomain="mysimpledomain"
snapshotname="simple-test"
targetdisk="hda"

# look at '<disk>' types, should be just 'file' types
virsh dumpxml $thedomain | grep '<disk' -A5

# show block level devices and qcow2 paths (hda,hdb,..etc)
virsh domblklist $thedomain

# create snapshot in default pool location
# file name is $thedomain.$snapshotname
virsh snapshot-create-as $thedomain --name $snapshotname --disk-only

# list snapshot
virsh snapshot-list $thedomain

외부 스냅샷 복원

기본 메커니즘을 확인하고 스냅샷 복원을 위한 변수를 준비하려면 다음 명령을 실행하세요.

# notice path to hda has now changed to snapshot file
virsh domblklist $thedomain

# <source> has changed to snapshot file
virsh dumpxml $thedomain | grep '<disk' -A5

# pull default pool path from xml 
pooldir=$(virsh pool-dumpxml default | grep -Po "(?<=path\>)[^<]+")
echo "default pool dir: $pooldir"

# should see two files starting with $thedomain
# the one named $thedomain.$snapshotname is the snapshot
cd $pooldir
ls -latr $thedomain*

# snapshot points to backing file, which is original disk
sudo qemu-img info $thedomain.$snapshotname -U --backing-chain

# capture original backing file name so we can revert
backingfile=$(qemu-img info $thedomain.$snapshotname -U | grep -Po 'backing file:\s\K(.*)')
echo "backing file: $backingfile"

복원하려면 도메인 xml을 다시 원래 qcow2 파일로 수정하고, 스냅샷 메타데이터를 제거하고, 마지막으로 스냅샷 파일을 삭제해야 합니다.

# stop VM
virsh destroy $thedomain

# edit hda path back to original qcow2 disk
virt-xml $thedomain --edit target=$targetdisk --disk path=$backingfile --update

# validate that we are now pointing back at original qcow2 disk
virsh domblklist $thedomain

# delete snapshot metadata
virsh snapshot-delete --metadata $thedomain $snapshotname

# delete snapshot qcow2 file
sudo rm $pooldir/$thedomain.$snapshotname

# start guest domain
virsh start $thedomain

이제 게스트 도메인은 원래 상태에 있어야 합니다. 외부 스냅샷에 대한 자세한 내용은 위 링크를 참조하세요.

내부 스냅샷이 비활성화된 이유는 무엇입니까?

내부 스냅샷이 비활성화된 이유는 아래에서 확인할 수 있습니다. 이 주제를 검색하는 동안 찾은 최고의 답변 중 하나는 다음과 같습니다.이것:

2017년 9월 4일 월요일 오전 8시 30분 23초 -0700에 ovirt@xxxxxxxxxxxxxxxxx가 다음과 같이 썼습니다.

운영 체제: Fedora 26 + Virt-Manager v1.42 가상 머신: Win 10 UEFI + Q35

스냅샷 생성 중 오류 발생: 작업이 지원되지 않습니다. pflash 기반 펌웨어가 있는 VM의 내부 스냅샷은 지원되지 않습니다.

해결책이 있나요?

안녕하세요. 안타깝게도 그렇지 않으며 UEFI 게스트에 대한 스냅샷을 지원하는 데 다소 시간이 걸릴 수 있습니다.

문제는 내부 스냅샷이 오래되었고 외부 스냅샷에 있는 기능 중 많은 부분이 부족하다는 것입니다. 기본적으로 클라이언트 상태를 포함한 모든 것이 파일에 저장되는 디스크가 하나만 있는 클라이언트에서만 작동합니다.

이 문제를 해결하고 UEFI virt-manager를 사용하는 게스트에 대한 스냅샷을 찍으려면 외부 스냅샷을 사용하도록 전환해야 합니다. 이미 버그가 있습니다.삼. 그러나 libvirt에는 외부 스냅샷에 대한 일부 필수 기능이 여전히 부족하기 때문에 아직 수행할 수 없습니다. 예를 들어 외부 스냅샷으로 되돌릴 수 없어 사용할 수 없게 됩니다. libvirt의 구현에는 BUG도 있습니다.4.

파벨

삼 https://bugzilla.redhat.com/show_bug.cgi?id=1403951 4 https://bugzilla.redhat.com/show_bug.cgi?id=1402581

왜냐하면여기:

Re: [libvirt] [PATCH v2] qemu: snapshot: pflash 펌웨어를 사용하여 내부 스냅샷 비활성화
From: Laszlo Ersek <lersek redhat com>
To: Peter Krempa <pkrempa redhat com>
Cc: libvir-list redhat com
Subject: Re: [libvirt] [PATCH v2] qemu: snapshot: Forbid internal snapshots with pflash firmware
Date: Thu, 23 Mar 2017 17:49:56 +0100
2017년 3월 23일 15:07에 Peter Krempa는 다음과 같이 썼습니다.
2017년 3월 23일 목요일 11:03:02 +0100에 Laszlo Ersek이 썼습니다:

2017년 3월 23일 10:54에 Peter Krempa는 다음과 같이 썼습니다.

2017년 3월 23일 목요일 10:48:01 +0100에 Laszlo Ersek이 썼습니다:

2017년 3월 23일 10시 29분에 Peter Krempa는 다음과 같이 썼습니다.

변수 store() 파일이 원본인 경우 qemu는 이를 스냅샷할 수 없으므로 스냅샷이 불완전합니다. QEMU는 이러한 스냅샷을 거부하지 않습니다.

또한 qcow2 가변 저장소 지원 파일의 사용을 허용하면 이 문제가 해결되지만 메모리 덤프의 대상이 될 수 있습니다.

사용된 저장소 형식에 관계없이 이 경우 libvirt는 pflash 파일을 처리하지 않기 때문에 오프라인 내부 스냅샷은 불완전합니다.

문제를 방지하려면 이러한 스냅샷을 비활성화하세요.

[...]
@@ -13873,8 +13873,14 @@ qemuDomainSnapshotPrepare(virConnectPtr conn, 정리로 이동; }
/* qemu가 OVMF 로더를 사용하는 VM에서는 내부 스냅샷이 작동하지 않습니다.
* not snapshot the variable store */
/* 내부 스냅샷 + pflash 기반 로더에는 다음과 같은 문제가 있습니다.
* - if the variable store is raw, the snapshot is incomplete
* - alowing a qcow2 image as the varstore would make it eligible to receive
*   the vmstate dump, which would make it huge
* - offline snapshot would not snapshot the varstore at all
*
* Avoid the issues by forbidding this completely.
*/
나는 이것에 대해 더 많이 생각해 보았고 위의 문제에도 불구하고 Snapshot + OVMF 사용자가 이를 성공적으로 사용할 수 있다고 생각합니다. 위의 문제에도 불구하고 나쁜 점을 관찰하지 않았기 때문에 금지하면 다시 돌아오게 됩니다.

이유는 다음과 같습니다.

내부 스냅샷은 virt-manager의 기본값입니다.

게스트는 일반적으로 varstore를 자주 다시 작성하지 않으며 일반적으로 설치할 때만 다시 작성합니다.

운영 체제는 일반적으로 시작 항목을 제외하고는 아무것도 수정하지 않습니다.

온라인 VM의 스냅샷은 메모리 이미지에 varstore를 포함합니다.

운영 체제는 실패할 경우 시작 항목을 복원하는 데 매우 능숙합니다.

위의 사실로 인해 일부 사용자는 pflash 로더를 사용한 스냅샷이 예상대로 작동한다고 합법적으로 믿는 것 같습니다. 이는 주로 데이터가 매우 정적이고 운영 체제가 중요한 내용을 저장하지 않으며 자체적으로 일부 문제를 해결할 수 있기 때문입니다.

나는 유용성 손실을 피하기 위해 이것을 금지해야 한다고 생각하지 않습니다. 스냅샷이 안전하지 않다는 문서를 추가할 수 있습니다. 추가적으로, 현재 유사한 문제를 겪고 있는 외부 스냅샷에 대한 지원을 추가해야 합니다.
유효한 것처럼 보이지만 본질적으로 안전하지 않은 작업과 안전을 보장하는 명확한 오류 메시지 사이에는 균형이 있습니다.

UEFI 가변 저장소에는 언급한 것보다 더 많은 용도가 있습니다(중요도 내림차순).

특정 UEFI 변수(인증된 변수)에는 보안 관련 사항이 있습니다. 여기에는 보안 부팅을 위한 표준화된 키(플랫폼 키, 키 교환 키, 화이트리스트 인증서 및 서명(DB), 블랙리스트 인증서 및 서명(DBX))이 포함됩니다.

내가 아는 한, 여기에는 shim/MokManager("MOK"는 Machine Owner Key의 약어임)에서 사용하는 유사한 보안 관련 변수도 포함되어 있습니다. 즉, shim은 표준화된 보안 부팅 인터페이스에서 EFI 바이너리 확인을 위임합니다. 비휘발성 변수.

UEFI 변수는 Linux "pstore"(영구 저장소) 파일 시스템의 백엔드 역할을 할 수 있습니다. 그러면 충돌이 발생할 경우 Pstore를 사용하여 dmesg의 마지막 부분을 저장할 수 있습니다. 이 메시지는 새로 시작할 때 다시 읽을 수 있습니다.

펌웨어는 부팅할 때마다 내부적으로 여러 변수를 사용(읽기/쓰기)합니다. 이것들은 중요하지 않을 수도 있습니다. 한 가지 예는 일련의 부팅 프로세스 중에 UEFI 메모리 맵 조각화를 줄이는 데 도움이 되는 변수입니다.

OVMF는 bootindex 속성을 기반으로(또는 "bootorder" fw_cfg 파일을 더 직접적으로 기반으로) 부팅할 때마다 UEFI 부팅 옵션에서 작동합니다. 물론 이는 아마도 varstore 콘텐츠 중 가장 덜 위험한 범주일 것입니다.

나 자신은 varstore가 실제로 스냅샷을 생성한 적이 없다는 사실을 깨닫지 못한 채 OVMF 게스트의 내부 스냅샷(오프라인에만 해당)을 성공적으로 사용했지만 본질적으로 손실이 있는 작업을 자동으로 수행하는 데 매우 불편함을 느꼈습니다. 특히 varstore가 삭제될 가능성이 있는 경우 더욱 그렇습니다. 안전에 영향이 있습니다.

사용자는 문서를 읽지 않으며(절대 읽지 않습니다), 저는 모호한 보안 부팅 오작동에 대한 향후 버그 보고서를 제출하지 않는 것이 좋습니다.

이는 궁극적으로 libvirt 개발자에게 달려 있지만 제 생각에는 이런 종류의 안전하지 않은 작업을 계속 허용한다면 최소값은 다음과 같습니다.

virt-manager에서는 작업이 손실되고 보안에 영향을 미칠 수 있음을 명확하게 나타내는 추가 확인 대화 상자가 나타납니다.

virsh에서는 "--force" 또는 이와 유사한 옵션을 지정하지 않는 한 유사한 오류 메시지와 함께 작업을 거부합니다.

또한 다른 (독립적인) libvirt 클라이언트 애플리케이션이 있으므로 이를 제출한 클라이언트 애플리케이션에 관계없이 libvirt 자체가 안전하지 않은 스냅샷 요청을 거부할 수 있도록 libvirt API 수준에 새 플래그가 필요할 수 있습니다.

나는 유용성 회귀가 좋지 않으며 버그 보고서를 생성할 수 있다는 점에 동의합니다.만약에이는 보안 개선과 직접적으로 충돌하므로 보안 개선이 유용성 회귀보다 우선합니다. 사용자가 보안을 무시하도록 허용할 수는 있지만 그 자리에서 알림을 받고 동의해야 합니다.

이번 패치를 통해 앞으로 나아갈 수 있기를 바랍니다. 그러나 궁극적으로는 귀하에게 달려 있습니다.

감사해요! 라즐로

Answer 1

2022년에도 내부 스냅샷은 수정되지 않았습니다. 유일한 해결책은 외부 스냅샷을 사용하는 것입니다. 자세한 내용은 다음을 방문하세요.KVM: libvirt 외부 스냅샷 생성 및 복원. 외부 스냅샷 예시에 대한 모든 크레딧은 다음으로 이동합니다.파비안 리.

단순 게스트 도메인의 외부 스냅샷

외부 스냅샷 만들기

게스트 도메인이 모든 것을 포함하는 단순 VM인 경우 <disk>아래와 type="file"같이 시작된 VM 상태(RAM 제외)의 외부 스냅샷을 생성합니다. 이 예에서는 하드 드라이브가 에 있고 hdaCD-ROM이 에 있다고 가정합니다 hdb.

# name of domain, snapshot, and target disk device
thedomain="mysimpledomain"
snapshotname="simple-test"
targetdisk="hda"

# look at '<disk>' types, should be just 'file' types
virsh dumpxml $thedomain | grep '<disk' -A5

# show block level devices and qcow2 paths (hda,hdb,..etc)
virsh domblklist $thedomain

# create snapshot in default pool location
# file name is $thedomain.$snapshotname
virsh snapshot-create-as $thedomain --name $snapshotname --disk-only

# list snapshot
virsh snapshot-list $thedomain

외부 스냅샷 복원

기본 메커니즘을 확인하고 스냅샷 복원을 위한 변수를 준비하려면 다음 명령을 실행하세요.

# notice path to hda has now changed to snapshot file
virsh domblklist $thedomain

# <source> has changed to snapshot file
virsh dumpxml $thedomain | grep '<disk' -A5

# pull default pool path from xml 
pooldir=$(virsh pool-dumpxml default | grep -Po "(?<=path\>)[^<]+")
echo "default pool dir: $pooldir"

# should see two files starting with $thedomain
# the one named $thedomain.$snapshotname is the snapshot
cd $pooldir
ls -latr $thedomain*

# snapshot points to backing file, which is original disk
sudo qemu-img info $thedomain.$snapshotname -U --backing-chain

# capture original backing file name so we can revert
backingfile=$(qemu-img info $thedomain.$snapshotname -U | grep -Po 'backing file:\s\K(.*)')
echo "backing file: $backingfile"

복원하려면 도메인 xml을 다시 원래 qcow2 파일로 수정하고, 스냅샷 메타데이터를 제거하고, 마지막으로 스냅샷 파일을 삭제해야 합니다.

# stop VM
virsh destroy $thedomain

# edit hda path back to original qcow2 disk
virt-xml $thedomain --edit target=$targetdisk --disk path=$backingfile --update

# validate that we are now pointing back at original qcow2 disk
virsh domblklist $thedomain

# delete snapshot metadata
virsh snapshot-delete --metadata $thedomain $snapshotname

# delete snapshot qcow2 file
sudo rm $pooldir/$thedomain.$snapshotname

# start guest domain
virsh start $thedomain

이제 게스트 도메인은 원래 상태에 있어야 합니다. 외부 스냅샷에 대한 자세한 내용은 위 링크를 참조하세요.

내부 스냅샷이 비활성화된 이유는 무엇입니까?

내부 스냅샷이 비활성화된 이유는 아래에서 확인할 수 있습니다. 이 주제를 검색하는 동안 찾은 최고의 답변 중 하나는 다음과 같습니다.이것:

2017년 9월 4일 월요일 오전 8시 30분 23초 -0700에 ovirt@xxxxxxxxxxxxxxxxx가 다음과 같이 썼습니다.

운영 체제: Fedora 26 + Virt-Manager v1.42 가상 머신: Win 10 UEFI + Q35

스냅샷 생성 중 오류 발생: 작업이 지원되지 않습니다. pflash 기반 펌웨어가 있는 VM의 내부 스냅샷은 지원되지 않습니다.

해결책이 있나요?

안녕하세요. 안타깝게도 그렇지 않으며 UEFI 게스트에 대한 스냅샷을 지원하는 데 다소 시간이 걸릴 수 있습니다.

문제는 내부 스냅샷이 오래되었고 외부 스냅샷에 있는 기능 중 많은 부분이 부족하다는 것입니다. 기본적으로 클라이언트 상태를 포함한 모든 것이 파일에 저장되는 디스크가 하나만 있는 클라이언트에서만 작동합니다.

이 문제를 해결하고 UEFI virt-manager를 사용하는 게스트에 대한 스냅샷을 찍으려면 외부 스냅샷을 사용하도록 전환해야 합니다. 이미 버그가 있습니다.삼. 그러나 libvirt에는 외부 스냅샷에 대한 일부 필수 기능이 여전히 부족하기 때문에 아직 수행할 수 없습니다. 예를 들어 외부 스냅샷으로 되돌릴 수 없어 사용할 수 없게 됩니다. libvirt의 구현에는 BUG도 있습니다.4.

파벨

삼 https://bugzilla.redhat.com/show_bug.cgi?id=1403951 4 https://bugzilla.redhat.com/show_bug.cgi?id=1402581

왜냐하면여기:

Re: [libvirt] [PATCH v2] qemu: snapshot: pflash 펌웨어를 사용하여 내부 스냅샷 비활성화
From: Laszlo Ersek <lersek redhat com>
To: Peter Krempa <pkrempa redhat com>
Cc: libvir-list redhat com
Subject: Re: [libvirt] [PATCH v2] qemu: snapshot: Forbid internal snapshots with pflash firmware
Date: Thu, 23 Mar 2017 17:49:56 +0100
2017년 3월 23일 15:07에 Peter Krempa는 다음과 같이 썼습니다.
2017년 3월 23일 목요일 11:03:02 +0100에 Laszlo Ersek이 썼습니다:

2017년 3월 23일 10:54에 Peter Krempa는 다음과 같이 썼습니다.

2017년 3월 23일 목요일 10:48:01 +0100에 Laszlo Ersek이 썼습니다:

2017년 3월 23일 10시 29분에 Peter Krempa는 다음과 같이 썼습니다.

변수 store() 파일이 원본인 경우 qemu는 이를 스냅샷할 수 없으므로 스냅샷이 불완전합니다. QEMU는 이러한 스냅샷을 거부하지 않습니다.

또한 qcow2 가변 저장소 지원 파일의 사용을 허용하면 이 문제가 해결되지만 메모리 덤프의 대상이 될 수 있습니다.

사용된 저장소 형식에 관계없이 이 경우 libvirt는 pflash 파일을 처리하지 않기 때문에 오프라인 내부 스냅샷은 불완전합니다.

문제를 방지하려면 이러한 스냅샷을 비활성화하세요.

[...]
@@ -13873,8 +13873,14 @@ qemuDomainSnapshotPrepare(virConnectPtr conn, 정리로 이동; }
/* qemu가 OVMF 로더를 사용하는 VM에서는 내부 스냅샷이 작동하지 않습니다.
* not snapshot the variable store */
/* 내부 스냅샷 + pflash 기반 로더에는 다음과 같은 문제가 있습니다.
* - if the variable store is raw, the snapshot is incomplete
* - alowing a qcow2 image as the varstore would make it eligible to receive
*   the vmstate dump, which would make it huge
* - offline snapshot would not snapshot the varstore at all
*
* Avoid the issues by forbidding this completely.
*/
나는 이것에 대해 더 많이 생각해 보았고 위의 문제에도 불구하고 Snapshot + OVMF 사용자가 이를 성공적으로 사용할 수 있다고 생각합니다. 위의 문제에도 불구하고 나쁜 점을 관찰하지 않았기 때문에 금지하면 다시 돌아오게 됩니다.

이유는 다음과 같습니다.

내부 스냅샷은 virt-manager의 기본값입니다.

게스트는 일반적으로 varstore를 자주 다시 작성하지 않으며 일반적으로 설치할 때만 다시 작성합니다.

운영 체제는 일반적으로 시작 항목을 제외하고는 아무것도 수정하지 않습니다.

온라인 VM의 스냅샷은 메모리 이미지에 varstore를 포함합니다.

운영 체제는 실패할 경우 시작 항목을 복원하는 데 매우 능숙합니다.

위의 사실로 인해 일부 사용자는 pflash 로더를 사용한 스냅샷이 예상대로 작동한다고 합법적으로 믿는 것 같습니다. 이는 주로 데이터가 매우 정적이고 운영 체제가 중요한 내용을 저장하지 않으며 자체적으로 일부 문제를 해결할 수 있기 때문입니다.

나는 유용성 손실을 피하기 위해 이것을 금지해야 한다고 생각하지 않습니다. 스냅샷이 안전하지 않다는 문서를 추가할 수 있습니다. 추가적으로, 현재 유사한 문제를 겪고 있는 외부 스냅샷에 대한 지원을 추가해야 합니다.
유효한 것처럼 보이지만 본질적으로 안전하지 않은 작업과 안전을 보장하는 명확한 오류 메시지 사이에는 균형이 있습니다.

UEFI 가변 저장소에는 언급한 것보다 더 많은 용도가 있습니다(중요도 내림차순).

특정 UEFI 변수(인증된 변수)에는 보안 관련 사항이 있습니다. 여기에는 보안 부팅을 위한 표준화된 키(플랫폼 키, 키 교환 키, 화이트리스트 인증서 및 서명(DB), 블랙리스트 인증서 및 서명(DBX))이 포함됩니다.

내가 아는 한, 여기에는 shim/MokManager("MOK"는 Machine Owner Key의 약어임)에서 사용하는 유사한 보안 관련 변수도 포함되어 있습니다. 즉, shim은 표준화된 보안 부팅 인터페이스에서 EFI 바이너리 확인을 위임합니다. 비휘발성 변수.

UEFI 변수는 Linux "pstore"(영구 저장소) 파일 시스템의 백엔드 역할을 할 수 있습니다. 그러면 충돌이 발생할 경우 Pstore를 사용하여 dmesg의 마지막 부분을 저장할 수 있습니다. 이 메시지는 새로 시작할 때 다시 읽을 수 있습니다.

펌웨어는 부팅할 때마다 내부적으로 여러 변수를 사용(읽기/쓰기)합니다. 이것들은 중요하지 않을 수도 있습니다. 한 가지 예는 일련의 부팅 프로세스 중에 UEFI 메모리 맵 조각화를 줄이는 데 도움이 되는 변수입니다.

OVMF는 bootindex 속성을 기반으로(또는 "bootorder" fw_cfg 파일을 더 직접적으로 기반으로) 부팅할 때마다 UEFI 부팅 옵션에서 작동합니다. 물론 이는 아마도 varstore 콘텐츠 중 가장 덜 위험한 범주일 것입니다.

나 자신은 varstore가 실제로 스냅샷을 생성한 적이 없다는 사실을 깨닫지 못한 채 OVMF 게스트의 내부 스냅샷(오프라인에만 해당)을 성공적으로 사용했지만 본질적으로 손실이 있는 작업을 자동으로 수행하는 데 매우 불편함을 느꼈습니다. 특히 varstore가 삭제될 가능성이 있는 경우 더욱 그렇습니다. 안전에 영향이 있습니다.

사용자는 문서를 읽지 않으며(절대 읽지 않습니다), 저는 모호한 보안 부팅 오작동에 대한 향후 버그 보고서를 제출하지 않는 것이 좋습니다.

이는 궁극적으로 libvirt 개발자에게 달려 있지만 제 생각에는 이런 종류의 안전하지 않은 작업을 계속 허용한다면 최소값은 다음과 같습니다.

virt-manager에서는 작업이 손실되고 보안에 영향을 미칠 수 있음을 명확하게 나타내는 추가 확인 대화 상자가 나타납니다.

virsh에서는 "--force" 또는 이와 유사한 옵션을 지정하지 않는 한 유사한 오류 메시지와 함께 작업을 거부합니다.

또한 다른 (독립적인) libvirt 클라이언트 애플리케이션이 있으므로 이를 제출한 클라이언트 애플리케이션에 관계없이 libvirt 자체가 안전하지 않은 스냅샷 요청을 거부할 수 있도록 libvirt API 수준에 새 플래그가 필요할 수 있습니다.

나는 유용성 회귀가 좋지 않으며 버그 보고서를 생성할 수 있다는 점에 동의합니다.만약에이는 보안 개선과 직접적으로 충돌하므로 보안 개선이 유용성 회귀보다 우선합니다. 사용자가 보안을 무시하도록 허용할 수는 있지만 그 자리에서 알림을 받고 동의해야 합니다.

이번 패치를 통해 앞으로 나아갈 수 있기를 바랍니다. 그러나 궁극적으로는 귀하에게 달려 있습니다.

감사해요! 라즐로

단순 게스트 도메인의 외부 스냅샷

답변1

단순 게스트 도메인의 외부 스냅샷

외부 스냅샷 만들기

외부 스냅샷 복원

내부 스냅샷이 비활성화된 이유는 무엇입니까?

관련 정보