우리 회사는 독점 솔루션을 사용하여 새 VM 생성을 자동화해야 합니다. 이를 위해 우리는 표준화된 형식(OVA가 유일한 "표준"인 것 같습니다)으로 제품을 배송하거나 VM에서 변환할 수 있도록 하고 싶습니다. 동일한 시스템을 다양한 가상화 유형으로 전환합니다.
지금까지 이 작업은 수동으로 수행되었습니다. 즉, 클라이언트가 HyperV VM을 원하는 경우 내부에 있는 HyperV 서버, VMWare의 VMWare 등에서 이를 구축해야 함을 의미합니다. 우리의 목표는 이를 자동화하는 것입니다.
더 나은 설명: 계획은 KVM 서버를 보유하고 VM을 프로비저닝한 후 이를 OVA 형식으로 내보내는 것입니다. 그리고 아마도 고객이 선택한 하이퍼바이저에서 추가 예의로 사용할 수 있습니다.
"qemu-img 변환"을 사용하면 디스크를 제대로 변환할 수 있지만 다른 하이퍼바이저에서 필요에 따라 기계 정의(XML)를 다른 형식으로 변환할 수 없는 것 같습니다.
이에 대한 적절한 도구를 찾을 수 없습니다. 제안 사항이 있습니까?
참고: 이를 설치할 하이퍼바이저에 액세스할 수 없으므로 OVA/TAR 등으로 내보내야 합니다.
답변1
불행히도 OVA는 제공할 수 있는 것보다 훨씬 더 많은 것을 약속합니다. 기껏해야 디스크 이미지 배포를 위한 표준 형식이지만 디스크 이미지가 여러 하이퍼바이저에서 원활하게 부팅될 수 있도록 보장하는 역할은 거의 없습니다. 모든 하이퍼바이저는 서로 다른 가상 하드웨어 세트를 에뮬레이트하므로 게스트 OS에는 각 하이퍼바이저에 대해 서로 다른 드라이버를 설치해야 합니다. Linux와 같은 일부 운영 체제는 임의의 하드웨어로 부팅할 수 있고 찾은 것과 일치하는 드라이버를 자동 감지할 수 있다는 점에서 합리적으로 훌륭하지만, 심지어 망가지기 쉽기 때문에 고장이 납니다. 예를 들어 /etc/fstab"/"가 디스크에 있는 것으로 나열되는 경우 /dev/vda1(QEMU의 virtio-blk 디스크 드라이버의 경우) 로 표시되는 SCSI 디스크를 사용하여 VMWare에서 부팅할 때 작동하지 않습니다 /dev/sda1. Windows는 특정 드라이버를 각 디스크/NIC 등에 단단히 바인딩하는 것을 좋아하기 때문에 다양한 하드웨어에 적응하기가 정말 어렵습니다.
모든 하이퍼바이저에는 자체적으로 선호하는 디스크 이미지 형식이 있다는 문제도 있습니다. VMWare는 vmdk를 선호하고, QEMU는 raw 또는 qcow2를 이상적으로 선호하고, VirtualBox에는 다른 것이 있는 등의 문제가 있습니다. OVA는 이러한 어려운 문제를 해결하기 위해 아무 것도 하지 않습니다.
이러한 종류의 문제로 인해 virt-v2v(http://libguestfs.org/virt-v2v.1.html) 하나의 하이퍼바이저에 대한 디스크 이미지를 가져오고 동시에 디스크 형식을 변경하면서 다른 하이퍼바이저에서 작동하도록 게스트 OS를 재구성하는 방법이 있습니다.
모든 디스크에서 작동한다고 생각되는 디스크 이미지를 어떻게든 구축하더라도 전체 QA 테스트 주기를 거쳐 실제로 올바르게 작동하는지 확인해야 합니다.
IMHO 각 하이퍼바이저에 대한 전용 디스크 이미지를 구축하는 것이 훨씬 더 쉽습니다.