Cluster 24. Resizing LVM image of the Virtual Machine.

On guest:
fdisk -l /dev/vda

Resize LV to be 20GB:
lvresize -L 21474836480b /dev/agrp-c01n02_vg0/vm-test
  Size of logical volume agrp-c01n02_vg0/vm-test changed from 15.00 GiB (3840 extents) to 20.00 GiB (5120 extents).
  Logical volume agrp-c01n02_vg0/vm-test successfully resized.

Find domain ID:
virsh list
 Id    Name                           State
----------------------------------------------------
 1     vm-test                 running

Resize vda of the guest:

virsh blockresize  --path /dev/agrp-c01n02_vg0/vm-test --size 21474836480b  1

Block device '/dev/agrp-c01n02_vg0/vm-test' is resized

On guest - check that vda is resized to the needed size:

lsblk -a | grep ^vda 

vda                         252:0    0   20G  0 disk 

View last partition index (here it's 2 because of vda2) on the guest:

lsblk -a | grep vda

vda                         252:0    0   20G  0 disk 

├─vda1                      252:1    0  500M  0 part /boot

└─vda2                      252:2    0 14.5G  0 part 

Find end of the last partition (text in bold is end - 31208) on the guest:

fdisk -l

Disk /dev/vda: 21.5 GB, 21474836480 bytes

16 heads, 63 sectors/track, 41610 cylinders

Units = cylinders of 1008 * 512 = 516096 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x000a4595

   Device Boot      Start         End      Blocks   Id  System

/dev/vda1   *           3        1018      512000   83  Linux

Partition 1 does not end on cylinder boundary.

/dev/vda2            1018       31208    15215616   8e  Linux LVM

Create new partition vda3 on the guest:

fdisk /dev/vda 

input n letter # for creating new partition

input p # for primary partition 

input 3 # for new partition index

input 31208 # for "First cylinder (1-41610, default 1):"

enter # to accept "Last cylinder, +cylinders or +size{K,M,G} (31208-41610, default 41610):"

input w # to save 

View current partition table on the guest:

partx -l /dev/vda

Re-read partition table:

partx -a /dev/vda # this will give "BLKPG: Device or resource busy" for already added partition

Check that we have device nodes for /dev/sdb itself and the partitions on it:

ls /dev/vda*

/dev/vda  /dev/vda1  /dev/vda2 /dev/vda3

Create PV and verify on the guest:

pvcreate /dev/vda3

  Physical volume "/dev/vda3" successfully created

pvs

 PV         VG       Fmt  Attr PSize  PFree

  /dev/vda2  VolGroup lvm2 a--  14.51g    0 

  /dev/vda3           lvm2 ---   5.00g 5.00g

Extend VG with new PV nad verify:

vgextend VolGroup /dev/vda3

  Volume group "VolGroup" successfully extended

pvs

  PV         VG       Fmt  Attr PSize  PFree

  /dev/vda2  VolGroup lvm2 a--  14.51g    0 

  /dev/vda3  VolGroup lvm2 a--   5.00g 5.00g

Extend LV size to the all available free space on the guest:

lvextend -l +100%FREE /dev/VolGroup/lv_root 

  Size of logical volume VolGroup/lv_root changed from 13.01 GiB (3330 extents) to 18.00 GiB (4609 extents).

  Logical volume lv_root successfully resized

Verify on the guest:

lvs

  LV      VG       Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert

  lv_root VolGroup -wi-ao---- 18.00g                                                    

  lv_swap VolGroup -wi-ao----  1.50g 

Resize file system on the guest:
For ext type filesystem:

resize2fs /dev/VolGroup/lv_root

resize2fs 1.41.12 (17-May-2010)

Filesystem at /dev/VolGroup/lv_root is mounted on /; on-line resizing required

old desc_blocks = 1, new_desc_blocks = 2

Performing an on-line resize of /dev/VolGroup/lv_root to 4719616 (4k) blocks.

The filesystem on /dev/VolGroup/lv_root is now 4719616 blocks long.
For xfs filesystem:
xfs_growfs /dev/VolGroup/lv_root

Verify on guest:

df -h

Filesystem                                   Size  Used Avail Use% Mounted on

/dev/mapper/VolGroup-lv_root      18G  9.3G  7.5G  56% /

tmpfs                                           939M     0  939M   0% /dev/shm

/dev/vda1                                    477M   48M  405M  11% /boot

Cluster 23. Converting qcow2 to LVM storage.

If you want target machine to remain working while we changing it's storage (it's only recommended for VM's which are NOT having their data updated continuously - like NTP server, if your VM data is updated continuously - you MUST stop the VM and then convert VM's storage and then start VM on the new storage, otherwise you will lose data):

