(0) 
(0)Posted by 삐꾸강아쥐
Trackback URL : http://blog.blog.n-nuri.com/trackback/582
The error "Setup is starting Windows" is a symptom of the Windows installer not recognizing the underlying HVM (hardware virtual machine), in particular the ACPI controller. However, these options don't work as expected if the guest OS is the 64bit version of Window XP or Windows Server 2003.
Currently, the version of XEN shipping with Red Hat Enterprise Linux 5 does not support 64bit installations of Windows XP and Windows Server 2003.
With 32 bit guests, either of the below will fix this issue:
The first option is during installation, when Windows says to press F6 to install additional drivers, press F5 instead of F6. This will then prompt the user to select the machine and ACPI controller type. Then from the next dialog box select "Standard PC" and continue the installation as usual.
The second method includes the known work around for Windows not seeing cdrom after first reboot as well as getting past the earlier error message.
Install Windows through virt-manager. When it starts installation of Windows, close the vnc console and run xm shutdown guest from a root console. In these examples, guest refers to the name of the guest in question.
Edit /etc/xen/guest and add the cdrom to the disk section. Change the following line:
disk = [ 'file:/var/lib/xen/images/guest,hda,w']
to
disk = ['file:/var/lib/xen/images/guest,hdx,w','phy:/dev/hdx,hdx:cdrom,r']
Replace /dev/hdx with the exact device of the system's cdrom or dvd drive. It can also be specified by file:/path/to/XP.iso for iso images.
Add boot = "d" under the disk section. Change acpi = 1 to acpi = 0. Lastly, run xm create guest.
After this, Windows XP should boot normally and not hang at "setup is starting Windows".
Remove the boot = "d" line from the configuration file before starting the machine on the first reboot.
(0) (0)Posted by 삐꾸강아쥐
Trackback URL : http://blog.blog.n-nuri.com/trackback/559
xm - Xen management user interface
xm <subcommand> [args]
The xm program is the main interface for managing Xen guest domains. The program can be used to create, pause, and shutdown domains. It can also be used to list current domains, enable or pin VCPUs, and attach or detach virtual block devices.
The basic structure of every xm command is almost always:
xm <subcommand> <domain-id> [OPTIONS]Where subcommand is one of the sub commands listed below, domain-id is the numeric domain id, or the domain name (which will be internally translated to domain id), and OPTIONS are sub command specific options. There are a few exceptions to this rule in the cases where the sub command in question acts on all domains, the entire machine, or directly on the xen hypervisor. Those exceptions will be clear for each of those sub commands.
All xm operations rely upon the Xen control daemon, aka xend. For any xm commands to run xend must also be running. For this reason you should start xend as a service when your system first boots using xen.
Most xm commands require root privileges to run due to the communications channels used to talk to the hypervisor. Running as non root will return an error.
Most xm commands act asynchronously, so just because the xm command returned, doesn't mean the action is complete. This is important, as many operations on domains, like create and shutdown, can take considerable time (30 seconds or more) to bring the machine into a fully compliant state. If you want to know when one of these actions has finished you must poll through xm list periodically.
The following sub commands manipulate domains directly, as stated previously most commands take domain-id as the first parameter.
This uses the back end xenconsole service which currently only works for para-virtual domains.
The attached console will perform much like a standard serial console, so running curses based interfaces over the console is not advised. Vi tends to get very odd when using it over this interface.
Configfile can either be an absolute path to a file, or a relative path to a file located in /etc/xen.
Create will return as soon as the domain is started. This does not mean the guest OS in the domain has actually booted, or is available for input.
OPTIONS
Attache console to the domain as soon as it has started. This is useful for determining issues with crashing domains.
xm create Fedora4This creates a domain with the file /etc/xen/Fedora4, and returns as soon as it is run.
xm create /dev/null ramdisk=initrd.img \ kernel=/boot/vmlinuz-2.6.12.6-xenU \ name=ramdisk nics=0 vcpus=1 \ memory=64 root=/dev/ram0This creates the domain without using a config file (more specifically using /dev/null as an empty config file), kernel and ramdisk as specified, setting the name of the domain to "ramdisk", also disabling virtual networking. (This example comes from the xm-test test suite.)
The --long option prints out the complete set of xm subcommands, grouped by function.
An example format for the list is as follows:
Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 98 1 r----- 5068.6 Fedora3 164 128 1 r----- 7.6 Fedora4 165 128 1 ------ 0.6 Mandrake2006 166 128 1 -b---- 3.6 Mandrake10.2 167 128 1 ------ 2.5 Suse9.2 168 100 1 ------ 1.8Name is the name of the domain. ID the domain numeric id. Mem is the size of the memory allocated to the domain. VCPUS is the number of VCPUS allocated to domain. State is the run state (see below). Time is the total run time of the domain as accounted for by Xen.
STATES
Note: there is no stable guarantees on the format of this data. Use at your own risk.
The mem-max value may not correspond to the actual memory used in the Domain, as it may balloon down it's memory to give more back to the OS .
Warning: there is no good way to know in advance how small of a mem-set will make a domain unstable and cause it to crash. Be very careful when using this command on running domains.
Migration is pretty complicated, and has many security implications, please read the Xen Users Guide to ensure you understand the ramifications and limitations on migration before attempting it in production.
OPTIONS
The behavior of what happens to a domain when it reboots is set by the on_reboot parameter of the xmdomain.cfg file when the domain was created.
OPTIONS
This is roughly equivalent to doing a hibernate on a running computer, with all the same limitations. Open network connections may be severed upon restore, as TCP timeouts may have expired.
The behavior of what happens to a domain when it reboots is set by the on_shutdown parameter of the xmdomain.cfg file when the domain was created.
OPTIONS
Shutdown all domains. Often used when doing a complete shutdown of a Xen system.
-w
Wait for the domain to complete shutdown before returning.
If the vcpu-count is smaller than the current number of active VCPUs, the highest number VCPUs will be hotplug removed. This may be important for pinning purposes.
Attempting to set the VCPUs to a number larger than the initially configured VCPU count is an error. Trying to set VCPUs to < 1 will be quietly ignored.
Normally VCPUs can float between available CPUs whenever Xen deems a different run state is appropriate. Pinning can be used to restrict this, by ensuring certain VCPUs can only run on certain physical CPUs.
dmesg [-c]
OPTIONS
Sample xen domain info looks as follows (lines wrapped manually to make the man page more readable):
host : talon
release : 2.6.12.6-xen0
version : #1 Mon Nov 14 14:26:26 EST 2005
machine : i686
nr_cpus : 2
nr_nodes : 1
sockets_per_node : 2
cores_per_socket : 1
threads_per_core : 1
cpu_mhz : 696
hw_caps : 0383fbff:00000000:00000000:00000040
total_memory : 767
free_memory : 37
xen_major : 3
xen_minor : 0
xen_extra : -devel
xen_caps : xen-3.0-x86_32
xen_pagesize : 4096
platform_params : virt_start=0xfc000000
xen_changeset : Mon Nov 14 18:13:38 2005 +0100
7793:090e44133d40
cc_compiler : gcc version 3.4.3 (Mandrakelinux
10.2 3.4.3-7mdk)
cc_compile_by : sdague
cc_compile_domain : (none)
cc_compile_date : Mon Nov 14 14:16:48 EST 2005
xend_config_format : 2FIELDS
Print out the xend log. This log file can be found in /var/log/xend.log.
top
Executes the xentop command, which provides real time monitoring of domains. Xentop is a curses interface, and reasonably self explanatory.
Most virtual devices can be added and removed while guests are running. The effect to the guest OS is much the same as any hotplug event.
BLOCK DEVICES
OPTIONS
This will mount the dsl iso as /dev/hdc in the guestdomain as a read only device. This will probably not be detected as a cdrom by the guest, but mounting /dev/hdc manually will work.
OPTIONS
Access Control in Xen consists of two components: (i) The Access Control Policy ( ACP ) defines security labels and access rules based on these labels. (ii) The Access Control Module ( ACM ) makes access control decisions by interpreting the policy when domains require to communicate or to access resources. The Xen access control has sufficient mechanisms in place to enforce the access decisions even against maliciously acting user domains (mandatory access control).
Access rights for domains in Xen are determined by the domain security label only and not based on the domain Name or ID . The ACP specifies security labels that can then be assigned to domains and resources. Every domain must be assigned exactly one security label, otherwise access control decisions could become indeterministic. ACPs are distinguished by their name, which is a parameter to most of the subcommands described below. Currently, the ACP specifies two ways to interpret labels:
(1) Simple Type Enforcement: Labels are interpreted to decide access of domains to comunication means and virtual or physical resources. Communication between domains as well as access to resources are forbidden by default and can only take place if they are explicitly allowed by the security policy. The proper assignment of labels to domains controls the sharing of information (directly through communication or indirectly through shared resources) between domains. This interpretation allows to control the overt (intended) communication channels in Xen.
(2) Chinese Wall: Labels are interpreted to decide which domains can co-exist (be run simultaneously) on the same system. This interpretation allows to prevent direct covert (unintended) channels and mitigates risks caused by imperfect core domain isolation (trade-off between security and other system requirements). For a short introduction to covert channels, please refer to http://www.multicians.org/timing-chn.html.
The following subcommands help you to manage security policies in Xen and to assign security labels to domains. To enable access control security in Xen, you must compile Xen with ACM support enabled as described under "Configuring Security" below. There, you will find also examples of each subcommand described here.
ACM_SECURITY ?= y
ACM_DEFAULT_SECURITY_POLICY ?= \
ACM_CHINESE_WALL_AND_SIMPLE_TYPE_ENFORCEMENT_POLICYThen recompile and install xen and the security tools and then reboot: cd xen_source_dir/xen; make clean; make; cp xen.gz /boot; cd xen_source_dir/tools/security; make install; reboot into xen
xm makepolicy example.chwall_ste.client_v1
xm loadpolicy example.chwall_ste.client_v1
xm cfgbootpolicy example.chwall_ste.client_v1
xm labels example.chwall_ste.client_v1 type=domwill print for our example policy:
dom_BoincClient dom_Fun dom_HomeBanking dom_NetworkDomain dom_StorageDomain dom_SystemManagement
We assume that the specified myconfig.xm configuration file actually instantiates a domain that runs workloads related to home-banking, probably just a browser environment for online-banking.
xm addlabel dom_HomeBanking dom myconfig.xmThe very simple configuration file might now look as printed below. The addlabel subcommand added the access_control entry at the end of the file, consisting of a label name and the policy that specifies this label name:
kernel = "/boot/vmlinuz-2.6.16-xen"
ramdisk="/boot/U1_home_banking_ramdisk.img"
memory = 164
name = "homebanking"
vif = [ '' ]
dhcp = "dhcp"
access_control = ['policy=example.chwall_ste.client_v1,
label=dom_HomeBanking']Security labels must be assigned to domain configurations because these labels are essential for making access control decisions as early as during the configuration phase of a newly instantiated domain. Consequently, a security-enabled Xen hypervisor will only start domains that have a security label configured and whose security label is consistent with the currently enforced policy. Otherwise, starting the domain will fail with the error condition "operation not permitted".
xm addlabel "res_LogicalDiskPartition1(hda1)" res phy:hda6After labeling this disk resource, it can be attached to the domain by adding a line to the domain configuration file. The line below attaches this disk to the domain at boot time.
disk = [ 'phy:hda6,sda2,w' ]Alternatively, the resource can be attached after booting the domain by using the block-attach subcommand.
xm block-attach homebanking phy:hda6 sda2 wNote that labeled resources cannot be used when security is turned off. Any attempt to use labeled resources with security turned off will result in a failure with a corresponding error message. The solution is to enable security or, if security is no longer desired, to remove the resource label using the rmlabel subcommand.
xm create myconfig.xm xm list --label Name ID ... Time(s) Label homebanking 23 ... 4.4 dom_HomeBanking Domain-0 0 ... 2658.8 dom_SystemManagementLISTING LABELED RESOURCES
xm resources
phy:hda6
policy: example.chwall_ste.client_v1
label: res_LogicalDiskPartition1(hda1)
file:/xen/disk_image/disk.img
policy: example.chwall_ste.client_v1
label: res_LogicalDiskPartition2(hda2)POLICY REPRESENTATIONS
The XML version is the version that users are supposed to create or change, either by manually editing the XML file or by using the Xen policy generation tool (xensec_gen). After changing the XML file, run the makepolicy subcommand to ensure that these changes are reflected in the other versions. Use, for example, the subcommand cfgbootpolicy to activate the changes during the next system reboot.
The binary version of the policy is derived from the XML policy by tokenizing the specified labels and is used inside Xen only. It is created with the makepolicy subcommand. Essentially, the binary version is much more compact than the XML version and is easier to evaluate during access control decisions.
The mapping version of the policy is created during the XML-to-binary policy translation (makepolicy) and is used by the Xen management tools to translate between label names used as input to the tools and their binary identifiers (ssidrefs) used inside Xen.
xmdomain.cfg(5), xentop(1)
Sean Dague <sean at dague dot net> Daniel Stekloff <dsteklof at us dot ibm dot com> Reiner Sailer <sailer at us dot ibm dot com>
(0) (0)Posted by 삐꾸강아쥐
Trackback URL : http://blog.blog.n-nuri.com/trackback/525
ex) my-script 를 실행 하였고...
정상적으로 보이지만 virt-manager - Connect host network 의
Shared physical device 에 장치가 올라오지 않을경우???
원인은 virt-manager 버그가 있습니다.
제가 관련하여 올렸던 글 이구요
http://www.linuxquestions.org/questions/linux-enterprise-47/help-me...-centos-5.1-on-xen-bridge-630203/
센트쪽에 이슈 등록이 되어 있는 부분 이네요
http://bugs.centos.org/view.php?id=2516
^^
아무쪼록... 저 같은 문제가 발생된분들이... 잘 해결 되시길...^^
첨부 1 : 파일 첨부 합니다. connection.py.patch 파일을 다운 받으셔서 connection.py 파일에 패치 하시면 됩니다.
(0) (0)Posted by 삐꾸강아쥐
Trackback URL : http://blog.blog.n-nuri.com/trackback/518
출처 :http://www-128.ibm.com/developerworks/kr/library/l-xen/Xen의 시대: 리눅스를 가상화 하여 애플리케이션 테스트하기샌드박스(sandbox)를 만들어 애플리케이션 관리하기  |  |
|
난이도 : 초급 Bryan Clark, Interaction Designer, Red Hat 2005 년 3 월 15 일 Xen은 리눅스 커널에서 사용할 수 있는 가상화 기술로서 원래 시스템에 피해를 주지 않고도 기존 환경에서 리눅스가 실행되는 것처럼 새로운 업그레이드를 마무리 및 테스트할 수 있는 기술이다. 이 글에서 Fedora Core를 사용하여 Xen을 설치하는 방법을 설명하겠다. 설치한 후에는 어느 배포판의 Xen이나 똑같이 작동된다. 리눅스의 가상화를 연구하고 새로운 소프트웨어의 테스트에 샌드박스를 사용할 때의 이점과 이 샌드박스를 같은 리눅스 박스에 여러 가상 머신들을 실행하는 장소로 사용하는 것에 대해 설명하겠다. 기존 소프트웨어의 꾸준한 향상과 버그 픽스(bug fixes)가 이루어지는 오픈 소스 세계는 유동적이다. 최첨단 소프트웨어 업그레이드는 전력 투구해야 하는 작업이다. 소프트웨어 업그레이드의 난점은 업그레이드가 완료된 후에 애플리케이션이 어떻게 작동할지 예상할 수 없다는 점이다. 대부분의 소프트웨어 패키징 시스템은 롤백(rollback) 기능을 제공하지만 이것으로 충분하지 않다. 새로운 업데이트들을 아무것에도 영향을 끼치지 않는 환경에서 테스트 및 실행해보는 것이 가장 이상적일 것이다. 운동장에 뛰노는 아이들처럼, 여러분에게도 마음껏 뛰놀 수 있는 샌드박스(sandbox)라는 것이 있다. 가상화(Virtualization)는 애플리케이션과 시스템을 같은 하드웨어에 있는 다른 것들과 분리시키는데 활용된다. 리눅스는 하드웨어 에뮬레이터(hardware emulators )부터 순수한 하드웨어 가상화까지 여러 가지 형태의 가상화를 지원한다. 최근 급부상하고 있는 기술이 캠브리지 대학교에서 개발한 Xen이다. Xen은 전대미문의 퍼포먼스와 보안성 때문에 주목을 끌고 있다. 캠브리지 대학교의 연구 프로젝트로 개발된 Xen은 오픈 소스 커뮤니티에서 많은 도움을 받았다. Xen은 paravirtualizing VMM (Virtual Machine Monitor)이다. OS가 선택 영역에서 변경되어 하이퍼바이저(hypervisor)로 호출되지만, 그 OS에서 실행되는 애플리케이션은 변경되지 않는다. VMWare 같은 가상화 시스템이(실행 OS를 변경할 필요가 없는) 진정한 가상화를 표방하지만, 퍼포먼스에 영향을 미칠 수 있는 머신 코드는 여전히 변환해야 한다. Xen은 변경된 OS가 필요하기 때문에, Xen 아키텍쳐로 포팅되지 않는 한 현재 리눅스 커널을 Xen 하이퍼바이저(hypervisor)에서 실행할 수 없다. 하지만 현재 시스템이 Xen 아키텍쳐로 포팅된 새로운 리눅스 커널을 사용할 수 있다면 기존 시스템을 변경 하지 않고 실행할 수 있다. 그림 1. Xen 아키텍쳐  Xen의 소스 코드는 프로젝트 페이지(참고자료)를 참조하기 바란다. 리눅스를 이미 실행하고 있다면, 패키지 업데이트 또는 설치를 통해 Xen을 설치할 수 있다. 다음은 Xen을 포함하고 있는 배포판이다. 여러분의 배포판을 체크하라. 위 리스트에 있는 것이 아니라면, 소스코드를 직접 사용해야 한다. 배포판의 설치 프로시저 외에도 어떤 배포판의 Xen에서도 모든 것이 똑같이 작동한다. 내 컴퓨터는 Fedora Core 3을 실행하고 있기 때문에, Fedora Core를 설치하여 실행하는 것에 대해 설명하겠다. Fedora는 Xen 사용자 커뮤니티를 이미 형성하고 있다. 비록 패키지들은 최근에야 개발 채널로 옮겨졌다. Fedora에서 Xen을 사용하는 사람들이 많기 때문에, 온라인에서 많은 성공 스토리를 참조할 수 있다.
빠른 설치와 실행을 위해 이 섹션에서는 참고자료 섹션의 Quick Start Guide에 초점을 맞추겠다. Quick Start Guide도 매번 변경된다. 이 기본 머신에 최소한의 서버를 설치하는 것으로 시작한다. 기본 머신은 하이퍼바이저(hypervisor)이고, 어떤 서버 애플리케이션도 실행하지 않는다. 이 머신 상단에서 실행되는 Xen 서버에 원하는 패키지들을 설치할 기회가 생길 것이다. 그렇게 되면 아직 실행하지 않아도 되는 애플리케이션은 설치 할 필요가 없다. 시스템을 실행시켰다면 Fedora의 최신 개발 버전(rawhide)으로 업데이트 해야 할 것이다. /etc/yum.repos.d/ 디렉토리의 엘리먼트로 가서 fedora-devel.repo를 제외한 모든 것을 이제 여러분만의 yum 리파지토리(repository)가 설정 되었으니, 머신을 업데이트하여 최신 Xen 릴리스를 사용할 수 있다. Listing 1. FC3를 업데이트하여 Xen 패키지 설치하기
다음에는 더미 파일시스템(dummy filesystem)을 만든다. Listing 2. Xen 서버 파일시스템 포맷팅 및 설치
Xen 서버 파일시스템이 포맷 및 마운트(mount) 되면, 이 파일시스템에서 실행될 패키지들을 설치한다. Xen 서버에서 웹 서버를 실행하려면, 웹 서버 패키지 세트를 설치해야 한다. (경고: 시간이 조금 걸린다. yum을 실행시킨 다음 산책을 다녀와라.) Listing 3. Xen 서버 패키지 설치하기
(잘 되었는지 확인하라.) 이제 모든 패키지들을 설치했지만, 간단한 fstab 파일을 살펴봐야 한다. 이것은 Xen 서버들에게 루트(root) 장치 sda1이 될 것을 말해준다. 이 루트 디바이스는 실제로 하이퍼바이저(hypervisor)에서 온 가상화된 장치이다. 하지만 여러분의 서버는 이것을 인식하지 못한다. Listing 4. Xen 서버 fstab 파일
정상적인 Fedora 설치 없이는 어떤 fstab도 만들어지지 않는다. Fedora의 향후 버전에는 이 문제를 다루는 툴이 포함될 것이다. 마지막으로 시스템을 올바르게 실행할 해킹 작업이 필요하다. Xen은 현재 Listing 5. 마지막 해킹
힘들게 설정했기 때문에 머신을 재부팅하고, Xen 커널을 사용하기 시작한다. 아마도 과도한 프린트아웃을 보게 될 것이다. TLS 라이브러리에 대한 무시무시한 메시지도 보게 될 것이다. (그 메시지 때문에 이전 섹션으로 다시 가야 할지도 모른다.) Xen에는 실행하는 각 서버 마다 설정 파일이 필요하다. 모든 서버에 하나의 동적 설정 파일을 만들 수 있지만, 두 개의 정적 설정 파일을 만들 것을 권한다. 여러분도 알다시피, 이 디스크 레이블은 파일 이미지가 sda1 장치라는 것을 알려준다. Listing 6. Xen 서버 설정 파일
서버를 실행하려면
이제 설정을 편집하고 시스템이 두 개의 Xen 서버를 실행하도록 설정할 것이다. 이런 힘든 작업에 대한 보상은 무엇일까? 같은 커널에서 실행되는 시스템이 두 개가 되었다. BaseServer가 웹 서비스를 정상적으로 실행하기 원하는 안정적인 환경을 나타낸다면 TestServer는 Fedora가 제공하는 최신 소프트웨어 업데이트를 나타낸다. 이 테스트서 시스템을 지속적으로 업그레이드 하여, 모든 새로운 버전의 소프트웨어를 업데이트 한다. 이 TestServer를 BaseServer로서 실행할 수 있다. BaseServer가 실행될 때가 아파치 httpd 서비스를 설정할 좋은 때이다. ssl.conf 파일을 /etc/httpd/conf.d/ 디렉토리에서 빼내어 ssl을 종료한다. 그렇지 않으면 이 서버에 대한 인증을 만들어야 한다. 또한 아파치 사용자를 이 시스템에 추가해야 한다. Xen 하이퍼바이저(hypervisor)는 가상 네트워크 장치를 자동으로 제공한다. 이 서비스에서 dhcp를 실행할 수 있다면, BaseServer를 설정했다면 BaseServer 콘솔에서
TestServer 인스턴스(instance)는 BaseServer와 같은 구성을 갖지만, Fedora가 제공하는 최신 패키지로 업그레이드 한다. 여기에서 웹 사이트가 작동하는지를 확인한다.
간단한 설명과 예제로 Xen을 설치하여 시행하는데 도움이 될 수 있길 바란다. LVM의 활용법이나 머신 간 Xen 서버의 네트워크 마이그레이션 방법은 다루지 않았다. Xen에 대한 자세한 내용은 아래 참고자료 섹션을 참조하기 바란다.
| ||||||||||||||||||||||||||||||||||||||
(0) (0)Posted by 삐꾸강아쥐
Trackback URL : http://blog.blog.n-nuri.com/trackback/192
http://blog.n-nuri.com 이 접속이 안 될경우 http://x2x.dnip.net 으로 접속해 주세요 공유하지 않는 지식은 썩은 물과 같다~~~!!!
- 삐꾸강아쥐
connection.py.patch
