원시 이미지는 다음과 같이 VMDK 이미지로 변환될 수 있습니다 qemu-img.
qemu-img convert -O vmdk "$_raw" "$_vmdk"
생성된 VMDK 이미지의 UUID는 다음을 사용하여 설정할 수 있다는 것을 알고 있습니다.
VBoxManage internalcommands sethduuid "$_vmdk" "$_uuid"
변환할 때 디스크의 UUID를 설정하는 방법이 있습니까 qemu-img(이 솔루션이 FreeBSD에서 작동한다면 좋을 것입니다)?
답변1
이 대답은 내 머리에서 나온 것이며아니요테스트되었습니다. 테스트해 보시면 답변을 업데이트해 주시기 바랍니다.
불행하게도 이 질문에는 우리가 이 일을 하는 이유를 설명하는 맥락이 거의 없습니다. 표면적으로는 다음을 참조할 수 있습니다.qemu-img대답은 '아니요'입니다.
그러나 그것은 지루할 것입니다. 대신, 몇 가지 말도 안되는 가정을 하고 실행해 봅시다.
설명하는 솔루션은 qemu-imgFreeBSD 에서 가능합니다.에뮬레이터/qemu-utilsvboxmanage는 다음에서 비롯됩니다.에뮬레이터/가상박스-ose. 아마 그게 당신이 하고 있는 일이겠죠? 그러나 이것이 왜 문제인지는 말하지 않았습니다(단지 하나의 도구를 덜 사용하고 싶습니까?).
흥미롭게도 이것은 단지 힌트일 뿐입니다.GUID 파티션 테이블(GPT)디스크에. qemu-img디스크에 무엇이 있는지는 별로 신경쓰지 마세요. 하지만 vboxmanage도우미 기능만 있으면 충분합니다.
디스크로
/dev/ada0따라서 as의 전체 원본 복사본(또는 Qemu에서 생성된 원본 파일)이 있는 경우 ada0.dd해당 이미지를 가상 메모리 디스크로 사용할 수 있습니다.
# mdconfig -a -t vnode -u 0 -f /home/johndoe/ada0.dd
/dev/md0그러면 완전한 디스크가 제공됩니다 .
그러면 모든 것이 잘 보이는지 확인할 수 있습니다.
# fdisk /dev/md0
이것은 이전 디스크와 정확히 같아야 합니다.
# glabel status
GPT를 사용할 때 다음을 선호할 수 있습니다.gpart
# gpart create -s gpt /dev/md0
UUID는 이 명령을 사용하여 자동으로 생성됩니다. 실제로 파티션 테이블의 항목에 닿는지는 알 수 없습니다. 이런 경우에는 먼저 백업을 하시기 바랍니다. 어쩌면 전체 테이블을 파괴할 수도 있습니다. 생성한 다음 복원하시겠습니까? 여기서 몇 가지 테스트를 수행해야 합니다. 하지만 중요한 점은 이제 드라이브에 대한 전체 액세스 권한이 있다는 것입니다.
다음을 사용하여 파일 시스템을 마운트할 수 있습니다.이 방법게다가
파일로
GUID 파티션 테이블 회로도를 살펴보면위키피디아파티션 테이블 헤더의 오프셋 56에서 혼합 엔디안 디스크 GUID를 찾았다고 들었습니다.
따라서 디스크 이미지를 마운트하는 대신 간단히 바이트 묶음으로 생각할 수 있습니다. 512바이트 섹터를 사용한다고 가정하지만 4K 섹터에 맞게 조정해야 할 수도 있습니다. 헤더는 LBA 1에 있고 오프셋 56에 관심이 있습니다. 따라서 512 + 56 = 568입니다.
$ hexdump -v -s 568 -n 16 -e '1/1 "%.2x\n"' /home/johndoe/ada0.dd
그런 다음 필요한 바이트만 간단히 변경할 수 있습니다. Hexdump로는 충분하지 않습니다. 살펴봐야 합니다.xxd함께 제공편집/vim.우이데겐올바른 GUID를 생성하는 데 도움이 될 수 있습니다.
이 경로로 이동하는 경우 다음 사항에 유의하세요.
- 무엇이든 작성하기 전에 "EFI PART" 서명을 확인하여 스크립트의 탄력성을 확보하세요.
- 또한 수정해야 하는 헤더의 보조 복사본도 있다는 점을 기억하세요(오프셋 32를 통해 찾으세요).
이것은 재미있는 작은 스크립트가 될 것입니다.
스트림 미디어
나는 당신이 정말로 원하는 것이 원본 원시 이미지를 원래 상태로 유지하고 즉석에서 작업을 수행하는 것이라는 은밀한 의심을 가지고 있습니다. 우리는 부분적으로 xxd지원을 제공 stdin하여 stdout파이프를 통해 연결할 수 있습니다. 불행하게도 그것은 qemu-img지원 처럼 보이지 않습니다 stdin.
그런 다음 디스크에 파일이 있어야 합니다. 실용적인 해결책은 원본 파일을 백업으로 유지하고 새 복사본을 사용하여 수정하는 것입니다. 이는 디스크 공간 비용만 증가시킵니다.
그러나 FreeBSD를 사용하면 디스크 공간을 절약하고 복사를 피할 수 있는 매우 빠른 방법이 있습니다. ZFS를 유리하게 사용할 수 있습니다. 새 데이터 세트를 생성하고 원본 이미지 파일을 여기에 배치한 후 스냅샷을 생성하면 됩니다. 그런 다음 파일을 직접 수정할 수 있지만 변경된 바이트(또는 변경된 섹터)에만 영향을 미칩니다. 완료되면 스냅샷을 롤백하여 해당 섹터를 신속하게 복원할 수 있습니다.
모든 것에 대한 스냅샷을 찍고 싶지 않기 때문에 특정 데이터세트를 만듭니다.
# zfs create zroot/rawfiles
필요한 데이터를 여기에 넣고 /rawfiles깨끗한 상태의 스냅샷을 만듭니다.
# zfs snapshot zroot/rawfiles@cleanstate
그런 다음 잠재적으로 큰 이미지 파일에서 몇 바이트를 수정할 수 있습니다. 깨끗한 상태로 돌아가고 싶을 때 롤백합니다.
# zfs rollback zroot/rawfiles@cleanstate
공간 제약이 있는 경우 이는 빠르고 실행 가능한 옵션입니다. 이와 같은 작업을 수행하는 경우 롤백을 계속할 경우 경쟁 조건에 유의하세요.
만약을 대비하여 이것을 백업으로 가지고 있다면 별도의 데이터 세트 생성을 건너뛰고 zfs snapshot zroot@hailmary문제가 발생하면 그냥 수행할 수 있습니다.cp /.zfs/snapshot/hailmary/......
수동
이미지 생성 프로세스에 영향을 미치는 경우 몇 가지 흥미로운 옵션도 있습니다.
qemu-img새 이미지를 생성하고 이를 탑재하고 GPT(새 GUID 포함)를 생성하는 데 사용할 수 있습니다 .
# qemu-img create -f raw VM10G.raw 10G
# mdconfig -a -t vnode -u 0 -f VM10G.raw
# gpart create -s gpt /dev/md0
하지만 파일일 뿐이므로 qemu-img.
# truncate -s 10g VM10G.raw
# mdconfig -a -t vnode -u 0 -f VM10G.raw
# gpart create -s gpt /dev/md0
내가 이걸 왜 보여주고 있지? 글쎄, 어쩌면 당신은 이런 맥락에서 뭔가를 하고 있을 수도 있습니다. FreeBSD에는 매우 영리한 트릭이 있습니다:므징가(1).
이를 사용하면 FreeBSD에서 디스크 이미지를 생성할 수 있으며 QCOW, QCOW2, 동적 VHD, 고정 VHD, VMDK 및 RAW를 지원합니다. 즉, VMDK로 직접 이동할 수 있습니다.
mkimg -f vmdk -s gpt -b /boot/pmbr -p freebsd-boot:=/boot/gptboot -p freebsd-ufs:=root-file-system.ufs -p freebsd-swap::1G -o gpt.vmdk
이 예는 FreeBSD 중심이지만 원시 파티션을 사용합니다. 따라서 원본 전체 디스크 이미지에서 파티션 전용 이미지로 소스를 변경하는 경우 작업 경로가 있어야 합니다.