Proxmox 3.1: installation details out of the box
The virtualization system "Proxmox" on Habré is dedicated to several posts, and, of course, before writing this post, I had the opportunity to study them for my own experiment. My research was to install Proxmox 3.1 on bare metal, configure it, and transfer existing virtual machines from VMWare to a new system. Installing the OS was made, as the name implies, from the distribution of Proxmox 3.1, "as is." During the installation, configuration, and import of virtual machines, interesting moments arose, which I would like to share with the community.
After installing the OS from the disk, the system reboots and the Proxmox first starts, at this moment the message “GRUB LOADING ..” is displayed and the launch stops.
The “GRUB LOADING ..” problem is related to 2 factors that should be considered when installing a proxmox:
After creating a container in the web interface, there is a problem with setting up the network. When configuring, it is possible to specify an ip address, but this will be virtual NAT, i.e. Access to the container is possible with vhost, but not from the entire network. In order for the container to be accessible from the entire network, you need to configure ethernet (eth0). At the installation stage, eth0 can also be configured, but the ip address will not be assigned. And in the eth0 container itself is missing (ifconfig command does not show it). This is where the problem arises: how to configure the bridge interface.
According to the materials on setting up networks OpenVZ , you must do the following: enter the container ("100" - container id)
define the interface eth0 in the container system (without this step, the next step will be valid until the container is reloaded)
then configure the eth0 interface
or constantly add to / etc / network / interfaces
The compression procedure for vmdk drives, in my opinion, is very important because The amount of physical disk is always limited.
The procedure for restoring a virtual guest system in Proxmox through a web interface is well known, however, it’s not clear how this happens in the console. Guest systems (KVM talk) are backed up to the file vzdump-qemu-id-date-time.vma.gz. This is an archive of a pre-packaged virtual disk and a guest OS configuration file.
It is logical to first get the file .vma:
where 103 is the guest number in Proxmox
Next, you need to locate the file vzdump-qemu-103-date-time.vma. For this, in Proxmox 3.1 there is a special utility vma
Note: the command will work without errors, unless you create the directory “103” in the / var directory. As a result, there will be a couple of files in / var / 103 /:
Note: if we restored the guest system with a vmdk disk, then the recovered disk will be in raw format. You can fix this by converting to the required format:
"Proper OS Shutdown" for Proxmox (KVM) guest systems means simulating the event of "pressing the system off button on a physical machine." Such shutdown works correctly in unix-systems. This is achieved by a command in QEMU:
However, in guest Windows systems in the background, the command returns an error and the system does not shut down. Disconnection occurs “correctly” only in case of successful login to the system, or “forcibly” (event “disconnecting the power cord”) - by another command (qm stop 103). It is possible to correct this situation by adjusting the local guest Windows OS policy:
Start - Control Panel - Administration - Local Security Policy - Security Settings - Local Policies - Security Settings - Shut Down: Allow the system to shutdown without logging in (“Enable”)
The first moment: Installation of the system and the message "GRUB LOADING ..."
After installing the OS from the disk, the system reboots and the Proxmox first starts, at this moment the message “GRUB LOADING ..” is displayed and the launch stops.
The “GRUB LOADING ..” problem is related to 2 factors that should be considered when installing a proxmox:
- The hard disk on which the OS is installed should always be first at startup (unfortunately, the corresponding setting of the boot order option in the BIOS does not give the desired result, a paradox, but you need to find the desired sata0 port and load the system in the correct configuration)
- the drive must always be connected (without a drive we will observe “GRUB LOADING ..”, obviously, the drive device appears in the startup scripts)
The second moment: Setting up the network in an openvz container (proxmox) or activating an interface like bridge
After creating a container in the web interface, there is a problem with setting up the network. When configuring, it is possible to specify an ip address, but this will be virtual NAT, i.e. Access to the container is possible with vhost, but not from the entire network. In order for the container to be accessible from the entire network, you need to configure ethernet (eth0). At the installation stage, eth0 can also be configured, but the ip address will not be assigned. And in the eth0 container itself is missing (ifconfig command does not show it). This is where the problem arises: how to configure the bridge interface.
According to the materials on setting up networks OpenVZ , you must do the following: enter the container ("100" - container id)
vzctr enter 100
define the interface eth0 in the container system (without this step, the next step will be valid until the container is reloaded)
ifconfig eth0 0
then configure the eth0 interface
ifconfig eth0 192.168.XXX.XXX netmask 255.255.255.0 ip route add 192.168.XXX.YYY dev eth0 ip route add default via 192.168.XXX.YYY
or constantly add to / etc / network / interfaces
auto eth0 iface eth0 inet static address 192.168.XXX.XXX netmask 255.255.255.0 gateway 192.168.XXX.YYY
The third moment: Import VMWare virtual machines to KVM Proxmox
- Import freebsd.vmdk
Before importing an existing VMWare virtual machine with FreeBSD, you need to create a prototype of it on Proxmox KVM with the same parameters, choosing the “vmdk” disk format, type IDE. After creating the prototype, copy the “freebsd.vmdk” disk to / var / lib / vz / images / id /, rename it (giving the name of the created disk) and start the virtual machine. If the download ends with a root partition search, then we load the frenzy disk into the drive of the machine and repeat the launch from live-cd in hdrw mode (write to disk). We look at the mounted df -h slices, we find the disk marking (ad or da), we edit the / etc / fstab file, changing the disk marking to the one obtained in the previous command. After successful loading of OS it will be necessary to edit and the network interface. - Import windows.vmdk
You must first load the imported VMWare virtual machine into your native software, then add the IDE drivers information to the registry in the loaded machine, copy pciide.sys to% SystemRoot% System32 / Drivers. Uninstall from VMWare Tools virtual system, unmount virtual machine and copy vmdk virtual disk file to Proxmox (KVM). Load a virtual system with an imported disk (IDE type).
The fourth moment: Compress VMDK virtual disks in Proxmox
The compression procedure for vmdk drives, in my opinion, is very important because The amount of physical disk is always limited.
- Compress WINDOWS.vmdk
Compressing virtual disks is associated with the effect of “inflating” the vmdk file (increasing the file size) when the guest virtual system is running. To compress a virtual disk format VMDK with MS Windows OS, you can use a pair of utilities from VMWare: vmware-mount and vmware-vmdiskmanager - as part of the VDDK package, you can download from the office. site . Since Proxmox works on Debian, then we download the linux64 archive and install it:
tar -xzf VMware-vix-disklib-5.1.0-774844.x86_64.tar.gz
cd ./vmware-vix-disklib-distrib
./vmware-install.pl
After installation, you need to add a line to /etc/ld.so.conf:
/usr/lib/vmware-vix-disklib/lib64
Further utilities are ready to work with disks. Turn off the guest virtual system, the disk of which will be subject to compression. The vmdk disk compression procedure consists of three phases:
- vmdk disk defragmentation
vmware-vdiskmanager -d /path/to/name.vmdk - disk compression preparation
vmware-mount /path/to/name.vmdk /mnt/vmdk/
If during the mount, an error occurs about an unknown NTFS file system, you must load the support for this system into Debian:
apt-get install ntfs-3g
vmware-vdiskmanager -p /mnt/vmdk/ - disk compression
vmware-mount -x # vmdk
losetup -d /dev/loop0 # : "device is busy"
vmware-mount -x #
vmware-vdiskmanager -k /path/to/name.vmdk #
The effect of vmdk disk compression is to the true size of the disk in the guest virtual system.
- vmdk disk defragmentation
- Compress FREEBSD.vmdk
For compressing a virtual disk with FREEBSD, the above utilities will not work, because There is a problem mounting a vmdk disk to the host system: Debian does not know the UFS file system. However, there is a solution, you can use the built-in features of FreeBSD: create dumps of the file system of the original guest OS and restore them to a newly created virtual disk, and then swap the disks - the procedure of transferring freeBSD to a new hdd .
The fifth moment: Restore the virtual guest system in Proxmox via the console
The procedure for restoring a virtual guest system in Proxmox through a web interface is well known, however, it’s not clear how this happens in the console. Guest systems (KVM talk) are backed up to the file vzdump-qemu-id-date-time.vma.gz. This is an archive of a pre-packaged virtual disk and a guest OS configuration file.
It is logical to first get the file .vma:
gzip -d vzdump-qemu-103-date-time.vma.gz
where 103 is the guest number in Proxmox
Next, you need to locate the file vzdump-qemu-103-date-time.vma. For this, in Proxmox 3.1 there is a special utility vma
vma extract vzdump-qemu-103-date-time.vma /var/103
Note: the command will work without errors, unless you create the directory “103” in the / var directory. As a result, there will be a couple of files in / var / 103 /:
vm-103-disk-1.raw
qemu-server.conf
Note: if we restored the guest system with a vmdk disk, then the recovered disk will be in raw format. You can fix this by converting to the required format:
qemu-img -f raw -O vmdk vm-103-disk-1.raw vm-103-disk-1.vmdk
The moment of the sixth: Proper shutdown of guest Windows on Proxmox (KVM)
"Proper OS Shutdown" for Proxmox (KVM) guest systems means simulating the event of "pressing the system off button on a physical machine." Such shutdown works correctly in unix-systems. This is achieved by a command in QEMU:
qm shutdown 103
However, in guest Windows systems in the background, the command returns an error and the system does not shut down. Disconnection occurs “correctly” only in case of successful login to the system, or “forcibly” (event “disconnecting the power cord”) - by another command (qm stop 103). It is possible to correct this situation by adjusting the local guest Windows OS policy:
Start - Control Panel - Administration - Local Security Policy - Security Settings - Local Policies - Security Settings - Shut Down: Allow the system to shutdown without logging in (“Enable”)
')
Source: https://habr.com/ru/post/215367/
All Articles