Showing posts with label Xen Virtualization. Show all posts
Showing posts with label Xen Virtualization. Show all posts

How to turn on VT-d in Xen

1 ) cd xen-unstable.hg
2 ) make install
3 ) make linux-2.6-xen-config CONFIGMODE=menuconfig
4 ) change XEN->"PCI-device backend driver" from "M" to "*".
5 ) make linux-2.6-xen-build
6 ) make linux-2.6-xen-install
7 ) depmod 2.6.18.8-xen
8 ) mkinitrd -v -f --with=ahci --with=aacraid --with=sd_mod --with=scsi_mod initrd-2.6.18-xen.img 2.6.18.8-xen
9 ) cp initrd-2.6.18-xen.img /boot
10) lspci - select the PCI BDF you want to assign to guest OS
11) "hide" pci device from dom0 as following sample grub entry:
title Xen-Fedora Core (2.6.18-xen)
root (hd0,0)
kernel /boot/xen.gz com1=115200,8n1 console=com1 iommu=1
module /boot/vmlinuz-2.6.18.8-xen root=LABEL=/ ro xencons=ttyS console=tty0 console=ttyS0, pciback.hide=(01:00.0)(03:00.0)
module /boot/initrd-2.6.18-xen.img
12) reboot system
13) add "pci" line in /etc/xen/hvm.conf for to assigned devices
pci = [ '01:00.0', '03:00.0' ]
15) start hvm guest and use "lspci" to see the passthru device and
"ifconfig" to see if IP address has been assigned to NIC devices.

VT-d Works on OS

1) Host OS: PAE, 64-bit
2) Guest OS: 32-bit, PAE, 64-bit

Combinations Tested

1) 64-bit host: 32/PAE/64 Linux/XP/Win2003/Vista guests
2) PAE host: 32/PAE Linux/XP/Win2003/Vista guests

Enabled Systems

1) For VT-d enabling work on Xen, we have been using development systems using following Intel motherboards:
- DQ35MP
- DQ35JO

Note from Intel on VT-d compatbility:
VT-d is enabled on the following chipsets:
Intel Q35
Intel Q45
The following chipsets have VT-d capability, but OEMs may not have it enabled on boards based on these:
Intel X38
Intel X48
For Intel Desktop Boards, these have VT-d support enabled:
Intel DQ35JO
Intel DQ35MP
Intel DX38BT
Intel DX48BT2
Intel DQ45CB (BIOS 0061 required, previous versions are known to cause problems)
Intel DQ45EK
Intel DX58SO
For ASUS Desktop Boards, these have VT-d support enabled:
ASUS P5E-VM DO (Intel Q35 chipset)
For ASUS Desktop Boards, these DO NOT have VT-d support enabled:
ASUS P5E (Intel X38 chipset)

2) As far as we know, following OEM systems also has vt-d enabled. Feel free to add others as they become available.
- Dell: Optiplex 755 http://www.dell.com/content/products/category.aspx/optix?c=us&cs=555&l=en&s=biz
- HP Compaq: DC7800 http://h10010.www1.hp.com/wwpc/us/en/en/WF04a/12454-12454-64287-321860-3328898.html
- Fujitsu-Siemens: Esprimo 5925 http://facts.fujitsu-siemens.com/index.cfm?fuseaction=dspcontent&lid=134&page=3

Caveat on Conventional PCI Device Passthrough

VT-d spec specifies that all conventional PCI devices behind a PCIe-to-PCI bridge have to be assigned to the same domain.

PCIe devices do not have this restriction

VTd device hotplug

2 virtual PCI slots (6~7) are reserved in HVM guest to support VTd hotplug. If you have more VTd devices, only 2 of them can support hotplug. Usage is simple:

1.

List the VTd device by dom. You can see a VTd device 0:2:0.0 is inserted in the HVM domain's PCI slot 6. lspci inside the guest should see the same.

[root@vt-vtd ~]# xm pci-list HVMDomainVtd
VSlt domain bus slot func
0x6 0x0 0x02 0x00 0x0

1. detach the device from the guest by the physical BDF. Then HVM guest will receive a virtual PCI hot removal event to detach the physical device

[root@vt-vtd ~]# xm pci-detach HVMDomainVtd 0:2:0.0

1. attach a PCI device to the guest by the physical BDF and desired virtual slot(optional). Following command would insert the physical device into guest's virtual slot 7

[root@vt-vtd ~]# xm pci-attach HVMDomainVtd 0:2:0.0 7

VTd hotplug usage model

* for live migration: As you know, VTd device would break the live migration as physical device can't be save/restored like virtual device. With hotplug, live migration is back again. Just hot remove all the VTd devices before live migration and hot add new VTd devices on target machine after live migration.
* VTd hotplug for device switch: VTd hotplug can be used to dynamically switch physical device between different HVM guest without shutdown.

