QEMU / KVM이있는 드라이브의 요청되지 않은 섹터에 Windows VM 설치

하나의 500GB NVMe 드라이브가 있습니다. GPT를 사용하고 있으며 다음과 같은 파티션이 있습니다.

1G 의 ef00 / EFI System ...에 대한 /boot
4 세대 의 8200 / Linux swap
245G 의 8300 / Linux filesystem Linux 설치의 경우, 내 호스트 / 기본 운영 체제

나머지 드라이브, 250G 여유 공간입니다. 가능한 한 많은 오버 헤드를 피하면서 KVM으로 가상화 된 Windows 10 VM 용으로 사용하고 싶습니다. 나는 이것에 3 가지 접근법을 보았다.

하나의 큰 파티션이 있고 raw 그것에 이미지.
잠시만 기다려주세요. 8300 파티션을 만들고 KVM에 디스크로 전달합니다.
소프트웨어 RAID 속임수 (복잡성이 줄어 듭니다).

그러나 Windows 10 설치 프로그램이 특정 영역의 섹터에 대한 액세스 권한을 부여하고 실제 독립 실행 형 실제 드라이브 인 것처럼 가장하여 자유 공간 분할을 처리하도록 할 수있는 방법이 있습니까?

또는 Windows에 필요한 모든 파티션 (즉, 시스템 파티션, MSR, Windows 파티션 및 복구 도구 파티션)을 사전 할당하는 것은 불가능합니다 이리 ), 어떻게 든 KVM으로 전달할 수 있습니까?

내 이론을 제쳐두고 최고의 성능 우선 솔루션은 무엇입니까? 나는 이것을 잠시 봤지만 행운은 없었다. 적절한 일일이 언급하지 않고 일화일지도 모릅니다.

— Olegs Jeremejevs
소스

원시 파티션을 KVM에 장치로 제공하면 Windows Installer는이를 디스크로보고 파티션을 분할합니다. 그러나 다중 이미지 및 스냅 샷이 없으면 많은 유연성을 잃어 버릴 수 있습니다. 원시 파티션이 최선의 방법은 아닙니다.

— eckes

제 관심사는 불필요한 수준의 추상화입니다 : Windows 10은 파티션을 할당 할 것입니다. 내부 다른 파티션. 소개하는 오버 헤드가 얼마나되는지, 그리고이 추상화를 건너 뛸 수 있는지 여부를 알아 내려고 노력 중입니다.

— Olegs Jeremejevs

파티션은 오버 헤드가 없으며 기본적으로 장치 드라이버는 시작 / 중지 섹터 만 가져옵니다. 시행 레이어가 없습니다. 낭비되는 사소한 공간 일 뿐이지 만 주변에 길이 있는지 확실하지 않습니다. 그러나 복구 / 복구 파티션을 건너 뛸 수 있습니다.

— eckes

알았어, 정보 주셔서 감사합니다! 두 번째 파티션을 사용하겠습니다. 첫 번째 의견에서 메모에 대해 어떤 유연성에 대해 이야기하고 있습니까? VM의 이미지를 이동 / 크기 조정할 수 있습니까?

— Olegs Jeremejevs

주로 스냅 샷과 클론.

— eckes

따라서 고려해야 할 두 가지 수준이 있습니다. Windows 게스트에서 여러 파티션이있는 단일 시스템 드라이브를 사용하는 것이 아마도 가장 쉽습니다. 또한 파티션 테이블 (또는 동적 디스크 메타 데이터)이 기본적으로 섹터 오프셋의 매핑이기 때문에 오버 헤드가 적습니다.

호스트에서 실제 디스크, 디스크 파티션 또는 논리 볼륨에서 디스크를 제공 할 수 있습니다. 이 세 가지 옵션은 기본적으로 동일한 오버 헤드를 갖습니다 (무시할 수있는 섹터 오프셋 계산).

장치를 파일에 넣으면 오버 헤드는 파일 시스템 변환 계층을 거쳐야하기 때문에 조금 커집니다.

아마도 논리적 볼륨 또는 파일로 이동하여 여러 클론, 스냅 샷의 유연성 이점을 얻고 크기를 조정할 수 있습니다. 그것은 당신이하는 일에 달려 있습니다. 정기적으로 다른 소프트웨어 및 Windows 버전을 사용해보아야하는 경우 덜 정적 인 설정을 사용하는 것이 좋습니다. 고정 볼륨을 사용하면 호스트 파일 시스템을 피할 수있는 성능 이점을 얻을 수 있습니다.

— eckes
소스