virsh # entry to the virsh console

list # list all running VMs

 Id    Name                           State

----------------------------------------------------

 4     rntp                           running

 5     rftp                           running

 18    agisrv                         running

 19    squid                          running

 23    cc_replica                     running

 27    nagios                         running

 29    rvoip                          running

domblklist rntp # list block-devices for given VM name

Target     Source

------------------------------------------------

vda        /var/lib/libvirt/images/rntp.qcow2

hdc        -

domblkinfo rntp vda # view size for an image (we need "Capacity")

Capacity:       16106127360

Allocation:     1576611840

Physical:       1576611840

or:

qemu-img info /var/lib/libvirt/images/rntp.qcow2 # we need "virtual size"

image: /var/lib/libvirt/images/rntp.qcow2

file format: qcow2

virtual size: 15G (16106127360 bytes)

disk size: 1.5G

cluster_size: 65536

Create LV with needed size:
lvcreate -L 16106127360b -n vm01-rntp_0 agrp-c01n01_vg0

virsh dumpxml rntp > /root/rntp.xml
Calculate md5 checksum (md5 sums only verifies/works with the file content rather than the file name):
md5sum /var/lib/libvirt/images/rntp.qcow2 > rntp.md5
md5sum /root/rntp.xml >> rntp.md5

Copy qcow2 image to the destination node:
scp root@10.10.10.2:/var/lib/libvirt/images/rntp.qcow2  /var/lib/libvirt/images/
scp root@10.10.10.2:/root/rntp.xml  /etc/libvirt/qemu/
scp root@10.10.10.2:/root/rntp.md5  /root/

Verify md5 checksum (before that change location in the rntp.md5 file):
md5sum -c rntp.md5
/root/rntp.qcow2: OK
/root/rntp.xml: OK

Copying an image to a physical device:
The diskimage will need to be in raw format.
qemu-img convert -O raw rntp.qcow2 rntp.raw
Then you just dd it onto the hard drive.
dd if=rntp.raw of=/dev/agrp-c01n01_vg0/vm01-rntp_0
Or, let qemu-img directly write onto the drive in one command:
qemu-img convert -O raw rntp.qcow2 /dev/agrp-c01n01_vg0/vm01-rntp_0

Adapting the configuration file

Old situation:

     <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/images/rntp.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>

New situation:

    <disk type='file' device='disk'>

      <driver name='qemu' type='raw' cache='none' io='native'/>

      <source dev='/dev/agrp-c01n01_vg0/vm01-rntp_0'/>

      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>

After this step, you should be able to start your virtual machine again. If the machine boots successfully, you can remove the old disk file (I suggest to stop machine on the previous location and then test new VM for a week and only after that delete old image file).

If you move virtual machine from one machine to the other (both are not members of the same cluster) - use virsh define vm01-rntp.xml to create machine on the new location and then stop VM on the old location (virsh shutdown vm01-rntp) and disable VM autostart (rm /etc/libvirt/qemu/autostart/rntp.xml)

