스마일서브 CDN 사업부에서 근무하고 있으며 동영상호스팅, 이미지호스팅에 대한 서비스 설명 및 기술 적인 이슈들을 기재하고 있습니다.
사용 형식 rpm -option1 [--option2] RPMNAME
1. option1
-i (설치)
-U (업그레이드 설치)
-v (진행 과정 설명을 보여줌)
-h (진행 과정을 보여줌)
-e (삭제)
-qa (설치 되어 있는 모든 RPM패키지 리스트)
-qa | grep (특정 RPM 패키지 설치여부 확인)
-qRp (의존성 관계 확인)
ex) rpm -ivh RPMNAME
rpm -Uvh RPMNAME
2. option2
--replacepkgs (동일한 패키지가 이미 설치 되어 있을 경우 무시하고 설치)
--replacefiles (설치 하려고 하는 패키지의 파일이 이미 설치되어 있는 다른 패키지의 파일과 중복될경우 무시하고 설치)
--force (패키지 중복이 발생하거나 이미 설치되어있는 다른 패키지의 파일과 충돌 발생시 무시 하고 설치)
--nodeps (패키지 의존성 문제를 무시)
많은 양의 메일이 큐에 쌓일경우 아래와 같이 설정해주시면
매번 큐를 삭제하지 않고도 주기적으로 큐 정리가 가능해집니다.
touch /var/qmail/control/queuelifetime
echo "86400" > /var/qmail/control/queuelifetime -> 큐 대기시간 하루
/etc/init.d/qmail reload
/var/qmail/bin/qmail-showctl | grep life
queuelifetime: Message lifetime in the queue is 86400 seconds
/var/qmail/bin/qmail-qstat
messages in queue: 1
messages in queue but not yet preprocessed: 0
The Oracle VM Server management command-line management tool xm, creates, destroys, manages and migrates guests.
This section contains a brief explanation of some of the more common xm commands. For full documentation, use the xm help --long command.
The xm command-line tool requires the xend daemon to be started.
Enter parameters to the xm command-line tool in the format:
xm [option] [argument]
See Chapter 5, "Domain Monitoring and Administration" for examples on using the xm command-line tool.
Options
Attaches to a domain's console.
# xm console mydomain
Creates a domain based on the entries in the config-file.
Entering the -c parameter attaches to the domain's console when the domain is created and started.
You can also enter name value pairs to override variables in the config-file using the name=value parameter.
# xm -c /home/myhome/myconfig
Immediately terminates a domain.
# xm destroy mydomain
Displays message buffer logs similar in format to the equivalent to the dmesg command in the Linux kernel.
The --clear parameter clears the message buffer.
Displays help on the xm command, and its options.
The --long option displays full help on xm commands, grouped by function.
Enter a command name as an option to the xm command to get help only on that command.
# xm help --long create
Displays information about the host computer.
# xm info
Displays information on all the running domains.
The --long option displays full information on running domains.
Enter the domain-id as an option to the xm command to get information on only that domain, or a set of domains.
# xm list --long mydomain
Displays logs similar in format to the equivalent for the Linux kernel. The log file is located at /var/log/xend.log.
# xm log
Migrates a domain to another computer.
The domain-id parameter is the domain to migrate.
The host parameter is the target computer.
The --live parameter migrates the domain without shutting down the domain.
The --resource parameter sets the maximum amount of Megabytes to be used.
# xm migrate mydomain example.com --live
Adds a domain to Oracle VM Server domain management.
You can set domain creation parameters with a number of command-line options, a Python script (with the --defconfig parameter), or an SXP configuration file (the --config parameter).
You can set configuration variables with name=value pairs, for example vmid=3 sets vmid to 3.
The config-file parameter is the location of the domain configuration file.
The option parameter is one or more of the following:
[-h | --help]
Displays help on the command.
[--help-config]
Prints the available configuration variables for the configuration script.
[-q | --quiet]
Quiet.
[--path=path]
Searches the location given in path for configuration scripts. The value of path is a colon-separated directory list.
[-f=file | --defconfig=file]
Uses the given Python configuration script. The script is loaded after arguments have been processed. Each command-line option sets a configuration variable named after its long option name, and these variables are placed in the environment of the script before it is loaded. Variables for options that may be repeated have list values. Other variables can be set using name=value on the command-line. After the script is loaded, values that were not set on the command-line are replaced by the values set in the script.
[-F=file | --config=file]
Sets the domain configuration to use SXP. SXP is the underlying configuration format used by Xen. SXP configurations can be hand-written or generated from Python configuration scripts, using the --dryrun option to print the configuration.
[-n | --dryrun]
Prints the resulting configuration in SXP, but does not create the domain.
[-x | --xmldryrun]
Prints the resulting configuration in XML, but does not create the domain.
[-s | --skipdtd]
Skips DTD checking and XML checks before domain creation. This option is experimental and may slow down the creation of domains.
[-p | --paused]
Leaves the domain paused after it is created.
[-c | --console_autoconnect]
Connects to the console after the domain is created.
# xm new /home/myhome/myconfig
Pauses the execution of a domain.
# xm pause mydomain
Reboots a domain.
The --all parameter reboots all domains.
The --wait parameter waits for the domain to reboot before returning control to the console.
# xm reboot --wait mydomain
Restores a domain from a saved state.
# xm restore /home/myhome/statefile
Saves a domain state so it can be restored at a later date.
# xm save mydomain /home/myhome/statefile
Shuts down a domain gracefully.
The -a parameter shuts down all domains.
The -w parameter waits for the domain to shut down before returning control to the console.
# xm shutdown -w mydomain
Displays real time monitoring information of the host and domains.
# xm top
Unpauses a paused domain.
# xm unpause mydomain
The virt-install command-line tool creates paravirtualized guests and hardware virtualized guests. virt-install can be used as an interactive shell, or all parameters can be given at the same time. Enter multiple parameters to the virt-install command-line tool in the format:
virt-install [option ...]
This section contains a brief explanation of some of the more common virt-install options. For full documentation, use the virt-install -h command.
Chapter 4, "Creating a Guest Virtual Machine" discusses using the virt-install tool.
Options
Displays the virt-install command parameters and their purpose.
# virt-install -h
Sets the name of the guest instance.
# virt-install -nMyGuest
Sets the memory to allocate for a guest instance in Megabytes.
# virt-install --ram=256
Sets the UUID (Universally Unique Identifier) for the guest. If none is given, a random UUID is generated.
# virt-install -u
Sets the number of virtual CPUs to configure for the guest.
# virt-install --vcpus=2
Sets the file to use as the disk image.
# virt-install --file=/home/myhome/myimage
Sets the size of the disk image (if it does not exist) in Gigabytes.
# virt-install -s2
Do not use sparse files for disks. This option may be significantly slower when creating guests.
Sets the fixed MAC address for the guest; if none or RANDOM is given, a random address is used.
# virt-install --mac=RANDOM
Sets the bridge to connect guest NIC to. If none is given, attempts to determine the default.
Use VNC (Virtual Network Computing) for graphics support.
# virt-install --vnc
Sets the port to use for VNC connections.
# virt-install --vncport=5900
Use SDL (Simple DirectMedia Layer) for graphics support.
# virt-install --sdl
Do not use a graphical console for the guest.
# virt-install --nographics
Do not automatically connect to the guest console.
# virt-install --noautoconsole
Set up keyboard mapping for the graphical console. If none is given, the keymap is automatically set to the local keymap.
# virt-install --de
Use kernel acceleration capabilities.
# virt-install --accelerate
Connect to hypervisor with URI.
# virt-install --connect=test:///default
Sets the guest as being a fully virtualized guest.
# virt-install -v
Sets the file to use a virtual CD-ROM device for fully a virtualized guest.
Sets the operating system type for a fully virtualized guest. Possible values are windows, unix, other, and linux.
# virt-install --os-type=windows
Sets the operating system variant for a fully virtualized guest, for example, rhel5, win2k, or vista. This parameter should be used with the os-type parameter.
The following table lists the possible values available for os-variant for each os-type option.
| Possible values for os-type=windows | Possible values for os-type=unix | Possible values for os-type=other | Possible values for os-type=linux |
|---|---|---|---|
| win2k3 | solaris9 | netware6 | generic24 |
| win2k | solaris10 | generic | generic26 |
| vista | freebsd6 | netware4 | rhel2.1 |
| winxp | openbsd4 | msdos | fedora7_64 |
| netware5 | el5_64 | ||
| fedora6 | |||
| fedora7 | |||
| fedora5 | |||
| centos5_64 | |||
| generic26_64 | |||
| centos5 | |||
| sles10 | |||
| sles10_64 | |||
| el4_64 | |||
| rhel4 | |||
| rhel5 | |||
| rhel4_64 | |||
| rhel3 | |||
| fedora6_64 | |||
| rhel5_64 | |||
| fedora5_64 | |||
| el4 | |||
| el5 |
Note:
Not all operating system variants are supported by Oracle for use with Oracle products, but are made available for your convenience.# virt-install --os-type=windows --os-variant=winxp
Disables APIC (Advanced Programmable Interrupt Controller) for a fully virtualized guest. Overrides the value set in --os-type and --os-variant.
Sets the CPU architecture to simulate.
# virt-install --arch=x86
Sets the guest as being a paravirtualized guest.
Sets the installation source for a paravirtualized guest, for example, nfs:host:/path, http://host/path, or ftp://host/path.
# virt-install -lhttp://example.com/path
Sets the virtual network interface type for hardware virtualized guests. The netfront driver is a paravirtualized driver which can be used with a paravirtualized guest, or with a hardware virtualized guest with the proper paravirtualized drivers installed. The ioemu driver is a hardware virtualized driver, and can only be used with a hardware virtualized guest. Both drivers contain the device emulation code to support hardware virtualized guests.
For hardware virtualized guests, type can be either ioemu or netfront. The default is ioemu.
You cannot use this parameter for paravirtualized guests. For paravirtualized guests, the default is netfront and cannot be changed.
# virt-install --vif-type=ioemu
Any additional arguments to pass to the installer with a paravirtualized guest.
Prints debugging information.
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>
차례
Modern computers are sufficiently powerful to use virtualization to present the illusion of many smaller virtual machines (VMs), each running a separate operating system instance. Successful partitioning of a machine to support the concurrent execution of multiple operating systems poses several challenges. Firstly, virtual machines must be isolated from one another: it is not acceptable for the execution of one to adversely affect the performance of another. This is particularly true when virtual machines are owned by mutually untrusting users. Secondly, it is necessary to support a variety of different operating systems to accommodate the heterogeneity of popular applications. Thirdly, the performance overhead introduced by virtualization should be small.
Xen is a virtual machine monitor for x86 that supports execution of multiple guest operating systems with unprecedented levels of performance and resource isolation. Xen is Open Source software, released under the terms of the GNU General Public License. We have a fully functional ports of Linux 2.6 running over Xen, and regularly use it for running demanding applications like MySQL, Apache and PostgreSQL. Any Linux distribution (RedHat, SuSE, Debian, Mandrake) should run unmodified over the ported OS.
In addition to Linux, members of Xen's user community have contributed or are working on ports to other operating systems such as NetBSD (Christian Limpach), FreeBSD (Kip Macy) and Plan 9 (Ron Minnich).
It is also possible to run some other, not ported, operating systems if your CPU has hardware virtualization support (VT or Pacifica).
an Etch dom0 (2.6.18-*-xen) can only run 32-bit domU when it's i386 itself, a 64-bit Etch dom0 (using the amd64 kernel) can run a 64-bits domU and also a 32-bit domU, but only when using the amd64-kernel and a 32-bit userland!
Quite the same way as Etch. The kernel is 2.6.26, the -xen variant contains patches from SuSE for dom0 support.
The xen-linux-system packages of interest are (Install the correct one for your architecture):
To get output from grub, XEN, the kernel and getty (login prompt) via both vga and serial console to work, here's an example of the right settings when using Lenny kernels and Xen 3.2:
In /boot/grub/menu.lst:
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1 terminal --timeout=5 serial console [...] title Xen 3.2-1-amd64 / Debian GNU/Linux, kernel 2.6.26-2-xen-amd64 root (hd0,0) kernel /boot/xen-3.2-1-amd64.gz com1=9600,8n1 console=com1,vga module /boot/vmlinuz-2.6.26-2-xen-amd64 root=/dev/md0 ro console=tty0 console=hvc0 module /boot/initrd.img-2.6.26-2-xen-amd64
In contrast to the Etch configuration, there's no ttyS0 in the vmlinuz line!
In /etc/inittab you need at least these lines:
1:2345:respawn:/sbin/getty 38400 hvc0 2:23:respawn:/sbin/getty 38400 tty1 # NO getty on ttyS0!
The tty1 will show up at the vga output, and the hvc0 will show up at the serial console.
The Lenny Debian Installer fully supports installation of 32 bit guests under Xen using the netboot/xen variant. Images are available on any Debian mirror in the installer directory and contain a kernel, installer ramdisk and an example Xen configuration file. To install, fetch the xm-debian.cfg configuration file, edit to suit your tastes, and start the guest with the install=true option plus an optional (but strongly recommended) install-mirror=ftp://ftp.XX.debian.org/debian.
xm create -c xm-debian.cfg install=true install-mirror=ftp://ftp.XX.debian.org/debian
Newer images are also available from the daily builds. After grabbing the xm-debian.cfg configuration file and editing it to suit your tastes, start the guest with an additional install-installer=http://people.debian.org/~joeyh/d-i/images/daily/ to manually direct it to the daily builds:
WARNING, if you do not change the hard disks option on xm-debian.cfg this WILL overwrite your dom0 instead of installing to your domU. YOUR MACHINE WILL BE DESTROYED.
xm create -c xm-debian.cfg install=true \ install-mirror=ftp://ftp.XX.debian.org/debian \ install-installer=http://people.debian.org/~joeyh/d-i/images/daily/
See the comments in the configuration file for additional installation options.
Another way of creating a lenny domu is the following:
xen-create-image --hostname=vanila --size=8Gb --dist=lenny --memory=512M --ide --dhcp
Please note that the --dir option may be required, and it specified the directory where it will store your disk images. If you wish to specify a fixed ip address, use the --ip xxx.xxx.xxx.xxx instead of --dhcp option.
Once the guest is installed simply boot it using:
xm create -c xm-debian.cfg
Lenny only includes 32 bit (PAE) kernel support which means there is no installer support for 64 bit guests. You can continue to use the Etch kernels or obtain a newer upstream kernel which supports 64 bit operation (2.6.27+).
In addition to installing via Debian Installer xen-tools can also create a Lenny domU as described in the Etch section above.
The default Lenny kernel is the newer paravirt_ops version (2.6.26), which does not function as a dom0 (except for the -xen variants, which have dom0 support but also some issues running as domU (please clarify?). It will also not support PCI passthrough in a domU. For PCI passthrough, you have to run the 2.6.18 etch kernel as both dom0 and domU.
In Lenny the distinction between the Xen and non-Xen flavours of the kernel (with respect to domU support) is no longer present. The Debian Installer will install the -686-bigmem flavour.
xen-tools don't use hvc0 as the console device in /etc/inittab and don't install udev (leading to /dev/pts missing in domU).
This makes logging in via xm console and via ssh impossible, because getty doesn't have a proper console to attach to and ssh can't attach to a pseudo terminal.
To fix this,
1. add to /etc/xen-tools/xen-tools.conf:
serial_device = hvc0
2. and make domU with:
xen-create-image --hostname HOSTNAME (more options...) --role udev
Upstream documentation can be found in the xen-docs-3.0 package (in /usr/share/doc/xen-docs-3.0/user.pdf.gz). It's also available online.
Choose and install a xen-linux-system-KERNELVERSION package. This installs the kernel, a hypervisor and matching utilities.
On i386, install libc6-xen. This means that you don't have to delete /lib/tls or move it out of the way, as suggested by most Xen guides.
The xen-linux-system packages of interest are (Install the correct one for your architecture):
If you need to apply some modifications to the kernel with the xen patch, then one way to do it is described DebianKernelCustomCompilation.
To get output from grub, XEN, the kernel and getty (login prompt) via both vga and serial console to work, here's an example of the right settings when using etch kernels and Xen 3.0.3:
In /boot/grub/menu.lst:
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1 terminal --timeout=5 serial console [...] title Xen 3.0.3-1-i386-pae / Debian GNU/Linux, kernel 2.6.18-6-xen-686 root (hd0,0) kernel /boot/xen-3.0.3-1-i386-pae.gz com1=9600,8n1 console=com1,vga module /boot/vmlinuz-2.6.18-6-xen-686 root=/dev/md0 ro console=tty0 console=ttyS0,9600n8 module /boot/initrd.img-2.6.18-6-xen-686
In /etc/inittab you need at least these lines:
1:2345:respawn:/sbin/getty 38400 tty1 T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
The easiest way to create a domU is to use xen-tools (and, if this doesn't do what you need, Steve Kemp is keen and fast in implementing useful suggestions).
If you do not wish to use xen-tools, you could use this alternative guide, to setup the system using debootstrap.
Xen boots domUs using kernels stored on dom0, so you only need to install the corresponding linux-modules package in the domU. Alternatively, you can use PyGrub to boot kernels on the domU filesystem.
On i386, make sure you install libc6-xen.
If you install lenny domU on etch dom0, make sure you read this entry on XenFaq when you see messages on the console like 4gb seg fixup, process klogd (pid 2075), cs:ip 73:b7e25870. After applying the echo 'hwcap 0 nosegneg' > /etc/ld.so.conf.d/libc6-xen.conf && ldconfig, in the dom0 system, reboot, or, if you don't like rebooting (which requires you to stop domU's), restart all processes mentioned in the log messages (e.g. /etc/init.d/ssh restart, init q, etc..)
There are three options:
Use DebianLenny's 2.6.26 (which has forwarded ported Xen 2.6.18 dom0 kernel)
Use 2.6.30 with forwarded ported Xen 2.6.18 dom0 kernel, see
http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2009-July/002356.html
The page DebianInstaller/Xen contains instructions on how to install Xen Dom0 and Etch DomU with DebianInstaller.See above for details of installing Lenny using Debian Installer.
Debian's Xen packages are maintained by the pkg-xen project. (developpers' mailing list)
The Debian Developer's Package Overview page lists source packages that are maintained by the team.
title Xen 3.1-1-i386 / Debian GNU/Linux, kernel 2.6.18-6-xen-686 root (hd0,0) kernel /xen-3.1-1-i386.gz noreboot module /vmlinuz-2.6.18-6-xen-686 root=/dev/foo ro console=tty0 module /initrd.img-2.6.18-6-xen-686
You need to configure some basic networking between dom0 and domU. Edit /etc/xen/xend-config.sxp
#(network-script network-dummy) (network-script network-bridge)
for a basic bridge networking, and restart xend.
You get the error :
CDROM boot failure code 0002 or CDROM boot failure code 0003 Boot from cd-Rom failed Fatal: Could not read the boot disk.
That's because Xen can't boot from a cdrom iso image at the moment. i.e you can't have tap:aio:/path/to/mycd.iso,hdc:cdrom,r or file:/path/to/mycd.iso,hdc:cdrom,r.
Workaround: use losetup to create a loopback device for the cdrom ISO image, then use it in Xen configuration file. for example :
#First, check which loop device is free $losetup -f /dev/loop9 #Then create a loopback device $losetup -f /path/to/mycd.iso losetup /dev/loop9 /dev/loop9: [fe04]:3096598 (/path/to/mycd.iso)
Now you can use /dev/loop9 in xen configuration file (/etc/xen/foobar.cfg) :
... disk = [ 'phy:/dev/vg1/xpsp3,ioemu:hda,w', 'phy:/dev/loop/0,ioemu:hdc:cdrom,r' ] ...
then boot/install the guest OS.
note: yo should switch back to the tap:aio:/path/to/mycd.iso,hdc:cdrom,r syntax after installation, since loop back have to be recreated after you reboot the host system.
Solution:
echo 'hwcap 0 nosegneg' > /etc/ld.so.conf.d/libc6-xen.conf && ldconfig
Read this XenFaq entry for more info.
Using a lenny domU, make sure you have hvc0 listed in inittab, like 1:2345:respawn:/sbin/getty 38400 hvc0. There happened to be a lot of changes of default console unit used by Xen (tty1, xvc0, hvc0 etc) but for a Lenny domU (version > 2.6.26-9) it's hvc0.
If a domU crashes or freezes while uttering the famous lasts words 'clocksource/0: Time went backwards', your domU is likely using the xen clocksource instead of its own clock ticks. In practice, this seems to be the cause of infrequent lockups under load (and/or problems with suspending). A workaround is to decouple the clock in the domU from the dom0:
In your dom0 and domU /etc/sysctl.conf add the line: xen.independent_wallclock=1. On the dom0, edit the configuration file of the domU (e.g. /etc/xen/foobar.cfg and add (or expand) the extra-line: extra="clocksource=jiffies".
These settings can be activated without rebooting the domU. After editing the configuration files, issue sysctl -p and echo "jiffies"> /sys/devices/system/clocksource/clocksource0/current_clocksource on the domU prompt.
Because the clock won't be relying on the dom0 clock anymore, you probably need to use ntp on the domU to synchronize it properly to the world.
The above, rather cryptic, error (when starting a domU using xen-utils/xm create) is due to xen-utils not being able to find PyGrub. Modify your xm-debian.cfg config file to use the absolute directory (ie. bootloader="/usr/lib/xen-3.2-1/bin/pygrub" instead of bootloader="pygrub") and your domU should boot up fine.
xm save/migration of a 32-Bit domU on a 64-Bit dom0 fails. It seems this is not supported with linux-image-2.6.26-2-xen-amd64 (http://readlist.com/lists/lists.xensource.com/xen-users/4/24225.html). One workaround is to use a 64-Bit Hypervisor with a 32-Bit dom0 (http://lists.xensource.com/archives/html/xen-users/2008-12/msg00404.html). See also 526695
It may be possible to build the PV drivers for use on HVM guests. These drivers are called unmodified_drivers and are part of the xen-unstable.hg repository. You can fetch the repository using mercurial thus:
hg clone http://xenbits.xen.org/xen-unstable.hg
The drivers reside under xen-unstable.hg/unmodified_drivers/linux-2.6. The README in this directory gives compilation instructions.
Homepage :http://www.xen.org
(quite basic and low-level) Upstream Documentation is on package xen-docs-3.0 package (in /usr/share/doc/xen-docs-3.0/user.pdf.gz). It's also available online.
German Wiki on Xen: http://www.xen-info.de/wiki
Creating and Managing Domains with xm
You can use the xm application to create and manage domains.
Connecting to a Domain
You can use xm to connect to a domain or virtual machine:
xm console domain-id
This causes the console to attach to the domain-id's text console.
Creating a Domain
You can use xm to make a domain:
xm create domain001 [-c]
This creates a domain named domain001 with the file residing in the /etc/xen/ directory. The [-c]option aids with troubleshooting by allowing you to connect to the text console.
Saving a Domain
You can use xm to save a domain:
xm save [domain-id] [statefile]
Terminating a Domain ID
You can use xm to terminate a domain-id:
xm destroy [domain-id]
This instantly terminates the domain-id. If you prefer another method of safely terminating your session, you can use the shutdown parameter instead.
Shutting Down a Domain
You can use xm to shut down any domain:
xm shutdown [domain-id] [ -a | -w ]
The [ -a] option shuts down all domains on your system. The [-w] option waits for a domain to completely shut down.
Restoring a Domain
You can use xm to restore a previously saved domain.
xm restore [state-file]
Suspending a Domain
You can use xm to suspend a domain:
xm suspend [domain-id]
Resuming a Domain
You can use xm to resume a previously suspended session:
xm resume [domain-id]
Rebooting a Domain
You can use xm to reboot a domain:
xm reboot [domain-id] [ -a | -w ]
The [ -a] option reboots all domains on your system. The [-w]option waits for a domain to completely reboot. You can control the behavior of the rebooting domain by modifying the on_boot parameter of the xmdomain.cfg file.
Renaming a Domain
You can use xm to assign a new name to an existing domain:
xm rename [domain-name] [new domain-name]
Domain renaming will keep the same settings (same hard disk, same memory, etc.).
Pausing a Domain
You can use xm to pause a domain:
xm pause [domain-id]
Unpausing a Domain
You can use xm to unpause a domain:
xm unpause [domain-id]
This makes the domain available for scheduling by a hypervisor.
Converting a Domain Name to Domain ID
You can use xm to convert a domain name to a domain ID:
xm domid [domain-name]
Converting a Domain ID to Domain Name
You can use xm to convert a domain ID to a domain name:
xm domname [domain-id]
Configuring Memory Allocation
You can use xm to modify a domain's memory allocation:
xm mem-set [domain-id] [count]
Note
You cannot grow a domain's memory beyond the maximum amount you specified when you first created the domain.
Configuring Maximum Memory
You can use xm to modify a domain's maximum memory:
xm mem-max [domain-id] [count]
You must specify the [count] in megabytes.
Configuring VCPU Count
You can use xm to modify a domain's VCPU count:
xm vcpu-set [domain-id] [count]
You must specify the [count] in megabytes.
Note
You cannot grow a domain's memory beyond the maximum amount you specified when you first created the domain.
Pinning a VCPU
You can use xm to pin a VCPU:
xm vcpu-pin [domain-id] [vcpu] [cpus]
Where [vcpu] is the VCPU that you want to attach to, and [cpus] is the target. Pinning ensures that certain VCPUs can only run on certain CPUs.
Migrating a Domain
You can use xm to migrate a domain:
xm migrate [domain-id] [host] [options]
Where [domain-id] is the domain you want to migrate, and [host] is the target. The [options] include ——live (or -l) for a live migration, or ——resource (or -r) to specify maximum speed of the migration (in Mbs).
To ensure a successful migration, you must ensure that the xend daemon is running on all hosts domains. All hosts must also be running Red Hat RHEL 5.0+ and have migration TCP ports open to accept connections from the source hosts.
Monitoring and Diagnostics
Performing a Core Dump
You can use xm to perform a memory dump of an existing virtual machine.
xm dump-core [-C] [domain-id]
This command dumps the virtual machine's memory to the xendump file located in the /var/xen/dump/ directory. You can terminate the virtual machine by including the -C option.
Monitoring Domains in Real Time
You can use xm to monitor domains and hosts in real time:
xm top [domain-id]
Displaying Domain States
You can use xm to display the domain activity states of one or more domains:
xm list [domain-id] [ ——long | ——label]
You can specify a specific domain(s) by name (s). The [——long] option provides a more detailed breakdown of the domain you specified. The [——label] domain adds an additional column that displays label status. The outputs displays:
Name ID Mem(MiB) VCPUs State Time Label
————————————————
Domain0 0 927 8 r—————— 204.9 INACTIVE
Domain202 1 927 8 s—————— 205.0/command ACTIVE
DomainQ/A 2 927 8 b—————— INACTIVE
Domain9600 3 927 8 c—————— 205.1 ACTIVE
Here are the six domain states per VCPU:
|
State |
Description |
|
running |
lists domains currently active on a CPU |
|
blocked |
lists domains that are blocked (a domain becomes blocked when the vcpu is awaiting for an external event to happen) |
|
paused |
lists domains that are suspended |
|
shutdown |
lists domains that are in process of shutting down |
|
shutoff |
lists domains that are completely down. |
|
crashed |
lists domains that are crashed |
|
inactive |
lists domains that are inactive instances |
|
——all |
lists domains that are both active and inactive vcpu instances |
Table The Domain States
문서 출처 : http://www.wideopen.com/docs/manuals/enterprise/RHEL-5-manual/Virtualization-en-US/task-virt-xm-monitoring-diag.html
[출처] Xen - xm 명령어|작성자 바람소리