JavaScript is required to for searching.
탐색 링크 건너뛰기
인쇄 보기 종료
Oracle VM Server for SPARC 3.0 관리 설명서     Oracle VM Server for SPARC (한국어)
search filter icon
search icon

문서 정보

머리말

제1부Oracle VM Server for SPARC 3.0 소프트웨어

1.  Oracle VM Server for SPARC 소프트웨어 개요

2.  소프트웨어 설치 및 사용

3.  Oracle VM Server for SPARC 보안

4.  서비스 및 컨트롤 도메인 설정

5.  게스트 도메인 설정

6.  I/O 도메인 설정

7.  가상 디스크 사용

8.  가상 네트워크 사용

9.  도메인 마이그레이션

10.  리소스 관리

11.  도메인 구성 관리

12.  기타 관리 작업 수행

제2부선택적 Oracle VM Server for SPARC 소프트웨어

13.  Oracle VM Server for SPARC Physical-to-Virtual 변환 도구

14.  Oracle VM Server for SPARC Configuration Assistant(Oracle Solaris 10)

15.  전원 관리 사용

16.  Oracle VM Server for SPARC Management Information Base 소프트웨어 사용

17.  Logical Domains Manager 검색

18.  Logical Domains Manager에서 XML 인터페이스 사용

XML 전송

XMPP 서버

로컬 연결

XML 프로토콜

요청 및 응답 메시지

요청 메시지

응답 메시지

이벤트 메시지

등록 및 등록 해제

<LDM_event> 메시지

이벤트 유형

도메인 이벤트

하드웨어 이벤트

진행률 이벤트

리소스 이벤트

모든 이벤트

Logical Domains Manager 작업

Logical Domains Manager 리소스 및 등록 정보

도메인 정보(ldom_info) 리소스

CPU(cpu) 리소스

MAU(mau) 리소스

메모리(memory) 리소스

가상 디스크 서버(vds) 리소스

가상 디스크 서버 볼륨(vds_volume) 리소스

디스크(disk) 리소스

가상 스위치(vsw) 리소스

네트워크(network) 리소스

가상 콘솔 집중기(vcc) 리소스

변수(var) 리소스

물리적 I/O 장치(physio_device) 리소스

SP 구성(spconfig) 리소스

DRM 정책 구성(policy) 리소스

가상 데이터 플레인 채널 서비스(vdpcs) 리소스

가상 데이터 플레인 채널 클라이언트(vdpcc) 리소스

콘솔(console) 리소스

도메인 마이그레이션

XML 스키마

용어집

색인

XML 프로토콜

통신 초기화가 완료되면 Logical Domains에서 정의한 XML 메시지가 전송됩니다. 다음 두 가지 유형의 XML 메시지가 있습니다.

요청 및 응답 메시지

Logical Domains에 대한 XML 인터페이스는 두 가지 형식입니다.

이 두 형식은 여러 가지 공통 XML 구조를 공유하지만, 두 형식의 차이점을 보다 잘 이해할 수 있도록 여기서는 개별적으로 설명합니다.

요청 메시지

가장 기본적인 레벨의 Logical Domains Manager로 들어오는 XML 요청에는 단일 객체에 대해 작동하는 단일 명령에 대한 설명이 포함됩니다. 보다 복잡한 요청은 여러 개의 명령과 명령당 여러 개의 객체를 처리할 수 있습니다. 기본 XML 명령의 구조는 다음과 같습니다.

예 18-1 단일 객체에 대해 작동하는 단일 명령의 형식

<LDM_interface version="1.3">
  <cmd>
    <action>Place command here</action>
    <options>Place options for certain commands here</options>
    <arguments>Place arguments for certain commands here</arguments>
    <data version="3.0">
      <Envelope>
        <References/>
        <!-- Note a <Section> section can be here instead of <Content> -->
        <Content xsi:type="ovf:VirtualSystem_Type" id="Domain name">
          <Section xsi:type="ovf:ResourceAllocationSection_type">
            <Item>
              <rasd:OtherResourceType>LDom Resource Type</rasd:OtherResourceType>
              <gprop:GenericProperty
              key="Property name">Property Value</gprop:GenericProperty>
            </Item>
          </Section>
          <!-- Note: More Sections sections can be placed here -->
        </Content>
      </Envelope>
    </data>
    <!-- Note: More Data sections can be placed here -->
  </cmd>
  <!-- Note: More Commands sections can be placed here -->
