Asking Xen User Questions

From Xen
Jump to navigationJump to search


Icon todo.png Needs Refactor

Needs splitting and moving into the smaller FAQs on Category:FAQ


Xen Users Mailing List Commonly Asked Questions

Introduction

This document is a Xen.org community effort to gather the most commonly asked questions from the xen-users emailing list and other support tools to assist new and experienced Xen hypervisor users with problems that frequently arise. If you would like to add content to this document, please send an email to community.manager@xen.org for editing rights if you don't have wiki editing rights already. For those users interested in trying Xen without installing the application, a Live CD version is available at http://wiki.xensource.com/xenwiki/LiveCD.

Support Tools

The following sites are available for Xen hypervisor support:

How To Guide Links

The Xen.org community Wiki has a HowTo Page with various information sources at http://wiki.xensource.com/xenwiki/HowTos. Updates to this Wiki page are continuous so check back often for new How Tos. Sample topics internally within the Wiki are:

Sample topics with external links are:

Guest Related Questions

Guest Conversion

See Xen_FAQ_Guest_Conversion

Console

See Xen_FAQ_Console

Drivers

See Xen_FAQ_Drivers,_Windows

Domain0

See Xen_FAQ_Dom0


See Xen_FAQ_DomU

Devices

Q (G6.0): For my xen domUs I'm using a mixture of locah physical partitions (with LVM) and iSCSI disks. For local partitions, I don't have any problem, because LVM volumes are always the same. But for iSCSI disks, devices are assigned in the order they are connected, so I can't be sured that device that now is /dev/sdb (for example) will always be /dev/sdb. So, is there any way to identify the physical device in the domU configuration not as phy:/dev/sdb, but something like phy:label=fslabel? Or is there any other solution to this problem?

A (G6.0): I go with phy:/dev/disk/by-path/ip-*-iscsi-iqn.* If you assign iscsi luns directly as domU's fs without additional partitioning, you could probably also use /dev/disk/by-label/* or /dev/disk/by-uuid/*

Installation Questions

See Xen_FAQ_Installation

Networking Questions

See Xen_FAQ_Networking

Security Questions

See Xen_FAQ_Security

Design/Misc Questions

How does Xen Work

Q (D3.0): How does Xen process System Calls on para-virtualized guest?

A (D3.0): When ever a system call is invoked via interrupt or sys center control gets transferred to the kernel (ring 0), which is then handled via system call handler. System call never goes to libc but Libc is a library that provides POSIX interface to the user space applications and in a way wrapper for invocation of a system call. System call interrupt based [i386]: During booting process, linux kernel of a domU register's its IDT with Xen Hypervisor via HYPERVISOR_set_trap_table(trap_table); [arch/i386/kernel/traps-xen.c]. Xen maintains two IDT's, one global IDT (its own) and other per domain IDT. Xen uses global IDT to register the entire trap handler except for system call handler (int 0x80). When a VM gets scheduled, its system call handler (from per domain IDT table) is registered with the processor. Hence when a domain/VM executes a system call, its own handler is executed. Implementation differs for x86_64: Xen registers its own system call handler with the processor and from that handler routes the request to VM/Domain specific handler.

Q (D3.1): How does Xen process System Calls on fully virtualized guest (HVM)?

A (D3.1): For HVM domU there is no change in the behavior of the system call. HVM is only supported for Intel-VT and AMD-SVM processors. These processors are virtualization aware. Virtualization aware processors provide a new ring (Root-Ring 0) with higher privilege for VMM and Guest OS continues to runs with the same privilege (as without Xen) in Non-Root Ring 0. Guest OS can issue the system calls the way it used to without Xen.

Q (D3.2): Can I run various DomU operating systems on a different Dom0 operating system?

A (D3.2): Yes.

Q (D3.3): Just curious to know, if there is any way that given a terminal to a box, we can determine is it a physical machine or a virtual machine ?

A (D3.3): You should be able to get some useful information from the DMI, e.g: % for i in system-manufacturer system-product-name system-version\ system-serial-number; do echo -n "$i: "; sudo dmidecode -s $i; done system-manufacturer: Xen system-product-name: HVM domU system-version: 3.3.1 system-serial-number: 89e5915f-dead-beef-cefd-46904ea94c4a OR Probably checking kernel process, check your process table for: [xenwatch] [xenbus] Another clue is checking the kernle suffix, for example: and the proc files: /proc/xen/capabilities

Q (D3.4): What is STUBDOM ?

A (D3.4): Stubdoms are lightweight 'service' or 'driver' domains. The initial purpose was to offload qemu (for hvm guests) out of dom0. So with stubdoms you can run hvm guest qemu in a separate stubdom, which boosts performance and makes it more secure. stubdoms can also run for example pv-grub for pv guests, making it more secure compared to pygrub, which always runs in dom0. http://wiki.xensource.com/xenwiki/StubDom Presentation about stubdoms at Xen Summit: http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf http://blog.xen.org/index.php/2008/08/28/xen-33-feature-stub-domains/ http://blog.xen.org/index.php/2008/08/28/xen-33-feature-hvm-device-model-domain/ http://lxr.xensource.com/lxr/source/stubdom/README

Q (D3.5): When is hardware virtualization used in Xen? Is it required?

A (D3.5): Xen uses hardware virtualization for HVM guests. Xen will not launch a HVM guest unless hardware virtualization is turned on.

Retrieved from "https://wiki.xenproject.org/index.php?title=Asking_Xen_User_Questions&oldid=5388"