How to enable MSI/MSI-X for assigned devices?

Before changeset 18127: 89d05940cc1c: Add an option "msi_irq_enable=1" in grub. It should appear like "kernel xen.gz msi_irq_enable=1 ".

From changeset 18127: 89d05940cc1c to changeset 18453: 7f1c71c6d4c8: (Changeset 18127 changed the parametar to "msi".) Add an option "msi=1" in grub. It should appear like "kernel xen.gz msi=1 ".

From changeset 18454: 65dc37be0443 on, we always have msi=1. We can't use a Xen grub parameter to set the value to 0.



How to list the currently assignable devices in a host?

From changeset: 18047:39c2cab9e765 on (Later some improvements were made, so we'd betetr use a changeset >=18149:13690b68fd46), there is a shell utility "xm pci-list-assignable-devices". The utility finds all the devices owned by pciback, checks if they have proper FLR method, checks if they have page-alinged MMIO BARs, and checks if the devices have been already assigned, finally it prints out the assignable devices. Note: the utility assumes the integrated devices (whose bus numbers are 0) have proper FLR method.

Enable DMA in Xen Virualization

Enabling DMA on your disk

Prerequisites

First, you need to be sure that DMA is disabled. You can check this with the following command:

# hdparm /dev/hda

If your harddisk is not hda, for example if you are using a SATA drive, or this is not your first harddisk, then substitute the appropriate device. You should get output similar to:

# hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 240121728, start = 0

If using_dma is on (as above) then you are all set. DMA is enabled, and the drive should be operating pretty much as fast as it can go. If this is not the case, then you can read on...

What to do to enable DMA

First, you can hope that your chipset is supported, and try doing:

# hdparm -d 1 /dev/hda

/dev/hda:
setting using_dma to 1 (on)
using_dma = 1 (on)

With luck, this will enable DMA on your disk for you. If so, you are now set, it is possible that your distribution will have some way of setting this on bootup.

If this did not work... don't panic yet. Basically it means that your dom0 kernel is not able to set DMA on your chipset. Try loading the appropriate kernel module, you may have to reboot and disable the "generic" module to ensure that the "generic" module does not claim your chipset.

Install Xen in Debian Linux

My assumptions here are that you have a free partition named /dev/hda5 which you can use for setting up a LVM partition.

The following values can offcourse be changed suited to your needs:

*

-L at lvcreate to set size for your partitions
*

memory = in /etc/xen/domu1 to set memory size for the domU

The domU uses kernel "/boot/vmlinuz-2.6.11-xenU", because this document was written with Xen 2.0.7 installed. This setup however also works up until the last Xen unstable (3.0) version. The domU kernel line changes into the kernel supplied by the Xen version of your choice.

* install the base system:

apt-get install lvm2
pvcreate /dev/hda5
vgcreate lvmxen /dev/hda5
lvcreate -L1G -n domu1 lvmxen
lvcreate -L256M -n domu1-swap lvmxen
mke2fs /dev/lvmxen/domu1
tune2fs -j /dev/lvmxen/domu1
mkswap /dev/lvmxen/domu1-swap
mount /dev/lvmxen/domu1 /mnt
debootstrap sarge /mnt

# It can be possible that debootsrap spits out an error message
# like: E: Couldn't find these debs: 33024830
# use the following command line for debootstrap if this is the case.
#
# debootstrap --resolve-deps sarge /mnt

mv /mnt/lib/tls /mnt/lib/tls.disabled

*

put in /mnt/etc/network/interfaces:

auto lo
iface lo inet loopback

*

put in /mnt/etc/fstab:

# /etc/fstab: static file system information.
#
#
proc /proc proc defaults 0 0
/dev/hda1 / ext3 defaults,errors=remount-ro 0 1
/dev/hda2 none swap sw 0 0

* create ttys

cd /dev
./MAKEDEV tty1 tty2 tty3 tty4 tty5 tty6

* unmount the newly created domU

cd /
umount /mnt

*

create a /etc/xen/domu1 file, for example:

# -*- mode: python; -*-
kernel = "/boot/vmlinuz-2.6.11-xenU"
memory = 128
name = "domu1"
vif = [' bridge=xen-br0' ]
disk = ['phy:/dev/lvmxen/domu1,hda1,w','phy:/dev/lvmxen/domu1-swap,hda2,w']
ip="192.168.2.103"
netmask="255.255.255.0"
gateway="192.168.2.1"
hostname = "domu1"
root = "/dev/hda1 ro"
extra = "4"

*

start the domU with xm create domu1 -c
*

log in as root, run base-config, happy xenning :-)

--

for a xen 3.0.0 source install, the /etc/xen/domu1 file must have the following values changed in /etc/xen/domu1:

