Manage the boot of virtual machines
One of the ideas, within which the selector cloud develops, is maximum administrator freedom when working with a cloud machine. Differences with the real server should be minimal, and all new functions should not disrupt the feeling of a “real” machine.
Now we have taken a very big step to implement this - we implemented a load management interface. Up to this point, experiments with booting (different kernel versions, boot options, etc.) could lead to a non-working machine, and fixing this problem was problematic (unplugging the disk, plugging it back, etc.).
Now this problem is solved. I think these two screenshots will explain the capabilities of the system more than the test description:
')
Just want to warn you that the configuration dialog is far from the safest thing. The absence of some options at boot or, on the contrary, extraneous options can make the virtual machine non-working.
Not all kernels are compatible with all distributions. For example, loading modern systems from 2.6.18 is not a good idea. Shipping Centos with 3.1 - too.
The selection begins with an indication of where to ship the core. There are two options: “from the virtual machine disk” and “external kernel”. We provide the external core (along with the initrd), the internal one is read from the boot disk. If the internal core is selected, you can specify which disk to boot from and specify the grub menu item. An empty field means "default".
In this mode, the “Kernel Parameters” are appended to the arguments that are written in grub.cfg (menu.lst). In particular, this opens the way to the single and init = / bin / sh options.
The second mode is the external kernel boot mode. For Centos, it is best to choose 2.6.18, for all others - 3.1 (2.6.34 left just in case).
Important: in the external kernel mode, the arguments are taken only from the “kernel parameters” field. If you do not specify all the necessary arguments here, there will be problems with loading. The key parameters that should be - barrier = off (for 3.1, without it there will be problems with ext4), console (without it there will be no console) and root (without it, the system will not know where to boot from). A sample of the parameters is inserted automatically when selecting one or another kernel, however, you need to understand that this is just a sample, and most likely, when externally loaded, you will need to specify additional parameters (for example, changing the console settings to console = xvc0 when loading 3.1 to debian ).
The kernel accepts a lot of parameters, some of them are processed by the kernel, some of them are modules. A complete list of the possible (not all that is applicable in the conditions of virtualization) is here .
Now we have taken a very big step to implement this - we implemented a load management interface. Up to this point, experiments with booting (different kernel versions, boot options, etc.) could lead to a non-working machine, and fixing this problem was problematic (unplugging the disk, plugging it back, etc.).
Now this problem is solved. I think these two screenshots will explain the capabilities of the system more than the test description:
')
Just want to warn you that the configuration dialog is far from the safest thing. The absence of some options at boot or, on the contrary, extraneous options can make the virtual machine non-working.
Not all kernels are compatible with all distributions. For example, loading modern systems from 2.6.18 is not a good idea. Shipping Centos with 3.1 - too.
Detailed description
The selection begins with an indication of where to ship the core. There are two options: “from the virtual machine disk” and “external kernel”. We provide the external core (along with the initrd), the internal one is read from the boot disk. If the internal core is selected, you can specify which disk to boot from and specify the grub menu item. An empty field means "default".
In this mode, the “Kernel Parameters” are appended to the arguments that are written in grub.cfg (menu.lst). In particular, this opens the way to the single and init = / bin / sh options.
The second mode is the external kernel boot mode. For Centos, it is best to choose 2.6.18, for all others - 3.1 (2.6.34 left just in case).
Important: in the external kernel mode, the arguments are taken only from the “kernel parameters” field. If you do not specify all the necessary arguments here, there will be problems with loading. The key parameters that should be - barrier = off (for 3.1, without it there will be problems with ext4), console (without it there will be no console) and root (without it, the system will not know where to boot from). A sample of the parameters is inserted automatically when selecting one or another kernel, however, you need to understand that this is just a sample, and most likely, when externally loaded, you will need to specify additional parameters (for example, changing the console settings to console = xvc0 when loading 3.1 to debian ).
The kernel accepts a lot of parameters, some of them are processed by the kernel, some of them are modules. A complete list of the possible (not all that is applicable in the conditions of virtualization) is here .
Source: https://habr.com/ru/post/143656/
All Articles