In a traditional VMM the virtual hardware exposed is functionally identical to the underlying machine [38]. Although full virtualization has the obvious benefit of allowing unmodified operating systems to be hosted, it also has a number of drawbacks. This is particularly true for the prevalent IA-32, or x86, architecture.
전통적으로 가상 하드웨어와 맞물리는 VMM은 하단부의 머신과 기능적으로 일치합니다. 전체 가상화(full virtualization)는 호스트 되는 운영체제를 수정하지 않아도 되는 분명한 이점이 있음에도 불구하고, 몇가지 결점을 가지고 있습니다. 이것은 일반적인 IA-32나 x86 아키텍쳐에서 특히 그렇습니다.
Support for full virtualization was never part of the x86 architectural design. Certain supervisor instructions must be handled by the VMM for correct virtualization, but executing these with insufficient privilege fails silently rather than causing a convenient trap [36]. Efficiently virtualizing the x86 MMU is also difficult. These problems can be solved, but only at the cost of increased complexity and reduced performance. VMware's ESX Server [10] dynamically rewrites portions of the hosted machine code to insert traps wherever VMM intervention might be required. This translation is applied to the entire guest OS kernel (with associated translation, execution, and caching costs) since all non-trapping privileged instructions must be caught and handled. ESX Server implements shadow versions of system structures such as page tables and maintains consistency with the virtual tables by trapping every update attempt -- this approach has a high cost for update-intensive operations such as creating a new application process.
전체 가상화(full virtualization)을 위한 지원은 결코 x86 아키텍처 디자인의 일부가 아닙니다. 특정 슈퍼바이저 명령어들은 정확한 가상화를 위해 VMM에 의해서만 처리되어야 하지만, 편리한 트랩 [36] 발생보다 차라리 부족한 특권으로 수행되는 것. x86 MMU의 효과적인 가상화는 매우 어렵습니다. 이 문제들은 해결될 수 있지만, 복잡성이 증가하고 성능이 감소하는 대가를 지불해야 합니다. VMware의 ESX Server [10]는 VMM이 중재를 요청할 경우에 트랩을 삽입하여 호스트되는 머신 코드의 일부를 동적으로 다시 씁니다. 이런 번역 작업은 잡아내고 처리해야하는 모든 트랩하지 않는 특권 명령어들 때문에 온전한 게스트 운영체제 커널(관련 번역, 실행, 캐싱 가격과 함께)이 적용됩니다. ESX Server는 페이지 테이블과 같은 시스템 구조의 그림자 버전 역할을 수행하고 가상 테이블로 결합도를 유지합니다. -- 이 접근법은 새로운 응용 프로세스의 생성과 같은 강력한 업데이트 운영을 위한 높은 비용을 가집니다.
Notwithstanding the intricacies of the x86, there are other arguments against full virtualization. In particular, there are situations in which it is desirable for the hosted operating systems to see real as well as virtual resources: providing both real and virtual time allows a guest OS to better support time-sensitive tasks, and to correctly handle TCP timeouts and RTT estimates, while exposing real machine addresses allows a guest OS to improve performance by using superpages [30] or page coloring [24].
Notwithstanding the intricacies of the x86, there are other arguments against full virtualization. In particular, there are situations in which it is desirable for the hosted operating systems to see real as well as virtual resources: providing both real and virtual time allows a guest OS to better support time-sensitive tasks, and to correctly handle TCP timeouts and RTT estimates, while exposing real machine addresses allows a guest OS to improve performance by using superpages [30] or page coloring [24].
그럼에도 불구의 복잡 x86, 거기에는 다른 인수 전체 가상화 반대합니다. 특히,이 경우에 해당되는 것이 바람직하다 호스팅 운영 체제에 대한 실제뿐만 아니라 가상 리소스를 참조하십시오 : 현실과 가상 시간을 제공하는 양쪽 손님 운영 체제를 사용 시간 - 민감한 작업을보다 효과적으로 지원하고, 올바르게 처리할 tcp 시간 초과가와 rtt 견적을 노출하는 동안 실제 머신 주소를 사용하면 성능 향상을 위해 게스트 운영 체제 superpages [30]을 사용하여 페이지 또는 착색 [24].
We avoid the drawbacks of full virtualization by presenting a virtual machine abstraction that is similar but not identical to the underlying hardware -- an approach which has been dubbed paravirtualization [43]. This promises improved performance, although it does require modifications to the guest operating system. It is important to note, however, that we do not require changes to the application binary interface (ABI), and hence no modifications are required to guest applications.
전체 가상화의 결점을 프리젠 테이션으로 우리가 피할의 가상 머신 추상화가 동일합니다 비슷하지만 기본 하드웨어 - 한 접근법 불리는해온 paravirtualization [43]. 이 약속을 향상된 성능, 비록 사용자의 운영 체제에 변경 사항이 필요합니다. 그것은 중요하게 참고 : 그러나, 우리가 필요하지 않은 응용 프로그램에 변경 내용을 바이너리 인터페이스 (아비), 그리고 필요에 따라서 사용자 응용 프로그램을 수정해야 할 것들이 없다.
We distill the discussion so far into a set of design principles:
1. Support for unmodified application binaries is essential, or users will not transition to Xen. Hence we must virtualize all architectural features required by existing standard ABIs.
2. Supporting full multi-application operating systems is important, as this allows complex server configurations to be virtualized within a single guest OS instance.
3. Paravirtualization is necessary to obtain high performance and strong resource isolation on uncooperative machine architectures such as x86.
4. Even on cooperative machine architectures, completely hiding the effects of resource virtualization from guest OSes risks both correctness and performance.
우리는 지금까지의 논의를 일련의 디자인 원칙으로 제정합니다 :
1. 수정되지 않은 응용 프로그램 바이너리에 대한 지원이 필수적이고, 사용자는 Xen을 변경하지 않는다. 따라서 우리는 존재하는 표준 ABI들이 요구하는 모든 아키텍쳐적인 기능을 가상화 해야한다.
1. 수정되지 않은 응용 프로그램 바이너리에 대한 지원이 필수적이고, 사용자는 Xen을 변경하지 않는다. 따라서 우리는 존재하는 표준 ABI들이 요구하는 모든 아키텍쳐적인 기능을 가상화 해야한다.
2. full muliti-application 운영체제를 지원하는 것은 중요합니다. 이렇게하면 복잡한 서버 구성도 단일 게스트 운영 체제 인스턴스로 가상화 되어집니다.
3. paravirtualization은 x86과 같은 비협조적인 머신 아키텍쳐 상에서 높은 성능을 얻고 리소스 분리도를 강화하기 위해 필요합니다.
4. 비협조적인 머신 아키텍쳐라도, 게스트 운영체제들로부터 리소스 가상화의 효과를 완벽하게 숨기는 것은 정확성과 성능에 위험합니다.
3. paravirtualization은 x86과 같은 비협조적인 머신 아키텍쳐 상에서 높은 성능을 얻고 리소스 분리도를 강화하기 위해 필요합니다.
4. 비협조적인 머신 아키텍쳐라도, 게스트 운영체제들로부터 리소스 가상화의 효과를 완벽하게 숨기는 것은 정확성과 성능에 위험합니다.
Note that our paravirtualized x86 abstraction is quite different from that proposed by the recent Denali project [44]. Denali is designed to support thousands of virtual machines running network services, the vast majority of which are small-scale and unpopular. In contrast, Xen is intended to scale to approximately 100 virtual machines running industry standard applications and services. Given these very different goals, it is instructive to contrast Denali's design choices with our own principles.
참고 : 우리가 x86 추상화는 매우 다르다 paravirtualized 최근의 차의 프로젝트가 제안한 [44]. 차의는 수천 개의 가상 머신을 지원하도록 설계된 네트워크 서비스를 실행 중 대부분이 중소 - 규모와 인기가합니다. 반면, xen는 규모가 약 100 가상 머신을 실행하기위한 업계 표준 응용 프로그램과 서비스를합니다. 이러한 매우 다른 목표, 그것은 우리의 교육에 대비 차의의 디자인 선택하고 자신의 원칙을합니다.
Firstly, Denali does not target existing ABIs, and so can elide certain architectural features from their VM interface. For example, Denali does not fully support x86 segmentation although it is exported (and widely used1) in the ABIs of NetBSD, Linux, and Windows XP.
첫째로, 기존의 abis 차의 타겟팅하지 않으면, 그래서 특정 건축 기능을 elide 수있습니다 그들의 vm 인터페이스를합니다. 예를 들어, x86 세그먼트화 차의 완벽하게 지원하지 않습니다 내보낸 것은의 (그리고 넓게 used1)에 abis netbsd, 리눅스, 그리고 windows xp.
Secondly, the Denali implementation does not address the problem of supporting application multiplexing, nor multiple address spaces, within a single guest OS. Rather, applications are linked explicitly against an instance of the Ilwaco guest OS in a manner rather reminiscent of a libOS in the Exokernel [23]. Hence each virtual machine essentially hosts a single-user single-application unprotected "operating system". In Xen, by contrast, a single virtual machine hosts a real operating system which may itself securely multiplex thousands of unmodified user-level processes. Although a prototype virtual MMU has been developed which may help Denali in this area [44], we are unaware of any published technical details or evaluation.
Secondly, the Denali implementation does not address the problem of supporting application multiplexing, nor multiple address spaces, within a single guest OS. Rather, applications are linked explicitly against an instance of the Ilwaco guest OS in a manner rather reminiscent of a libOS in the Exokernel [23]. Hence each virtual machine essentially hosts a single-user single-application unprotected "operating system". In Xen, by contrast, a single virtual machine hosts a real operating system which may itself securely multiplex thousands of unmodified user-level processes. Although a prototype virtual MMU has been developed which may help Denali in this area [44], we are unaware of any published technical details or evaluation.
둘째, 차의 구현을 지원 문제가 해결되지 않는 응용 프로그램을 멀티플렉싱, 지금도 여러 개의 주소를 공백, 단일 사용자 운영 체제 내에서합니다. 오히려, 응용 프로그램이 연결되어있는 ilwaco 게스트 운영 체제의 인스턴스를 명시적으로 반대하는 방식으로 libos에 다소의 추억 exokernel [23]. 따라서 호스트를 각각의 가상 머신 본질적으로 단일 - 사용자가 단일 - 응용 프로그램을 무방비 "운영 시스템"합니다. 에 xen, 반면에 진짜 운영 체제를 하나의 가상 머신 호스트 그 자체를 안전하게하는 데 수천 개의 수정되지 않은 다중 사용자 - 레벨 프로세스를합니다. 비록 가상 mmu 시제품 개발되었습니다 차의에이 지역에서 어떤 도움이 될 수도있습니다 [44], 우리는 어떤 출판 기술적인 세부 사항이나 평가를 인식하지 못하고합니다.
Thirdly, in the Denali architecture the VMM performs all paging to and from disk. This is perhaps related to the lack of memorymanagement support at the virtualization layer. Paging within the VMM is contrary to our goal of performance isolation: malicious virtual machines can encourage thrashing behaviour, unfairly depriving others of CPU time and disk bandwidth. In Xen we expect each guest OS to perform its own paging using its own guaranteed memory reservation and disk allocation (an idea previously exploited by self-paging [20]).
Thirdly, in the Denali architecture the VMM performs all paging to and from disk. This is perhaps related to the lack of memorymanagement support at the virtualization layer. Paging within the VMM is contrary to our goal of performance isolation: malicious virtual machines can encourage thrashing behaviour, unfairly depriving others of CPU time and disk bandwidth. In Xen we expect each guest OS to perform its own paging using its own guaranteed memory reservation and disk allocation (an idea previously exploited by self-paging [20]).
셋째, 차의 아키텍처를 호출하여 디스크에서 모든 vmm을 수행합니다. 이것은 아마도 memorymanagement와 관련이 부족 가상화 레이어를 지원합니다. 우리의 목표는 반대로 vmm 이내에 페이징의 성능을 고립 : 악의적인 가상 머신은 장려 춤 동작, 중앙 처리 장치를 불공정하게 시간을 다른 사람과 디스크 대역폭을 강탈합니다. 각 게스트 운영 체제에 xen 우리가 기대하는 자신의 페이징을 수행하려면 예약을 사용하여 자신의 보증 메모리 및 디스크 할당 (악용하는 아이디어가 이전에 자기 - 페이징 [20]).
Finally, Denali virtualizes the `namespaces' of all machine resources, taking the view that no VM can access the resource allocations of anotherVMif it cannot name them (for example, VMs have no knowledge of hardware addresses, only the virtual addresses created for them by Denali). In contrast, we believe that secure access control within the hypervisor is sufficient to ensure protection; furthermore, as discussed previously, there are strong correctness and performance arguments for making physical resources directly visible to guest OSes.
Finally, Denali virtualizes the `namespaces' of all machine resources, taking the view that no VM can access the resource allocations of anotherVMif it cannot name them (for example, VMs have no knowledge of hardware addresses, only the virtual addresses created for them by Denali). In contrast, we believe that secure access control within the hypervisor is sufficient to ensure protection; furthermore, as discussed previously, there are strong correctness and performance arguments for making physical resources directly visible to guest OSes.
마지막으로, 차의 virtualizes`네임 스페이스 '의 모든 시스템 자원을 복용 vm 안된다고보기에 액세스할 수있습니다 리소스 할당에 이름을 그들 anothervmif 수없습니다 (예를 들어, vms 하드웨어 주소에 대한 지식이 없다, 오직 그들을 위해 만들어진 가상 주소 차의). 반면, 우리가 보안 액세스 제어를 믿을 수 있도록 이내에 hypervisor는 충분히 보호; 또한, 논의한 이전에는 물리적 자원을 만들기위한 강력한 정확성과 성능을 인수 게스트 운영 체제를 직접 볼 수있습니다.
In the following section we describe the virtual machine abstraction exported by Xen and discuss how a guest OS must be modified to conform to this. Note that in this paper we reserve the term guest operating system to refer to one of the OSes that Xen can host and we use the term domain to refer to a running virtual machine within which a guest OS executes; the distinction is analogous to that between a program and a process in a conventional system. We call Xen itself the hypervisor since it operates at a higher privilege level than the supervisor code of the guest operating systems that it hosts.
In the following section we describe the virtual machine abstraction exported by Xen and discuss how a guest OS must be modified to conform to this. Note that in this paper we reserve the term guest operating system to refer to one of the OSes that Xen can host and we use the term domain to refer to a running virtual machine within which a guest OS executes; the distinction is analogous to that between a program and a process in a conventional system. We call Xen itself the hypervisor since it operates at a higher privilege level than the supervisor code of the guest operating systems that it hosts.
다음 섹션에서 Xen에서 파생된 가상 머신 추상화를 설명하고 게스트 운영체제가 이 규칙에 따라 어떻게 수정되어야 하는지 논의합니다. 참고로 이 논문에서 Xen으로 호스트할 수 있는 운영체제들 중의 하나를 언급하여 게스트 운영체제의 용어를 언급하고 게스트 운영체제 실행에서 가상 머신 수행을 언급하여 도메인 용어를 사용합니다; 이 특징은 관습적인 시스템에서 한 프로그램과 한 프로세스 사이에서는 유사합니다. 우리는 호스트 되는 게스트 운영체제의 슈퍼바이저 코드보다 더 높은 특권 레벨에서 운영되는 하이퍼바이저를 Xen이라고 부릅니다.
댓글 없음:
댓글 쓰기