PS if you want to move virtual machine from CentOS 6 (libvirt 0.10.2) to CentOS 7 (libvirt 3.2.0) - xml file will not fit. Instead of using xml file - take any xml-dump file of virtual machine existing on CentOS 7 and replace needed xml attributes (<uuid> / <name> / <memory unit= / <currentMemory unit= / <vcpu placement= / <os> / <disk /  <interface ). 

How many vCPU per pCPU.

virsh # nodeinfo

CPU model:           x86_64

CPU(s):              12

CPU frequency:       1200 MHz

CPU socket(s):       1

Core(s) per socket:  6

Thread(s) per core:  2

NUMA cell(s):        1

Memory size:         16741656 KiB

• Socket - physical socket which the processor package sits in, on the motherboard
• Processor package is what you get when you buy a single hardware processor.
• Core - is a hardware term that describes the number of independent central processing units in a single computing component (Cores count = Sockets*Cores per socket)). vCPU count equals to the cores count
• Thread - A Thread, or thread of execution, is a software term for the basic ordered sequence of instructions that can be passed through or processed by a single CPU core.
  
• NUMA - Non-uniform memory access is a computer memory design used in multiprocessing, where the memory access time depends on the memory location relative to the processor. Under NUMA, a processor can access its own local memory faster than non-local memory (memory local to another processor or memory shared between processors). The benefits of NUMA are limited to particular workloads, notably on servers where the data is often associated strongly with certain tasks or users
• ht Flag - Intel® Hyper-Threading Technology (Intel® HT Technology) delivers two processing threads per physical core - instructions are processed through two threads simultaneously,. Highly threaded applications can get more work done in parallel, completing tasks sooner. (also we see that Thread(s) per core equals to 2 - meaning that HT is enabled). Hyper-Threading doesn't double the performance, max performance increases are up to max 30%
• CPU - equals Cores*Threads per core (in example case 6*2=12). vCPU count equals to CPU count

KVM uses Virtual CPU (vCPU) notion while assigning Processor CPU (pCPU) to the newly created virtual machine. vCPU is neither an OS thread nor a process.
Intel VT-x proposed a new mode methodology with two modes: VMX root mode and VMX non-root mode (VMX - Virtual Machine Extensions, this is set of CPU instructions added by Intel to their processors to support virtualization), for running host VMM (Virtual Machine Monitor=Hypervisor) and guest respectively.
Intel VT-x also contains a new structure: VMCS (Virtual Machine Control Structure - supports nested virtualization - a VM inside the VM ), which saves all information both host and guest need. VMCS is one per guest.

The guest code is running directly on CPU in VMX non-root mode. No software emulation layer for vCPU is needed. That’s why KVM has better performance, and there is no specific thread for guest.

A vCPU equates to 1 physical core, but (by default - rhel.link) when your VM attempts to process something, it can potentially run on any of the cores that happen to be available at that moment. The scheduler handles this, and the VM is not aware of it. You can assign multiple vCPUs to a VM which allows it to run concurrently across several cores. Cores are shared between all VMs as needed, so you could have a 4-core system, and 10 VMs running on it with 2 vCPUs assigned to each. VMs share all the cores in your system quite efficiently as determined by the scheduler. This is one of the main benefits of virtualization - making the most use of under-subscribed resources to power multiple OS instances.

The exact amount of CPU overcommitment a KVM host can accommodate will depend on the VMs and the applications they are running. A general guide for performance of {allocated vCPUs}:{total vCPU} from the Best Practices recommendations is:

• 1:1 to 3:1 is no problem (the general recommendation is only using 1 vCPU per VM until you determine there is a need to add more than that. Over allocations of vCPU can cause lags in the VMs because too many are trying to use the same physical processors simultaneously. )
• 3:1 to 5:1 may begin to cause performance degradation
• 6:1 or greater is often going to cause a problem

So that if you will use overcommitment rate 3:1, then 12 vCPU (as in example) can be assigned as 36 vCPUs