(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://blog.n-nuri.com 이 접속이 안 될경우 http://x2x.dnip.net 으로 접속해 주세요 공유하지 않는 지식은 썩은 물과 같다~~~!!!
- 삐꾸강아쥐
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
connection.py.patch