Tag Archives: kvm

create LVM volumes for KVM servers

You need describe your LVM volume group in XML format:

vgs
vi /etc/libvirt/storage/vg_server1.xml

vg1
/dev/vg_server1

virsh pool-define /etc/libvirt/storage/vg_server1.xml
virsh pool-start vg1
virsh pool-autostart vg1
virsh pool-info vg1

now use virt-instal:

virt-install -d --hvm --vnc --name=server1 --ram 5000 --disk pool=vg1,size=100,bus=virtio,cache=none --network network=default,model=virtio \
--location=http://mirror.duomenucentras.lt/centos/7/os/x86_64/ \
--os-type=linux

shadow page tables

Virtualized guests running under Linux like to think that they are doing their own memory management. The truth of the matter, though, is that the host system cannot allow guests to directly modify the page tables used by the hardware; allowing that sort of access would compromise the security of the host. So, somehow, the host must be involved in the guest’s memory management. One common technique is through the use of shadow page tables. Guest systems maintain their own page tables, but they are not the tables used by the memory management unit. Instead, whenever the guest makes a change to its tables, the host system intercepts the operation, checks it for validity, then mirrors the change in the real page tables, which “shadow” those maintained by the guest.

One problem with this technique, as implemented in Linux currently, is that there is no easy way for the host to feed page table changes back to the guest. In particular, if the host system decides that it wants to push a given page out to swap, it can’t tell the guest that the page is no longer resident. So virtualization mechanisms like KVM avoid the problem altogether by pinning pages in memory when they are mapped in shadow page tables. That solves the problem, but it makes it impossible to swap processes running KVM-based virtual machines out of main memory.

qemu/kvm memory usage

The qemu/kvm process runs mostly like a normal Linux program. It allocates its memory with normal malloc() or mmap() calls. If a guest is going to have 1GB of physical memory, qemu/kvm will effectively do a malloc(1<<30), allocating 1GB of host virtual space. However, just like a normal program doing a malloc(), there is no actual physical memory allocated at the time of the malloc(). It will not be actually allocated until the first time it is touched.

Once the guest is running, it sees that malloc()’d memory area as being its physical memory. If the guest’s kernel were to access what it sees as physical address 0x0, it will see the first page of that malloc() done by the qemu/kvm process.

It used to be that every time a KVM guest changed its page tables, the host had to be involved. The host would validate that the entries the guest put in its page tables were valid and that they did not access any memory which was not allowed. It did this with two mechanisms:

shadow page tables

VMX/AMD-V extensions

 

 

KVM enable console

If you did default Centos OS installation, you may be missing console access from virsh virtual machine administration.

If you have started VM from virsh like this:

start –console VM and you see only:

Connected to domain VM_NAME
Escape character is ^]

you should change your VM default configuration like this:

vi /etc/init/ttyS0.conf

# ttyS0 – agetty
#
# This script starts a agetty on ttyS0

stop on runlevel [S016]
start on runlevel [23]
respawn
exec agetty -h -L -w /dev/ttyS0 115200 vt102

and finish initctl start ttyS0

you also can change a bit you grub.conf file a bit:

grubby –update-kernel=ALL –args=’console=ttyS0,115200n8 console=tty0′

if you will add this kernel commands, you will see kernel messages when your system is booting, but its not necessary.

If you can access console as root user you should add this:

echo “ttyS0” >> /etc/securetty