</LDM_interface>
<LDM_interface> 태그

Logical Domains Manager로 전송되는 모든 명령은 <LDM_interface> 태그로 시작해야 합니다. Logical Domains Manager로 전송되는 모든 문서는 <LDM_interface> 태그를 한 개만 포함해야 합니다. <LDM_interface> 태그에는 예 18-1에 표시된 것과 같이 버전 속성이 포함되어야 합니다.

<cmd> 태그

<LDM_interface> 태그 내에서 문서는 <cmd> 태그를 적어도 한 개 포함해야 합니다. 각 <cmd> 섹션에는 <action> 태그가 한 개만 있어야 합니다. <action> 태그는 실행할 명령을 설명하는 데 사용됩니다. 각 <cmd> 태그는 명령이 작동할 객체를 설명하는 <data> 태그를 적어도 한 개 포함해야 합니다.

<cmd> 태그는 일부 명령과 연관된 옵션과 플래그에 사용되는 <options> 태그도 포함할 수 있습니다. 옵션을 사용하는 명령은 다음과 같습니다.

다음 XML 예제 조각은 재부트 메시지가 포함된 재부트 요청을 stop-domain 하위 명령으로 전달하는 방법을 보여줍니다.

<action>stop-domain</action>
<arguments>
    <reboot/>
    <message>my reboot message</message>
</arguments>
<data> 태그

<data> 섹션은 지정된 명령과 관련된 객체에 대한 설명을 포함할 수 있습니다. 데이터 섹션의 형식은 OVF(Open Virtualization Format) 드래프트 사양의 XML 스키마 부분을 토대로 합니다. 해당 스키마는 <References> 태그(Logical Domains에서 사용하지 않음)와 <Content><Section> 섹션을 포함하는 <Envelope> 섹션을 정의합니다.

Logical Domains의 경우, <Content> 섹션은 특정 도메인을 식별하고 설명하는 데 사용됩니다. <Content> 노드의 id= 속성에 있는 도메인 이름으로 도메인을 식별합니다. <Content> 섹션 내에는 특정 명령에 필요한 도메인의 리소스를 설명하는 하나 이상의 <Section> 섹션이 있습니다.

도메인 이름만 식별해야 하는 경우에는 <Section> 태그를 사용할 필요가 없습니다. 반대로, 명령에 도메인 식별자가 필요하지 않은 경우 명령에 필요한 리소스를 설명하는 <Section> 섹션을 <Content> 섹션 외부에 제공할 필요는 없지만, <Envelope> 섹션 내에는 제공해야 합니다.

객체 정보를 추론할 수 있는 경우 <data> 섹션은 <Envelope> 태그를 포함할 필요가 없습니다. 이러한 상황은 작업에 해당하는 모든 객체를 모니터링하는 요청, 이벤트 등록 및 등록 해제 요청에 주로 적용됩니다.

OVF 사양의 스키마를 사용하여 모든 유형의 객체를 적절하게 정의할 수 있으려면 다음 두 가지의 OVF 유형을 추가로 정의해야 합니다.

<gprop:GenericProperty> 태그는 OVF 사양에 정의가 없는 객체 등록 정보를 처리하기 위해 정의되었습니다. 등록 정보 이름은 노드의 key= 속성에 정의되며 등록 정보 값은 노드 컨텐츠입니다. <binding> 태그는 다른 리소스에 바인드된 리소스를 정의하기 위해 ldm list-bindings 하위 명령 출력에 사용됩니다.

응답 메시지

