Gandi provides you with a virtual server that you have ordered to fit your needs. Along with the advantages of a virtual dedicated server comes the responsibility of maintaining the system, however. Gandi cannot directly intervene in the administration of your server, or in correcting mistakes, debugging your code or providing assistance in the configuration of your server.
You have to migrate on the new Gandi AI version (2011) in order to upgrade the modules as PHP, the old Gandi AI can provide PHP up to 5.2.3 only.
See Using the emergency console.
See using apt-get for deb based distribution (like Debian or Ubuntu). For rpm based distribution, you will have to use the dedicated tool from the distribution : yum for Fedora, CentOS, urpmi for Mandriva, …
ssh-keygen -R your_ip_address
here : Updating kernel modules.
here : How to fix error when updating packages.
The gandi-hosting-vm package is installed by default on all OS image prepared by our technical team. It install files in their correct path and you can modify its behavior at boot time with this config file : /etc/sysconfig/gandi. More information in : http://lacuisinedegandi.net/post/2010/10/28/Modification-des-OS-standards-par-Gandi
Update the gandi-hosting-vm package using Gandi APT sources
Stop / start your VPS in two times on the control panel
Do the procedure described on our wiki again
When detaching a disk and if no incident on our hosting plaform has been published, the main cause is a running application still using files on the currently detaching disk. When the kernel cannot release the disk to the Xen subsystem, it print a message in the 'dmesg' output.
By using either 'lsof' of 'fuser' command, you can try to identify which process in memory is using the disk and blocking the detach operation.
CentOS is installing by default iscsi and iscsid, you can remove those packages, or just stop it, that will have no impact on the VPS, we use it for the backend but not on the VPS, this will avoid the logs errors.
It is necessary to follow this process :
- install & activate the EPEL repository - install the python-ctypes package
And Gsync works ! (Thank to Christophe Gimenez for the report).
The new kernels are not supporting XFS anymore, you have to create a new disk on our platform which will be formatted as Ext4, then transfer your files.
You did not use the correct IP address for your server or the server does not exist behind this IP address. Check the status of your server in your administration page on the site. |
Input/ouput resources are collected by our Xen infrastructure, the use of your RAM have to be done from a program inside your virtuel server. More details : ici|
The kernel used by a server at boot is provided by the Xen infrastructure. Therefore kernel installed by package managment or even local compilation could not be used to boot a server. The Gandi team provide a set of kernel which you can associate with your kernel. See the next entry for choosing the kernel version.
The kernel used by a server at boot is associated with the 'main' disk. This disk is shown with a 'Boot disk' checked in the disk list in the server detail page in the hosting customer account. In the detailled page of this disk - after clicking on the disk name-, you will be able to choose a kernel version. After validating the operation, you will have to stop and start your virtual server.
This behavior is the result of the configuration of the file system about inotify options. These options allow the filesystem driver to warn the kernel about change in a directory that gsync watches. If the value of these options are to low, gsync will not backup completly the directory.
If your server is GandiAI please contact the support which will configure your server. If your server is in expert mode, please add these options to the /etc/sysctl.conf file :
fs.inotify.max_user_instances = 128 fs.inotify.max_user_watches = 8192 fs.inotify.max_queued_events = 16384
Note:
To apply change, add the entries in the /etc/sysctl.conf file and start the command : sysctl -p /etc/sysctl.conf"Write barriers" are part of a mechanism used by file systems to guarantee that some kind of I/O request are send to the disk in a specific order. The current implementation is not efficient et is currently rewritten.Their performance impact is big for some rare case of corruption when the server is crashing at the wrong moment. LVM ("device-mapper") and our current Xen setup does not support this feature.
When the file system is mounted it tries to detect the disk ability to handle this feature by setting a write barrier. The erreur (standard) return by the 'disk' subsystem is systematicaly registered in the request management system and generate this log entry as well as the "JBD: barrier-based sync failed on XXX" message. These messages can be ignored.
If the error message appears outside of the previous context (during the boot, when disk are attached to the server) or following another kind of message you should investigate further.
After april 2011, Gandi is using another storage infrastructure along the old one based on LVM. In the new model the main disk of your server does not contains any partition table anymore. The file system if created directly in the /dev/xvda1 disk.
If the file /proc/partitions does not contain /dev/xvda but only /dev/xvda1 you are on this new storage infrastructure. In this case simply resize the file system on /dev/xvda1 using :
resize2fs /dev/xvda1
This comande may return an error telling you to checking the filesystem before resizing.
We mainly focus on Long Time Support version of Ubuntu (10.04 at the moment) which have 5 years upstream support. Our local mirror of Ubuntu package tree is updated each day. So a new release will be available the next. About OS image usable to create server, we try to release an image in both architecture (32 and 64 bits) in both of our datacenter no more than one week after the official Ubuntu release. This give us time to properly create the image and to wait a couple of days for any major bug discovery. This is not as fast with the RPM distribution.
What you see is in fact the physical CPUs of the physical machine. To see your virtual CPU cores, we invite you to use the "top" command, then type on the "1" key in order to see separate CPU cores in top.
Last modified: 29 Sep 2011 at 17:47 by Emerick M. (Gandi)