XenServer 6 autostart VMs or vApps

In XenServer 5.6 there was the autostart feature on VMs. When the autostart checkbox on the VM was enabled, the VMs would start automatically after the XenServer host environment was powered up. In XenServer 6, this feature is removed from the XenCenter console. There are multiple blogposts that describe how to re-enable the autostart feature from the commandline. But that is not needed. You can use the new vApp feature. With vApps you can accomplish the same, but better. vApps is a logical grouping of multiple VMs. For example you can create a vApp “core infrastructure”, put your domaincontroller and licenseserver in it and some additional servers. In a vApp you can also define the order in which VMs are started and also a delay time between the startup sequence. So vApps is much more flexible than autostart. You can find vApp in XenCenter under Pool –> Manage vApps.

• Create a new vApp
• Assign VMs. A VM can be added to only one vApp at a time
• Change VM startup sequence. Add delays between sequences.

That’s it. This is a Pool feature, but it will also work with just one stand-alone XenServer. The automatic starting of a vApp only works for a paid version of XenServer. Although the administrators guide mentions vApps in combination with HA (High Availability) or DR (Disaster Recovery), you don’t need the platinum edition for vApps. In fact, you don’t need HA. I have it running with the Advanced Edition without HA enabled. If you want automatic starting of a vApp with the free version of XenServer you have to use the following commands:
List the vApps: xe appliance-list
Start a vApp: xe appliance-start uuid=<appliance-uuid>
Add above command to /etc/rc.local
So forget the autostart feature, use vApps. Even with the free version of XenServer you can use it.

Cheat XCP (Xen Cloud Platform)

I been spending perhaps way to much time getting to learn the Xen Cloud Platform over the last couple of weeks. I have been beating my brains the last couple of nights trying to figure out why certain features were not showing in XenCenter client. Why does XenCenter report that the license is going to expire in 30 days (even though XCP is FOSS). After a prolong search I came across mailing list with the answers I seek. Basically XenCenter treats XCP as a really old version of XenServer, even though XCP is based on XenServer 5.6 FP1. To get around this just do the following:

Create a new file in /etc/xensource/ and name it xapi_version_override

In this file place this value of 5.6.199 in it.

Now just restart XCP and next time you bring up XenCenter it will see XCP as 5.6.199. As for licensing, you can apparently apply the free license to XCP if you desire to. But in the end it is a none issue none functionality will be going away.

Command enable openVswitch on XenServer

Command enable openVswitch on XenServer

#xe-switch-network-backend openvswitch

#reboot

Cpuunits & Cpulimit

There are two parameters controlling fair CPU scheduler in OpenVZ: cpuunits and cpulimit.

cpuunits

Cpuunits are set via
vzctl set 101 --cpuunits 1000 --save
For example. If you set a cpuunit for one container to a value and set a cpuunit on another container to a different value, the time allotted to each of the containers will be the ratio of the two units. Let's use a real example.
We did the following:
vzctl set 101 --cpuunits 1000 --save
vzctl set 102 --cpuunits 2000 --save
vzctl set 103 --cpuunits 3000 --save
If we started a CPU intensive application on each CT, then 103 would be given 3 times as much cpu time as 101 and 102 would get twice as much as 101, but some fraction of what 103 got. Here's how to determine what the real ratios are.
Add the three units, 1000+2000+3000 = 6000
101 gets 1000/6000 or 1/6th of the time. (16%) 102 gets 2000/6000 or 1/3rd of the time. (34%) 103 gets 3000/6000 or 1/2 of the time. (50%)

cpulimit

The cpulimit parameter sets the absolute maximum limit for a container to a percent value. For instance:
vzctl set 101 --cpulimit 25 --save
says that container 101 cannot ever have more than 25 percent of a CPU even if the CPU is idle for the other 75% of the time. The limit is calculated as a percentage of a single CPU, not as a percentage of the server's CPU resources as a whole. In other words, if you have more than one CPU, you can set a cpulimit > 100. In a quad-core server, setting cpulimit to 100 permits a container to consume one entire core (and not 100% of the server).
CPU limits are only available in rhel5-based and rhel6-based kernels and they behave a bit differently in them.
In the rhel5 kernel the limit has a container-wide meaning. That said if you have e.g. a container of 2 CPUS with the 100% cpulimit set, this container's usage of CPUs can be 100%/0% or 50%/50% or any other values, whose sum is 100%.
In the rhel6 kernel the applied limit is divided between onlince CPUs proportionally and a busy CPU cannot borrow time from an idle one. I.e. with a 2 CPUs container and 100% limit set the usage of each CPU cannot exceed 50% in any case

(http://wiki.openvz.org/Resource_shortage)

www.studyall.co.cc

Setup citrix xenserver

1. Setup Xenserver từ source ISO bình thường. (link http://www.citrix.com/tv/#videos/103 hoặc http://www.citrix-tips.com/438/citrix-xenserver-installation-guide-2/ )