* kernel = "/boot/vmlinuz-2.6.12-xen" vif = [' bridge=xenbr0' ]

Xen Virtual LAN

Describe XenDom0VLANstoDomUVirtualNICs here.

These are very simple instructions for mapping VLANs on the Dom0 through to the DomU NICs. Redhat/CentOS specific, and in this example the NICs were mapped through to a HVM Windoze box.

Other descriptions to help being picked up by search engines is: - VLAN trunk to virtual machine mapping - VLANs to DomU interfaces

Essentially: a. Create a bridge group for each .1q interface you want, and add the interfaces to the bridge. b. Map each virtual NIC to the bridge group. c. Don't forget to set the MTU in Windoze


1. Configure the bond interface, and create VLAN interfaces on the bond interface. Create a bridge and map each vlan interface into the bridge. All the files for this are at /etc/sysconfig/network-scripts/. (This examples creates VLAN 900-903.) You will need to change the HWADDR to match you NIC cards.

These are all the related files:

/etc/sysconfig/network-scripts/ifcfg-eth0

/etc/sysconfig/network-scripts/ifcfg-eth1
/etc/sysconfig/network-scripts/ifcfg-bond0
/etc/sysconfig/network-scripts/ifcfg-bond0.900
/etc/sysconfig/network-scripts/ifcfg-bond0.901
/etc/sysconfig/network-scripts/ifcfg-bond0.902
/etc/sysconfig/network-scripts/ifcfg-bond0.903
/etc/sysconfig/network-scripts/ifcfg-br900
/etc/sysconfig/network-scripts/ifcfg-br901
/etc/sysconfig/network-scripts/ifcfg-br902
/etc/sysconfig/network-scripts/ifcfg-br903

1.1 These files configure the real ethernet ports to be part of an active/standby 'bond' interface.

/etc/sysconfig/network-scripts/ifcfg-eth0

# Intel Corporation 82541GI Gigabit Ethernet Controller

DEVICE=eth0
BOOTPROTO=none
HWADDR=00:15:17:28:f6:34
ONBOOT=yes
TYPE=Ethernet
#ETHTOOL_OPTS="autoneg off speed 100 duplex full"
MASTER=bond0
SLAVE=yes
USERCTL=no

/etc/sysconfig/network-scripts/ifcfg-eth1

# Intel Corporation 82566DM-2 Gigabit Network Connection

DEVICE=eth1
BOOTPROTO=none
HWADDR=00:15:17:28:f6:36
ONBOOT=yes
TYPE=Ethernet
#ETHTOOL_OPTS="autoneg off speed 100 duplex full"
MASTER=bond0
SLAVE=yes
USERCTL=no

1.2 This is the bond interface configuration.

Here the bond0 interface, in Dom0, is actually getting a IP via dhcp. You may want to set BOOTPROTO=none if you don't want this. The 'virtual mac' address is set here. Make sure this is unique.

/etc/sysconfig/network-scripts/ifcfg-bond0

DEVICE=bond0

BOOTPROTO=dhcp
ONBOOT=yes
USERCTL=no
#PEERDNS=no
IPV6INIT=no
MACADDR=52:54:00:12:45:56
BONDING_OPTS="mode=1 miimon=100 primary=eth0"

1.3 Now create the bridges.

/etc/sysconfig/network-scripts/ifcfg-br900

DEVICE=br900

TYPE=Bridge
#STP=on
ONBOOT=yes
BOOTPROTO=none

...

DEVICE=br903

TYPE=Bridge
#STP=on
ONBOOT=yes
BOOTPROTO=none

1.4 Now the creation of all the VLAN interfaces, which are put into the bridges.

/etc/sysconfig/network-scripts/ifcfg-bond0.900

DEVICE=bond0.900

PHYSDEV=bond0
ONBOOT=yes
BOOTPROTO=none
VLAN=yes
BRIDGE=br900

...

DEVICE=bond0.903

PHYSDEV=bond0
ONBOOT=yes
BOOTPROTO=none
VLAN=yes
BRIDGE=br903

2. Load the bond-ing module.The main thing to add is below (rest of the bond is set in the file above). Reload or modprobe.

alias bond0 bonding

3. Finally, the important line in the Xen xm config file is:

vif = [ 'type=ioemu, bridge=br900', 'type=ioemu, bridge=br901',

'type=ioemu, bridge=br902', 'type=ioemu, bridge=br903' ]

4. Don't forget to set the MTU to 1494 using the 'regedit' if you are using windoze.


If you are using Centos/Redhat you can also use 'virsh' which has a XML virtual machine definition. 'virsh' seems to be strongly supported by Redhat, and XML is fairly clean, so instead of just using the 'xm' style files do this:



vm_name
256000
/usr/bin/pygrub
destroy
restart
restart
2