diff --git a/53709b77-Nested-VMX-load-current_vmcs-only-when-it-exists.patch b/53709b77-Nested-VMX-load-current_vmcs-only-when-it-exists.patch new file mode 100644 index 0000000..c9fbdf4 --- /dev/null +++ b/53709b77-Nested-VMX-load-current_vmcs-only-when-it-exists.patch @@ -0,0 +1,31 @@ +# Commit 99c03bc6a1f8c6722926d2db781ece045f9d09ae +# Date 2014-05-12 11:59:19 +0200 +# Author Edmund H White +# Committer Jan Beulich +Nested VMX: load current_vmcs only when it exists + +There may not have valid vmcs on current CPU. So only load it when it exists. + +This original fixing is from Edmud . + +Signed-off-by: Edmund H White +Signed-off-by: Yang Zhang +Acked-by: Kevin Tian +Reviewed-by: Andrew Cooper + +--- a/xen/arch/x86/hvm/vmx/vmcs.c ++++ b/xen/arch/x86/hvm/vmx/vmcs.c +@@ -828,8 +828,12 @@ void virtual_vmcs_enter(void *vvmcs) + + void virtual_vmcs_exit(void *vvmcs) + { ++ struct vmcs_struct *cur = this_cpu(current_vmcs); ++ + __vmpclear(pfn_to_paddr(domain_page_map_to_mfn(vvmcs))); +- __vmptrld(virt_to_maddr(this_cpu(current_vmcs))); ++ if ( cur ) ++ __vmptrld(virt_to_maddr(cur)); ++ + } + + u64 virtual_vmcs_vmread(void *vvmcs, u32 vmcs_encoding) diff --git a/53732f4f-x86-MCE-bypass-uninitialized-vcpu-in-vMCE-injection.patch b/53732f4f-x86-MCE-bypass-uninitialized-vcpu-in-vMCE-injection.patch new file mode 100644 index 0000000..e2be524 --- /dev/null +++ b/53732f4f-x86-MCE-bypass-uninitialized-vcpu-in-vMCE-injection.patch @@ -0,0 +1,26 @@ +# Commit a07084525c126c596326dc1442dd218f522f51b4 +# Date 2014-05-14 10:54:39 +0200 +# Author Kai Huang +# Committer Jan Beulich +x86/MCE: bypass uninitialized vcpu in vMCE injection + +Dom0 may bring up less number of vCPUs than xen hypervisor actually created for +it, and in this case, on Intel platform, vMCE injection to dom0 will fail due to +injecting vMCE to uninitialized vcpu, and cause dom0 crash. + +Signed-off-by: Kai Huang +Acked-by: Christoph Egger + +--- a/xen/arch/x86/cpu/mcheck/vmce.c ++++ b/xen/arch/x86/cpu/mcheck/vmce.c +@@ -357,6 +357,10 @@ int inject_vmce(struct domain *d, int vc + if ( vcpu != VMCE_INJECT_BROADCAST && vcpu != v->vcpu_id ) + continue; + ++ /* Don't inject to uninitialized VCPU. */ ++ if ( !v->is_initialised ) ++ continue; ++ + if ( (has_hvm_container_domain(d) || + guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)) && + !test_and_set_bool(v->mce_pending) ) diff --git a/537b5e50-VT-d-apply-quirks-at-device-setup-time-rather-than-only-at-boot.patch b/537b5e50-VT-d-apply-quirks-at-device-setup-time-rather-than-only-at-boot.patch new file mode 100644 index 0000000..b215716 --- /dev/null +++ b/537b5e50-VT-d-apply-quirks-at-device-setup-time-rather-than-only-at-boot.patch @@ -0,0 +1,83 @@ +# Commit 5786718fbaafbe47d72cc1512cd93de79b8fc2fa +# Date 2014-05-20 15:53:20 +0200 +# Author Jan Beulich +# Committer Jan Beulich +VT-d: apply quirks at device setup time rather than only at boot + +Accessing extended config space may not be possible at boot time, e.g. +when the memory space used by MMCFG is reserved only via ACPI tables, +but not in the E820/UEFI memory maps (which we need Dom0 to tell us +about). Consequently the change here still leaves the issue unaddressed +for systems where the extended config space remains inaccessible (due +to firmware bugs, i.e. not properly reserving the address space of +those regions). + +With the respective messages now potentially getting logged more than +once, we ought to consider whether we should issue them only if we in +fact were required to do any masking (i.e. if the relevant mask bits +weren't already set). + +This is CVE-2013-3495 / XSA-59. + +Signed-off-by: Jan Beulich +Reviewed-by: Andrew Cooper +Acked-by: Xiantao Zhang +Acked-by: Yang Zhang + +--- a/xen/drivers/passthrough/vtd/extern.h ++++ b/xen/drivers/passthrough/vtd/extern.h +@@ -99,7 +99,7 @@ void platform_quirks_init(void); + void vtd_ops_preamble_quirk(struct iommu* iommu); + void vtd_ops_postamble_quirk(struct iommu* iommu); + void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map); +-void pci_vtd_quirk(struct pci_dev *pdev); ++void pci_vtd_quirk(const struct pci_dev *); + int platform_supports_intremap(void); + int platform_supports_x2apic(void); + +--- a/xen/drivers/passthrough/vtd/iommu.c ++++ b/xen/drivers/passthrough/vtd/iommu.c +@@ -1483,6 +1483,9 @@ static int domain_context_mapping( + break; + } + ++ if ( !ret && devfn == pdev->devfn ) ++ pci_vtd_quirk(pdev); ++ + return ret; + } + +@@ -1922,6 +1925,8 @@ static int intel_iommu_enable_device(str + struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev); + int ret = drhd ? ats_device(pdev, drhd) : -ENODEV; + ++ pci_vtd_quirk(pdev); ++ + if ( ret <= 0 ) + return ret; + +@@ -1993,12 +1998,7 @@ static int intel_iommu_remove_device(u8 + + static int __init setup_dom0_device(u8 devfn, struct pci_dev *pdev) + { +- int err; +- +- err = domain_context_mapping(pdev->domain, devfn, pdev); +- if ( !err && devfn == pdev->devfn ) +- pci_vtd_quirk(pdev); +- return err; ++ return domain_context_mapping(pdev->domain, devfn, pdev); + } + + void clear_fault_bits(struct iommu *iommu) +--- a/xen/drivers/passthrough/vtd/quirks.c ++++ b/xen/drivers/passthrough/vtd/quirks.c +@@ -385,7 +385,7 @@ void me_wifi_quirk(struct domain *domain + * - This can cause system failure upon non-fatal VT-d faults + * - Potential security issue if malicious guest trigger VT-d faults + */ +-void __init pci_vtd_quirk(struct pci_dev *pdev) ++void pci_vtd_quirk(const struct pci_dev *pdev) + { + int seg = pdev->seg; + int bus = pdev->bus; diff --git a/537b5e79-VT-d-extend-error-report-masking-workaround-to-newer-chipsets.patch b/537b5e79-VT-d-extend-error-report-masking-workaround-to-newer-chipsets.patch new file mode 100644 index 0000000..46a0c7e --- /dev/null +++ b/537b5e79-VT-d-extend-error-report-masking-workaround-to-newer-chipsets.patch @@ -0,0 +1,57 @@ +# Commit 04734664eb20c3bf239e473af182bb7ab901d779 +# Date 2014-05-20 15:54:01 +0200 +# Author Jan Beulich +# Committer Jan Beulich +VT-d: extend error report masking workaround to newer chipsets + +Add two more PCI IDs to the set that has been taken care of with a +different workaround long before XSA-59, and (for constency with the +newer workarounds) log a message here too. + +Also move the function wide comment to the cases it applies to; this +should really have been done by d061d200 ("VT-d: suppress UR signaling +for server chipsets"). + +This is CVE-2013-3495 / XSA-59. + +Signed-off-by: Jan Beulich +Reviewed-by: Andrew Cooper +Acked-by: Xiantao Zhang +Acked-by: Yang Zhang + +--- a/xen/drivers/passthrough/vtd/quirks.c ++++ b/xen/drivers/passthrough/vtd/quirks.c +@@ -379,12 +379,6 @@ void me_wifi_quirk(struct domain *domain + } + } + +-/* +- * Mask reporting Intel VT-d faults to IOH core logic: +- * - Some platform escalates VT-d faults to platform errors +- * - This can cause system failure upon non-fatal VT-d faults +- * - Potential security issue if malicious guest trigger VT-d faults +- */ + void pci_vtd_quirk(const struct pci_dev *pdev) + { + int seg = pdev->seg; +@@ -402,10 +396,20 @@ void pci_vtd_quirk(const struct pci_dev + + switch ( pci_conf_read16(seg, bus, dev, func, PCI_DEVICE_ID) ) + { ++ /* ++ * Mask reporting Intel VT-d faults to IOH core logic: ++ * - Some platform escalates VT-d faults to platform errors. ++ * - This can cause system failure upon non-fatal VT-d faults. ++ * - Potential security issue if malicious guest trigger VT-d faults. ++ */ ++ case 0x0e28: /* Xeon-E5v2 (IvyBridge) */ + case 0x342e: /* Tylersburg chipset (Nehalem / Westmere systems) */ ++ case 0x3728: /* Xeon C5500/C3500 (JasperForest) */ + case 0x3c28: /* Sandybridge */ + val = pci_conf_read32(seg, bus, dev, func, 0x1AC); + pci_conf_write32(seg, bus, dev, func, 0x1AC, val | (1 << 31)); ++ printk(XENLOG_INFO "Masked VT-d error signaling on %04x:%02x:%02x.%u\n", ++ seg, bus, dev, func); + break; + + /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */ diff --git a/537b5ede-move-domain-to-cpupool0-before-destroying-it.patch b/537b5ede-move-domain-to-cpupool0-before-destroying-it.patch new file mode 100644 index 0000000..f78652b --- /dev/null +++ b/537b5ede-move-domain-to-cpupool0-before-destroying-it.patch @@ -0,0 +1,53 @@ +# Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a +# Date 2014-05-20 15:55:42 +0200 +# Author Juergen Gross +# Committer Jan Beulich +move domain to cpupool0 before destroying it + +Currently when a domain is destroyed it is removed from the domain_list +before all of it's resources, including the cpupool membership, are freed. +This can lead to a situation where the domain is still member of a cpupool +without for_each_domain_in_cpupool() (or even for_each_domain()) being +able to find it any more. This in turn can result in rejection of removing +the last cpu from a cpupool, because there seems to be still a domain in +the cpupool, even if it can't be found by scanning through all domains. + +This situation can be avoided by moving the domain to be destroyed to +cpupool0 first and then remove it from this cpupool BEFORE deleting it from +the domain_list. As cpupool0 is always active and a domain without any cpupool +membership is implicitly regarded as belonging to cpupool0, this poses no +problem. + +Signed-off-by: Juergen Gross +Reviewed-by: Jan Beulich +Acked-by: George Dunlap + +--- a/xen/common/domain.c ++++ b/xen/common/domain.c +@@ -539,6 +539,8 @@ int domain_kill(struct domain *d) + BUG_ON(rc != -EAGAIN); + break; + } ++ if ( sched_move_domain(d, cpupool0) ) ++ return -EAGAIN; + for_each_vcpu ( d, v ) + unmap_vcpu_info(v); + d->is_dying = DOMDYING_dead; +@@ -721,8 +723,6 @@ static void complete_domain_destroy(stru + + sched_destroy_domain(d); + +- cpupool_rm_domain(d); +- + /* Free page used by xen oprofile buffer. */ + #ifdef CONFIG_XENOPROF + free_xenoprof_pages(d); +@@ -770,6 +770,8 @@ void domain_destroy(struct domain *d) + if ( _atomic_read(old) != 0 ) + return; + ++ cpupool_rm_domain(d); ++ + /* Delete from task list and task hashtable. */ + TRACE_1D(TRC_SCHED_DOM_REM, d->domain_id); + spin_lock(&domlist_update_lock); diff --git a/README.SuSE b/README.SuSE index 8abbbb5..6c9a353 100644 --- a/README.SuSE +++ b/README.SuSE @@ -5,8 +5,8 @@ This file contains SUSE-specific instructions and suggestions for using Xen. For more in-depth documentation of using Xen on SUSE, consult the virtualization chapter in the SLES or SUSE Linux manual, or read up-to-date -virtualization information, including a list of known issues, at -http://www.novell.com/documentation/vmserver/. +virtualization information, at +https://www.suse.com/documentation/sles11/singlehtml/book_xen/book_xen.html For more complete documentation on Xen itself, please install one of the xen-doc-* packages and read the documentation installed into @@ -30,13 +30,10 @@ If you want to install and manage VMs graphically, be sure to install a graphical desktop environment like KDE or GNOME. The following optional packages are needed to manage VMs graphically. Note that "Install Hypervisor and Tools" installs all the packages below: - vm-install (Optional, to install VMs) + virt-install (Optional, to install VMs) virt-manager (Optional, to manage VMs graphically) virt-viewer (Optional, to view VMs outside virt-manager) - -Additional packages: - nbd-client (Optional, to access virtual disks stored on NBD servers) - open-iscsi (Optional, to access virtual disks stored on iSCSI targets) + vm-install (Optional, to install VMs with xl only) You then need to reboot your machine. Instead of booting a normal Linux kernel, you will boot the Xen hypervisor and a slightly changed Linux kernel. @@ -66,7 +63,7 @@ domain 0 may sometimes be referred to as a dom0 kernel. is unprivileged (that is, it cannot control other domains). A kernel used in an unprivileged domain may be referred to as a domU kernel. -Novell documentation will use the more industry-standard term "virtual +SUSE documentation will use the more industry-standard term "virtual machine", or "VM", rather than "domain" where possible. And to that end, domain 0 will be called the "virtual machine server", since it essentially the server on which the other VMs run. All other domains are simply "virtual @@ -110,25 +107,8 @@ If you installed Xen during the initial SUSE installation, or installed one of the kernel-xen* packages later, a "XEN" option should exist in your Grub bootloader. Select that to boot SUSE on top of Xen. -If you want to add additional entries, or modify the existing ones, you will -have to edit Grub yourself. All Xen entries in the Grub configuration file -(usually /boot/grub/menu.lst) look something like this: - -title XEN - root (hd0,5) - kernel /xen.gz - module /vmlinuz-xen - module /initrd-xen - -Replace (hd0,5) with the partition that holds your /boot directory in -grub-speak, e.g., hda1 -> (hd0,0) and sda5 -> (hd2,4). - -Normally, xen.gz requires no parameters. If you want to add parameters, -see below. - -Replace "" with the kernel parameters that you want to pass to -your kernel. These should be very similar, if not identical, to those passed -to a normal kernel that you boot on bare iron. +If you want to add additional entries, or modify the existing ones, you may +run the YaST2 Boot Loader program. Once you have booted this configuration successfully, you are running Xen with a privileged kernel on top of it. @@ -139,44 +119,40 @@ Xen Boot Parameters Normally, xen.gz requires no parameters. However, in special cases (such as debugging or a dedicated VM server) you may wish to pass it parameters. +Adding parameters to xen.gz can be done by editing the /etc/default/grub file. +Add the following line to this file; GRUB_CMDLINE_XEN="". The +parameters may be valid options passed to xen.gz (the hypervisor). After +editing this file, you must run 'grub2-mkconfig -o /boot/grub2/grub.cfg' for +the changes to take effect and then reboot. + In particular in case of problems you may want to attach a serial terminal and direct Xen to send its output not only to the screen, but also to that terminal. In order to do so, add "console=vga,com com=" (without the quotes and with replaced by the serial port number - generally 1 or 2 - and with replaced by the baud rate the serial terminal is configured -for) to the xen.gz line. +for) to the GRUB_CMDLINE_XEN line. For a more complete discussion of possible parameters, see the user documentation in the xen-doc-* packages. -Init scripts ------------- -Before you can create additional VMs (or use any other xm command) xend must -be running. This init script is part of the xen-tools package, and it is -activated at installation time. You can (de)activate it using insserv. You -can also start it manually with "rcxend start". - -The deprecated xendomains script is also shipped, but disabled by default. In -SLES 10 GA (xen 3.0.2) and older, this script allowed VMs to be started and -stopped automatically when the machine starts and stops. In SLES 10 SP1 (xen -3.0.4) and newer, the proper way to start and stop VMs automatically is to set -the "on_xend_start" and "on_xend_stop" settings in the VMs configuration. -(Deprecating xendomains was necessary because xend, not the configuration file -in /etc/xen/vm, is now the authoritative source for the VM's settings.) -Consult the online documentation for more information. - - -Creating a VM with vm-install ------------------------------ -The vm-install program (part of the vm-install package, and accessible +Creating a VM with virt-install +------------------------------- +The virt-install program (part of the virt-install package, and accessible through YaST's Control Center) is the recommended method to create VMs. This -program handles creating both the VM's configuration file and disk(s). It can -help install any operating system, not just SUSE. +program handles creating both the VM's libvirt XML definition and disk(s). +It can help install any operating system, not just SUSE. Virt-install has both +a command line only mode and a graphical wizard mode that may be used to define +and start VM installations. -From the command line, run "vm-install". If the DISPLAY environment variable -is set and the supporting packages (python-gtk) are installed, a graphical -wizard will start. Otherwise, a text wizard will start. +Virt-install may be launched from the virt-manager VM management tool. After +starting virt-manager either from the YaST Control Center or by starting +it from the command line. The installation icon from the main virt-manager +screen may be selected to begin the virt-install installation wizard. + +The use of virt-install or virt-manager requires the installation of the +libvirt packages and the libvirt daemon must be running on the host unless +you are managing a remote host. Each VM needs to have its own root filesystem. The root filesystem can live on a block device (e.g., a hard disk partition, or an LVM2 or EVMS volume) or @@ -193,6 +169,29 @@ boots. (See "Network Troubleshooting" below.) XenSource has been allocated a range of MAC addresses with the OUI of 00-16-3E. By using MACs from this range you can be sure they will not conflict with any physical adapters. +When the VM shuts down (because the installation -- or at least the first +stage of it -- is done), the wizard finalizes the VM's configuration and +restarts the VM. + +The creation of VMs can be automated; read the virt-install man page for more +details. The installation of an OS within the VM can be automated if the OS +supports it. + + +Creating a VM with vm-install +----------------------------- +The vm-install program is also provided to create VMs. Like virt-install, +this optional program handles creating both the VM's Libvirt XML definition +and disk(s). It also creates a legacy configuration file for use with 'xl'. +It can help install any operating system, not just SUSE. + +From the command line, run "vm-install". If the DISPLAY environment variable +is set and the supporting packages (python-gtk) are installed, a graphical +wizard will start. Otherwise, a text wizard will start. If vm-install is +started with the '--use-xl' flag, it will not require libvirt nor attempt +to communicate with libvirt when creating a VM and instead will only use the +'xl' toolstack to start VM installations. + Once you have the VM configured, click "OK". The wizard will now create a configuration file for the VM, and create a disk image. The disk image will exist in /var/lib/xen/images, and a corresponding config file will exist in @@ -210,7 +209,7 @@ supports it. Creating a VM Manually ---------------------- -If you create a VM manually (as opposed to using vm-install, which is the +If you create a VM manually (as opposed to using virt-install, which is the recommended way), you will need to create a disk (or reuse an existing one) and a configuration file. @@ -222,48 +221,68 @@ The kernel and ramdisk used to bootstrap the VM must match any kernel modules that might be present in the VM's disk. It is possible to manually copy the kernel and ramdisk from the VM's disk (for example, after updating the kernel within that VM) to the VM server's filesystem. However, an easier (and less -error-prone) method is to use something called the "domUloader". Before a new +error-prone) method is to use something called the "pygrub". Before a new VM is started, this loader automatically copies the kernel and ramdisk into the VM server's filesystem, so that it can be used to bootstrap the new VM. -See /etc/xen/examples/xmexample.domUloader for an example. Next, make a copy of one of the /etc/xen/examples/* files, and modify it to -suit your needs. For paravirtualized VMs, start with -/etc/xen/examples/xmexample1; for fully virtualized VMs, start with -/etc/xen/examples/xmexample.hvm. You'll need to change (at very least) the -"name" and "disk" parameters. +suit your needs. You'll need to change (at very least) the "name" and "disk" +parameters. See /etc/xen/examples/ for example configuration files. Managing Virtual Machines ------------------------- -VMs can be managed from the command line or from virt-manager. +VMs can be managed from the command line using 'virsh' or from virt-manager. -Before a VM can be started, xend must be informed of it. vm-install will -automatically import new VM configurations into xend. However, if you copy a -VM from another machine, or manually create a VM configuration file, you will -need to import it into xend with a command like: - xm new my-vm -If your VM's configuration file is not located in /etc/xen/vm, you must -specify the full path. This imports the configuration into xend (and -therefore virt-manager becomes aware of it, also). +VMs created by virt-install or vm-install (without vm-install's --use-xl flag) +will automatically be defined in libvirt. VMs defined in libvirt may be managed +by virt-manager or from the command line using the 'virsh' command. However, +if you copy a VM from another machine and manually create a VM XML configuration +file, you will need to import it into libvirt with a command like: + virsh define /my-vm.xml +This imports the configuration into libvirt (and therefore virt-manager becomes +aware of it, also). Now to start the VM: - xm start my-vm -or start it graphically from virt-manager. + virsh start my-vm +or start it from virt-manager's graphical menu. -Have a look at running sessions with "xm list". Note the ID of the newly -created VM. Attach to the VM's text console with "xm console " (replacing -ID with the VM's ID). Attaching to multiple VM consoles is most conveniently -done with the terminal multiplexer "screen". +Have a look at running sessions with "virsh list". Note the ID of the newly +created VM. Attach to the VM's text console with "virsh console " +(replacing ID with the VM's ID). Attaching to multiple VM consoles is most +conveniently done with the terminal multiplexer "screen". -Have a look at the other xm commands by typing "xm help". Note that most xm -commands must be done as root. +Have a look at the other virsh commands by typing "virsh help". Note that most +virsh commands must be done as root. + + +Changes in the Xen VM Management Toolstack +------------------------------------------ +With SUSE Linux Enterprise Server 12, the way VMs are managed has changed +when compared with older SLES versions. Users familiar with the 'xm' command +and the xend management daemon will notice that these are absent. The xm/xend +toolstack has been replaced with the xl toolstack. The xl toolstack is +intended to remain backwards compatible with existing xm domain configuration +files. Most 'xm' commands can simply be replaced with 'xl'. One significant +difference is that xl does not support the concept of Managed Domains. The xl +command can only modifiy running VMs. Once the VM is shutdown, there is no +preserved state information other than what is saved in the configuration +file used to start the VM. In order to provide Managed Domains, users are +encouraged to use libvirt and it's tools to create and modify VMs. These +tools include the command line tool 'virsh' and the graphical tools +virt-manager and virt-install. + +Warning: Using xl commands to modify libvirt managed domains will result in +errors when virsh or virt-manager is used. Please use only virsh or +virt-manager to manage libvirt managed domains. If you are not using libvirt +managed domains then using xl commands is the correct way to modify running +domains. Using the Mouse via VNC in Fully Virtual Mode --------------------------------------------- In a fully virtualized VM, the mouse may be emulated as a PS/2 mouse, USB -mouse, or USB tablet. The vm-install tool selects the best emulation that is +mouse, or USB tablet. The virt-install tool selects the best emulation that is known to be automatically detected and supported by the operating system. However, when accessing some fully virtualized operating systems via VNC, the @@ -302,13 +321,6 @@ Section "InputDevice" EndSection After making these changes, restart gpm and X. -To ensure the VM is emulating a USB tablet, add these lines to the -configuration file in /etc/xen/vm: - usb=1 - usbdevice='tablet' -Then re-import the configuration into xend: - xm new my-vm - HVM Console in Fully Virtual Mode --------------------------------- @@ -411,10 +423,8 @@ compromised, all other domains are compromised as well. To allow relocation of VMs (migration), the receiving machine listens on TCP port 8002. You might want to put firewall rules in place in domain 0 to -restrict this to machines which you trust. You have some access control in -xend-config.sxp as well by tweaking the xend-relocation-hosts-allow -setting. Relocating VMs with sensitive data is not a good idea in untrusted -networks, since the data is not sent encrypted. +restrict this to machines which you trust. Relocating VMs with sensitive data +is not a good idea in untrusted networks, since the data is not sent encrypted. The memory protections for the domUs are effective; so far no way to break out of a virtual machine is known. A VM is an effective jail. @@ -457,7 +467,7 @@ that is reflected in the file's name. Troubleshooting --------------- -First try to get Linux running on bare iron before trying with Xen. +First try to get Linux running on bare metal before trying with Xen. Be sure your Xen hypervisor (xen) and VM kernels (kernel-xen) are compatible. The hypervisor and domain 0 kernel are a matched set, and usually must be @@ -491,7 +501,7 @@ Grub configuration from something like this: To something like this: kernel (hd0,5)/xen-dbg.gz noreboot After rebooting, the Xen hypervisor will write any error messages to the log -file (viewable with the "xm dmesg" command). +file (viewable with the "xl dmesg" command). If problems persist, check if a newer version is available. Well-tested versions will be shipped with SUSE and via YaST Online Update. More frequent @@ -502,10 +512,20 @@ versions will be shipped with SUSE and via YaST Online Update. More frequent Upgrading the Host Operating System ----------------------------------- When upgrading the host operating system from one major release to another -(for example, SLES 10 to SLES 11 or openSUSE 11.4 to openSUSE 12.1) or when -applying a service pack like SLES 11 SP2 to SLES 11 SP1 all running VMs must +(for example, SLES 11 to SLES 12 or openSUSE 12.3 to openSUSE 13.1) or when +applying a service pack like SLES 11 SP3 to SLES 11 SP2 all running VMs must be shut down before the upgrade process is begun. +On versions of SLES 11 and openSUSE 12 you are using the xm/xend toolstack. +After upgrading to SLES 12 and newer openSUSE versions this toolstack will be +replaced with the xl toolstack. The xl toolstack does not support Managed +Domains. If you wish to continue using Managed Domains you must switch to +using libvirt and its command line interface 'virsh'. You may also use +virt-manager as a GUI interface to libvirt. After upgrading the host but +before you can begin using libvirt on VMs that were previously managed by +xm/xend, you must run a conversion tool called /usr/sbin/xen2libvirt for all +VMs. Run 'xen2libvirt -h' to see the syntax for using this tool. + Memory Ballooning in VMs ------------------------ @@ -519,9 +539,10 @@ maxmem value may be increased. A reboot of the VM is required for this action to take effect. -Known Issues ------------- -For a list of known issues and work-arounds, see +Resources +--------- +https://www.suse.com/documentation/sles11/singlehtml/book_xen/book_xen.html +http://doc.opensuse.org/products/draft/SLES/SLES-xen_sd_draft/cha.xen.basics.html http://www.novell.com/documentation/vmserver/. @@ -540,10 +561,10 @@ Feedback In case you have remarks about, problems with, ideas for, or praise for Xen, please report it back to the xen-devel list: xen-devel@lists.xensource.com -If you find issues with the packaging or setup done by Novell/SUSE, please -report it to: - http://www.suse.de/feedback/ +If you find issues with the packaging or setup done by SUSE, please report +it through bugzilla: + https://bugzilla.novell.com ENJOY! - Your Novell SUSE Team. + Your SUSE Team. diff --git a/libxl.add-option-for-discard-support-to-xl-disk-conf.patch b/libxl.add-option-for-discard-support-to-xl-disk-conf.patch index aca3f65..ec12ac5 100644 --- a/libxl.add-option-for-discard-support-to-xl-disk-conf.patch +++ b/libxl.add-option-for-discard-support-to-xl-disk-conf.patch @@ -1,55 +1,57 @@ References: FATE#316071 Subject: libxl: add option for discard support to xl disk configuration -Handle new option discard=on|off for disk configuration. It is supposed -to disable discard support if file based backing storage was +Handle new boolean option discard/no-discard for disk configuration. It +is supposed to disable discard support if file based backing storage was intentionally created non-sparse to avoid fragmentation of the file. -The option is a boolean and intended for the backend driver. A new -boolean property "discard-enable" is written to the backend node. An -upcoming patch for qemu will make use of this property. The kernel -blkback driver may be updated as well to disable discard for phy based -backing storage. +The option intended for the backend driver. A new boolean property +"discard-enable" is written to the backend node. An upcoming patch for +qemu will make use of this property. The kernel blkback driver may be +updated as well to disable discard for phy based backing storage. -This change does not break ABI. Instead of adding a new member ->discard_enable -to struct libxl_device_disk the existing ->readwrite member is reused. +This change does not break ABI. Instead of adding a new member +discard_enable to struct libxl_device_disk the existing readwrite member +is reused. Signed-off-by: Olaf Hering --- - docs/misc/xl-disk-configuration.txt | 15 +++++++++++++++ + docs/misc/xl-disk-configuration.txt | 17 +++++++++++++++++ tools/libxl/libxl.c | 2 ++ - tools/libxl/libxl.h | 11 +++++++++++ + tools/libxl/libxl.h | 12 ++++++++++++ tools/libxl/libxlu_disk.c | 3 +++ tools/libxl/libxlu_disk_i.h | 2 +- - tools/libxl/libxlu_disk_l.l | 4 ++++ - 6 files changed, 36 insertions(+), 1 deletion(-) + tools/libxl/libxlu_disk_l.l | 2 ++ + 6 files changed, 37 insertions(+), 1 deletion(-) Index: xen-4.4.0-testing/docs/misc/xl-disk-configuration.txt =================================================================== --- xen-4.4.0-testing.orig/docs/misc/xl-disk-configuration.txt +++ xen-4.4.0-testing/docs/misc/xl-disk-configuration.txt -@@ -178,6 +178,21 @@ information to be interpreted by the exe - These scripts are normally called "block-