발신 XML 응답은 포함된 명령과 객체의 관점에서 수신 요청의 구조와 일치하지만, 요청에 대한 전체 <Response> 섹션과 지정된 각 객체와 명령에 대한 <Response> 섹션이 추가됩니다. <Response> 섹션은 예 18-2에 설명된 것과 같이 상태 및 메시지 정보를 제공합니다. 기본 XML 요청에 대한 응답의 구조는 다음과 같습니다.

예 18-2 단일 객체에 대해 작동하는 단일 명령에 대한 응답의 형식

<LDM_interface version="1.3">
  <cmd>
    <action>Place command here</action>
    <data version="3.0">
      <Envelope>
        <References/>
        <!-- Note a <Section> section can be here instead of <Content> -->
        <Content xsi:type="ovf:VirtualSystem_Type" id="Domain name">
          <Section xsi:type="ovf:ResourceAllocationSection_type">
            <Item>
              <rasd:OtherResourceType>
                LDom Resource Type
              </rasd:OtherResourceType>
              <gprop:GenericProperty
              key="Property name">
                Property Value
            </gprop:GenericProperty>
            </Item>
          </Section>
          <!-- Note: More <Section> sections can be placed here -->
        </Content>
      </Envelope>
      <response>
        <status>success or failure</status>
        <resp_msg>Reason for failure</resp_msg>
      </response>
    </data>
    <!-- Note: More Data sections can be placed here -->
    <response>
      <status>success or failure</status>
      <resp_msg>Reason for failure</resp_msg>
    </response>
  </cmd>
  <!-- Note: More Command sections can be placed here -->
  <response>
    <status>success or failure</status>
    <resp_msg>Reason for failure</resp_msg>
  </response>
</LDM_interface>
전체 응답

<response> 섹션은 <LDM_interface> 섹션의 직속 하위로, 전체 요청의 전반적인 성공 또는 실패를 나타냅니다. 수신 XML 문서의 형식이 잘못된 경우가 아니라면 <response> 섹션에는 <status> 태그만 포함됩니다. 이 응답 상태가 성공을 나타낸다면 모든 객체에 대한 모든 명령이 성공한 것입니다. 이 응답 상태가 실패이고 <resp_msg> 태그가 없는 경우 원래 요청에 포함된 명령 중 하나가 실패한 것입니다. <resp_msg> 태그는 XML 문서 자체와 관련된 문제를 설명하는 데만 사용됩니다.

명령 응답

<cmd> 섹션 아래에 있는 <response> 섹션은 사용자에게 특정 명령의 성공이나 실패에 대해 알립니다. <status> 태그는 명령의 성공 또는 실패 여부를 표시합니다. 전체 응답의 경우와 마찬가지로, 명령이 실패하면 요청의 <cmd> 섹션 컨텐츠의 형식이 잘못된 경우 <response> 섹션에는 <resp_msg> 태그만 포함됩니다. 그렇지 않은 경우 실패 상태는 명령이 실행된 객체 중 하나에서 오류가 발생했음을 의미합니다.

객체 응답

끝으로, <cmd> 섹션에 있는 각 <data> 섹션에도 <response> 섹션이 있습니다. 이 섹션에는 특정 객체에 대해 실행된 명령이 성공 또는 실패했는지 여부가 표시됩니다. 응답 상태가 SUCCESS일 경우, <response> 섹션에 <resp_msg> 태그가 없습니다. 상태가 FAILURE일 경우, 객체에 대해 명령을 실행 중일 때 발생한 오류에 따라 <response> 필드에 <resp_msg> 태그가 하나 이상 있습니다. 객체 오류는 명령 실행 시 발견된 문제 또는 형식이 잘못되었거나 알 수 없는 객체로 인해 발생할 수 있습니다.

<data> 섹션은 <response> 섹션 이외에 다른 정보를 포함할 수 있습니다. 이 정보는 오류가 발생한 객체를 설명하는 수신 <data> 필드와 같은 형식으로 되어 있습니다. <data> 태그를 참조하십시오. 이 추가 정보는 특히 다음과 같은 경우에 유용합니다.