libvirt

virtio-scsi implementation details, documentation & other references..

by

virtio-scsi going to be really a cool implementation on virtio stream. Indeed virtio-blk was arranging that position. How-ever virtio-blk lagged/skipped lots of scsi command ioctls which paved the way to virtio-scsi. Along with virtio-scsi implementation, other downsides of virtio-blk have been lifted, for ex: the number of disk limitation..etc.. To know more about virtio-scsi, I …

Read more

“error: internal error Process exited while reading console log output: Supported machines are:” …

by

Today one of my friend came into this error and I was called up to find a solution.. [root@host]# virsh create /etc/libvirt/qemu/rhel5.4-x86_64-kvm.xml error: Failed to create domain from /etc/libvirt/qemu/rhel5.4-x86_64-kvm.xml error: internal error Process exited while reading console log output: Supported machines are: pc         Standard PC (alias of pc-0.14) pc-0.14    Standard PC (default) fedora-13  Standard PC …

Read more

Configure openvswitch in virtualization environment and use it for simple and complex (ex: vlan) testing in centos/rhel/fedora..etc

by

Open vSwitch (OVS) is a software switch. It consist of user space tools provided by openvswitch rpm and kernel modules provided by kmod-openvswitch rpm. Unlike the bridge available in old versions of distros ( fedora, rhel..etc ) it provides many advanced configuration options like tagged vlan. Full details available at http://www.openvswitch.org/

Open vSwitch is a network switch; at its lowest level, it is concerned with routing packets between interfaces. It is aimed at virtualization users, so, naturally, it is used in the creation of virtual networks. A switch can be set up with a number of virtual network interfaces, most of which are used by virtual machines to communicate with each other and the wider world. These virtual networks can be connected across hosts and across physical networks. One of the key features of Open vSwitch appears to be the ability to easily migrate virtual machines between physical hosts and have their network configuration (addresses, firewall rules, open connections, etc.) seamlessly follow.

Below Process will outline the steps required in CentOS/RHEL..etc

STARTING THE SERVICE

modprobe -r bridge (OVS kernel modules conflict with the “bridge” module)

modprobe openvswitch_mod

modprobe brcompat_mod (OVS bridge compatibility support module. Without this lbvirt cannot use OVS)

Once kernel module part is loaded, lets try to start the subjected service as shown below:

/etc/init.d/openvswitch start

/etc/openvswitch/conf.db does not exist … (warning).
Creating empty database /etc/openvswitch/conf.db           [  OK  ]
Starting ovsdb-server                                      [  OK  ]
Configuring Open vSwitch system IDs                        [  OK  ]
Starting ovs-vswitchd                                      [  OK  ]

So, ovs-vswitchd service is started successfully..

Below command needs ‘brcompat_mod’ and will enable libvirt to use brctl to manage OVS.

ovs-brcompatd –pidfile –detach

Below are the steps which I followed to configure vlan ..

HOW TO CREATE TAGGED VLANS

On the HOST

ovs-vsctl add-br br0

ovs-vsctl add-port br0 vlan10 tag=10 — set interface vlan10 type=internal [creating a taged vlan 10]

ifconfig vlan10 192.168.10.254 netmask 255.255.255.0

ovs-vsctl add-port br0 vlan20 tag=20 — set interface vlan20 type=internal [creating a tagged vlan 20]

ifconfig vlan20 192.168.20.254 netmask 255.255.255.0

ovs-vsctl show

Now, lets list the bridge configuration in the system via ‘brctl’ command..

brctl show

If something goes wrong  (easiest way ) stop openvswitch service, delete /etc/openvswitch/conf.db and start the service again. Do the configuration again.

To test: Execute below steps in VM1

vconfig add eth0 10 [add vlan interface]

ifconfig eth0.10 192.168.10.100 netmask 255.255.255.0 broadcast 192.168.10.255 up [assign IP]

vconfig add eth0 20

ifconfig eth0.20 192.168.20.100 netmask 255.255.255.0 broadcast 192.168.20.255 up

VM2

vconfig add eth0 10 [add vlan interface]

ifconfig eth0.10 192.168.10.101 netmask 255.255.255.0 broadcast 192.168.10.255 up [assign IP]

vconfig add eth0 20

ifconfig eth0.20 192.168.20.101 netmask 255.255.255.0 broadcast 192.168.20.255 up

Now try pinging  VM1 to VM2

***************************************************************************************************************
Below Process will outline Fedora 17, 18, 19 Versions:

Unlike centos/rhel , the openvswitch support is added in libvirt. So, you dont need ‘brcompat_mod’ mentioned in first/above section to use it with libvirt.

Install these packages

[root@Xman 3.9.9-301.fc19.x86_64]# rpm -qa |grep openvswitch
openvswitch-controller-1.10.0-1.fc19.x86_64
openvswitch-1.10.0-1.fc19.x86_64
openvswitch-test-1.10.0-1.fc19.noarch
python-openvswitch-1.10.0-1.fc19.noarch
[root@Xman 3.9.9-301.fc19.x86_64]#

Load openvswitch module and enable the service.

[root@Xman 3.9.9-301.fc19.x86_64]# modprobe openvswitch
[root@Xman 3.9.9-301.fc19.x86_64]# lsmod |grep openvswitch
openvswitch 43393 0

[root@Xman 3.9.9-301.fc19.x86_64]# systemctl enable openvswitch
ln -s ‘/usr/lib/systemd/system/openvswitch.service’ ‘/etc/systemd/system/multi-user.target.wants/openvswitch.service’

[root@Xman 3.9.9-301.fc19.x86_64]# systemctl start openvswitch
[root@Xman 3.9.9-301.fc19.x86_64]# systemctl status openvswitch
openvswitch.service – Open vSwitch
Loaded: loaded (/usr/lib/systemd/system/openvswitch.service; enabled)
Active: active (exited) since Fri 2013-08-02 08:26:25 EDT; 5s ago
Process: 31565 ExecStart=/usr/share/openvswitch/scripts/openvswitch.init start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/openvswitch.service
├─31590 ovsdb-server: monitoring pid 31591 (healthy)
├─31591 ovsdb-server /etc/openvswitch/conf.db -vconsole:emer -vsyslog:err -vfile:info –remote=punix:/var/run/openvswitch/db.sock –private-key=db:Open_vSwitch,SSL,private_key …
├─31599 ovs-vswitchd: monitoring pid 31600 (healthy)
├─31600 ovs-vswitchd unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info –mlockall –no-chdir –log-file=/var/log/openvswitch/ovs-vswitchd.log –pidfile=…
└─31601 ovs-vswitchd: worker process for pid 31600

Aug 02 08:26:25 Xman openvswitch.init[31565]: /etc/openvswitch/conf.db does not exist … (warning).
Aug 02 08:26:25 Xman openvswitch.init[31565]: Creating empty database /etc/openvswitch/conf.db [ OK ]
Aug 02 08:26:25 Xman openvswitch.init[31565]: Starting ovsdb-server [ OK ]
Aug 02 08:26:25 Xman ovs-vsctl[31592]: 00001|vsctl|INFO|Called as ovs-vsctl –no-wait — init — set Open_vSwitch . db-version=6.12.0
Aug 02 08:26:25 Xman ovs-vsctl[31597]: 00001|vsctl|INFO|Called as ovs-vsctl –no-wait set Open_vSwitch . ovs-version=1.10.0 “external-ids:system-id…unknown\””
Aug 02 08:26:25 Xman openvswitch.init[31565]: Configuring Open vSwitch system IDs [ OK ]
Aug 02 08:26:25 Xman openvswitch.init[31565]: Starting ovs-vswitchd [ OK ]
Aug 02 08:26:25 Xman openvswitch.init[31565]: Enabling remote OVSDB managers [ OK ]
Aug 02 08:26:25 Xman openvswitch.init[31565]: Enabling gre with iptables [ OK ]
Aug 02 08:26:25 Xman systemd[1]: Started Open vSwitch.
[root@Xman 3.9.9-301.fc19.x86_64]#

[root@Xman 3.9.9-301.fc19.x86_64]# ps aux |grep openv
root 31591 0.0 0.0 43592 1996 ? S< 08:26 0:00 ovsdb-server /etc/openvswitch/conf.db -vconsole:emer -vsyslog:err -vfile:info --remote=punix:/var/run/openvswitch/db.sock --private-key=db:Open_vSwitch,SSL,private_key --certificate=db:Open_vSwitch,SSL,certificate --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert --no-chdir --log-file=/var/log/openvswitch/ovsdb-server.log --pidfile=/var/run/openvswitch/ovsdb-server.pid --detach --monitor root 31600 0.0 0.1 43880 9028 ? S mtu 1500
inet 192.168.10.254 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::e062:e7ff:fe73:5a0 prefixlen 64 scopeid 0x20 ether e2:62:e7:73:05:a0 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 468 (468.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

vlan20: flags=67 mtu 1500
inet 192.168.20.254 netmask 255.255.255.0 broadcast 192.168.20.255
inet6 fe80::8b3:e6ff:fe5a:a2e3 prefixlen 64 scopeid 0x20 ether 0a:b3:e6:5a:a2:e3 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 468 (468.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

[root@Xman 3.9.9-301.fc19.x86_64]#

Now, before starting a guest please edit the guest configuration as shown below:


–> It should be filled with the mac–> This should be the ‘bridge’ you configured for ovs
–> This add ovs support from libvirt layer

Once you started the guest please follow the same process mentioned ( configuration of vlan networks in guest) in section 1 ( inside Centos/RHEL..etc)

You should be good to go.

Reference:

http://openvswitch.org/support/

http://lwn.net/Articles/469775/

openvswitch faq..

Getting host/hypervisor system configuration/capabilities using ‘virsh’ commands..

by

There are couple of ‘virsh’ commands which can be used to get some basic information about the hypervisor which are in use/connected..

I will directly show the command output to get that information..

 

[root@humbles-lap ~]#virsh nodeinfo
CPU model: x86_64
CPU(s): 4
CPU frequency: 1599 MHz
CPU socket(s): 1
Core(s) per socket: 2
Thread(s) per core: 2
NUMA cell(s): 1
Memory size: 3909832 kB

[root@humbles-lap ~]#virsh capabilities



205846c1-4bd7-dd11-8400-54424964b92e

x86_64
Nehalem
Intel















tcp















selinux
0


hvm

32
/usr/bin/qemu
pc-0.13
pc
fedora-13
pc-0.12
pc-0.11
pc-0.10
isapc





/usr/bin/qemu-kvm
pc-0.13
pc
fedora-13
pc-0.12
pc-0.11
pc-0.10
isapc








hvm

64
/usr/bin/qemu-system-x86_64
pc-0.13
pc
fedora-13
pc-0.12
pc-0.11
pc-0.10
isapc





/usr/bin/qemu-kvm
pc-0.13
pc
fedora-13
pc-0.12
pc-0.11
pc-0.10
isapc








hvm

32
/usr/bin/qemu-system-arm
integratorcp
syborg
musicpal
mainstone
n800
n810
cheetah
sx1
sx1-v1
tosa
akita
spitz
borzoi
terrier
connex
verdex
lm3s811evb
lm3s6965evb
realview-eb
realview-eb-mpcore
realview-pb-a8
realview-pbx-a9
versatilepb
versatileab




hvm

32
/usr/bin/qemu-system-mips
malta
mipssim
magnum
pica61
mips




hvm

32
/usr/bin/qemu-system-mipsel
malta
mipssim
magnum
pica61
mips




hvm

32
/usr/bin/qemu-system-sparc
SS-5
SS-10
SS-600MP
SS-20
Voyager
LX
SS-4
SPARCClassic
SPARCbook
SS-1000
SS-2000
SS-2




hvm

32
/usr/bin/qemu-system-ppc
g3beige
mpc8544ds
bamboo
bamboo-0.13
bamboo-0.12
ref405ep
taihu
mac99
prep



The above commands can be used get the mentioned information..

 

virsh capabilties got mainly 2 sections.. 1. Host and 2. Guest part as highlighted above.

 

Recently the libvirt API behind this has been improved a lot for fetching above information..

 

Give hugepage memory for guests in KVM virtualization

by

First of all, what are hugepages ? I would love to explain this, but it is already did by someone here, so I am just quoting some bits of it..

Thats it.. Hope this helps..

[root@humbles-lap qemu_upstream]# cat /proc/meminfo |grep -i huge
AnonHugePages: 434176 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB ======; 2M
[root@humbles-lap qemu_upstream]#

[root@humbles-lap qemu_upstream]# sysctl -a |grep -i huge
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.hugetlb_shm_group = 0
vm.hugepages_treat_as_movable = 0
vm.nr_overcommit_hugepages = 0

My guest have ‘512M’ of memory , so I decided to give “256” ( total 256*2M=512) as the number of hugepages

[root@humbles-lap qemu_upstream]# sysctl vm.nr_hugepages=256
vm.nr_hugepages = 256
[root@humbles-lap qemu_upstream]#

[root@humbles-lap qemu_upstream]# sysctl -a |grep -i huge
vm.nr_hugepages = 256
vm.nr_hugepages_mempolicy = 256
vm.hugetlb_shm_group = 0
vm.hugepages_treat_as_movable = 0
vm.nr_overcommit_hugepages = 0
[root@humbles-lap qemu_upstream]#

So, hugepage assignment reflected here:

[root@humbles-lap qemu_upstream]# cat /proc/meminfo |grep -i huge
AnonHugePages: 450560 kB
HugePages_Total: 256
HugePages_Free: 256
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
[root@humbles-lap qemu_upstream]#

Once you assigned hugepages, you need to restart ‘libvirtd” service…

[root@humbles-lap hpages]# service libvirtd restart
Stopping libvirtd daemon: [ OK ]
Starting libvirtd daemon: [ OK ]
[root@humbles-lap hpages]#

Check mount point for ‘existence’ of a directory as shown below:

[root@humbles-lap qemu_upstream]# cd /dev/hpages/
[root@humbles-lap hpages]# ls
libvirt
[root@humbles-lap hpages]# cd libvirt/
[root@humbles-lap libvirt]# ls
qemu
[root@humbles-lap libvirt]# cd qemu/
[root@humbles-lap qemu]# ls
[root@humbles-lap qemu]#
With the current configuration, I have NOT specified to have ‘hugepage’ backed memory for my guest..

[root@humbles-lap qemu_upstream]# cat /etc/libvirt/qemu/rhel5.4-x86_64-kvm.xml |grep -i memory
memory;524288/memory;
currentMemory;524288/currentMemory;
[root@humbles-lap qemu_upstream]#

I edited my guest xml configuration to say, this guest memory is backed with “HUGEPAGES”..

[root@humbles-lap qemu_upstream]# cat /etc/libvirt/qemu/rhel5.4-x86_64-kvm.xml|grep -i memory -A 2
memory;524288/memory;
currentMemory;524288/currentMemory;
;memoryBacking;
hugepages/;
/memoryBacking;
vcpu;2/vcpu;
os;
[root@humbles-lap qemu_upstream]#

Started guest:

[root@humbles-lap qemu_upstream]# virsh create /etc/libvirt/qemu/rhel5.4-x86_64-kvm.xml
Domain rhel5.4-x86_64-kvm created from /etc/libvirt/qemu/rhel5.4-x86_64-kvm.xml

[root@humbles-lap qemu_upstream]# virsh list
Id Name State
———————————-
1 rhel5.4-x86_64-kvm running

[root@humbles-lap qemu_upstream]#

Now, check ‘meminfo’ in HOST system to know whether “HUGEPAGES” are used with GUESTS..

[root@humbles-lap qemu_upstream]# cat /proc/meminfo |grep -i huge
AnonHugePages: 483328 kB
HugePages_Total: 256
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
[root@humbles-lap qemu_upstream]#

virt-install –cpuset=auto

by

INFORMATIONAL NOTE: The option “virt-install –cpuset=auto ( with other switches)” can be used to pin physical cpus for the guest cpus. This option is really useful when “numa” capable host system is in use. So that you dont need to select host cpus to pin for guest cpus. The utility “virt-install” will form the optimal …

Read more

Share host filsystem to guest using virtfs 9p filesystem passthrough

by

Virtfs is a virtualization aware filesystem passthrough..Sharing host files on the guest through generic network file systems like NFS and CIFS suffer from major performance and feature deficiencies as these protocols are not designed or optimized for virtualization. To address the needs of
the virtualization paradigm, a new paravirtualized file system called VirtFS has been intorduced. Virtfs takes features of 9p2000.L protocol.

Using virtfs, you can share filesystem of host to the guest system. It works via para virtual transport mechanism called ‘virtio’. Virtfs has been implemented with ‘zero copy’ mechanism. This is a key advantage of VirtFS compared to using a network file system which would always require at least one (but usually more) data copies.

There are mainly 2 components in this implementation.

1)  virtio-9p-pci device ::

This will be used to transport protocol messages and data between the host
and the guest.

2) ‘fsdev’ device :

This is used to define the export file system characteristics like file
system type, security model .

For more about the implementation details,please  look at reference section..

Below is demo of this feature in “qemu” , “kvm”, “libvirt” environment.

Host system details : Fedora 15 :

[root@humbles-lap Desktop]$ cat /etc/redhat-release
Fedora release 15 (Lovelock)
[root@humbles-lap Desktop]$ uname -r
2.6.43.5-2.fc15.x86_64

Guest System details:  Fedora 16:

[root@localhost mnt]# cat /etc/redhat-release
Fedora release 16 (Verne)
[root@localhost mnt]# uname -r
3.1.0-7.fc16.x86_64
[root@localhost mnt]#

First of all, check support for above mentioned components ( virtio-9p-pci & fsdev) in host system qemu-kvm binary..

Host:

[root@humbles-lap Desktop]$ qemu-kvm –help|grep virtfs
-virtfs local,path=path,mount_tag=tag,security_model=[mapped|passthrough|none]

[root@humbles-lap Desktop]$ qemu-kvm device ?

name “virtio-9p-pci”, bus PCI

[root@humbles-lap Desktop]# lsmod |grep virt
9pnet_virtio           13416  0
9pnet                  73543  1 9pnet_virtio
virtio_net             23133  0
[root@humbles-lap Desktop]#

Guest Kernel has to support 9p:

[root@humbles-lap bin]#  grep 9P /boot/config-$(uname -r)
CONFIG_NET_9P=m
CONFIG_NET_9P_VIRTIO=m
CONFIG_NET_9P_RDMA=m
# CONFIG_NET_9P_DEBUG is not set
CONFIG_9P_FS=m
CONFIG_9P_FSCACHE=y
CONFIG_9P_FS_POSIX_ACL=y

IN HOST SYSTEM:
—————————————————-

The below string has to be specified with ‘qemu-kvm’ process to export a ‘virtfs’ filesystem for guest.

-virtfs local,path=[path to share],security_model=[mapped|passthrough|
none],mount_tag=[mount tag]

Where : Path = Sharing filesystem path
security_model: This can be either “mapped” or “passthrough”..
mount_tag: This is the idenitifier which can be used in guest when moutning.

The easiest way for defining this is, placing it in the guest configuration file..


< source dir='/misc/shared'/>

< address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>

After placing this in “guest configuration” file:

Start the guest :

ex: virsh create Fedora-16.xml

Check for “qemu-kvm” process to know whether “virtfs” options has been picked properly..

[root@humbles-lap Desktop]# ps aux |grep qemu-kvm
qemu      7473  0.8  8.0 1356940 314552 ?      Sl   17:00   0:27 /usr/bin/qemu-kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name Fedora-16 -uuid 75d12600-d3c5-9bb1-7d0a-5ed0e550f5ee -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Fedora-16.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/Fedora-16.img,if=none,id=drive-virtio-disk0,boot=on,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -fsdev local,security_model=passthrough,id=fsdev-fs0,path=/misc/shared -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=test_mount,bus=pci.0,addr=0x6 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:80:db:8d,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

IN GUEST SYSTEM:

You have to mount the shared filesystem using “9p” . Use below command for the same:

#mount -t 9p -o trans=virtio test_mount /mnt

Where,

Filesyste type: 9p
Transport mechanism: virtio
Mount tag: This is the tag ‘test_mount’ which used when sharing from host system.
Mount Point: /mnt

Check for filesystem :

HOST

[root@humbles-lap shared]# pwd
/misc/shared
[root@humbles-lap shared]# echo “Hi Guest” –> virtfs_file
[root@humbles-lap shared]#

GUEST:

[root@localhost mnt]# mount |grep test_mount
test_mount on /mnt type 9p (rw,relatime,sync,dirsync,trans=virtio)
[root@localhost mnt]# pwd
/mnt
[root@localhost mnt]# cat virtfs_file
Hi Guest

Reference: www.kernel.org/doc/ols/2010/ols2010-pages-109-120.pdf

Nested virtualization with KVM/VMX OR Guest inside guest in kvm in fedora linux

by

I would like to explain “nested Virtualization” in my own terms . How-ever it is already documented , so I am just quoting some bits from the same.

On Intel processors, KVM uses Intel’s VMX (Virtual-Machine eXtensions)
to easily and efficiently run guest operating systems. Normally, these guests
*cannot* themselves be hypervisors running their own guests, because in VMX,
guests cannot use VMX instructions.

The “Nested VMX” feature adds this missing capability – of running guest
hypervisors (which use VMX) with their own nested guests. It does so by
allowing a guest to use VMX instructions, and correctly and efficiently
emulating them using the single level of VMX available in the hardware.

Terminology
———–

Single-level virtualization has two levels – the host (KVM) and the guests.
In nested virtualization, we have three levels: The host (KVM), which we call
L0, the guest hypervisor, which we call L1, and its nested guest, which we
call L2.

Running nested VMX
——————

The nested VMX feature is disabled by default. It can be enabled by giving
the “nested=1” option to the kvm-intel module.

No modifications are required to user space (qemu). However, qemu’s default
emulated CPU type (qemu64) does not list the “VMX” CPU feature, so it must be
explicitly enabled, by giving qemu one of the following options:

     -cpu host              (emulated CPU has all features of the real CPU)

     -cpu qemu64,+vmx       (add just the vmx feature to a named CPU type)

Instead of explaining a lot of theory about it, I will demo its use:

[cc]

//Checking whether “kvm_intel” will support this parameter?

[root@humbles-lap Humble]# modinfo kvm_intel


filename:       /lib/modules/2.6.43.5-2.fc15.x86_64/kernel/arch/x86/kvm/kvm-intel.ko


license:        GPL


author:         Qumranet


depends:        kvm


intree:         Y


vermagic:       2.6.43.5-2.fc15.x86_64 SMP mod_unload 


parm:           vpid:bool


parm:           flexpriority:bool


parm:           ept:bool


parm:           unrestricted_guest:bool


parm:           emulate_invalid_guest_state:bool


parm:           vmm_exclusive:bool


parm:           yield_on_hlt:bool


parm:           fasteoi:bool




parm:           nested:bool


parm:           ple_gap:int


parm:           ple_window:int


// This feature is "disabled" by default..


[root@humbles-lap Humble]# cat /sys/module/kvm_intel/parameters/nested 


N


// Remove the module


[root@humbles-lap Humble]# rmmod kvm_intel


[root@humbles-lap Humble]# lsmod |grep kvm_intel


[root@humbles-lap Humble]#


// Make the 'nested' boolean "ON" and reload:


[root@humbles-lap Humble]# insmod /lib/modules/2.6.43.5-2.fc15.x86_64/kernel/arch/x86/kvm/kvm-intel.ko nested=Y


[root@humbles-lap Humble]# lsmod |grep intel


kvm_intel             132406  0 


snd_hda_intel          33276  3 


snd_hda_codec         115767  3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel


snd_pcm                97170  4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec


snd                    78908  14 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer


kvm                   407039  1 kvm_intel


snd_page_alloc         18101  2 snd_hda_intel,snd_pcm


intel_ips              18304  0


[root@humbles-lap Humble]# cat /sys/module/kvm_intel/parameters/nested 


Y


[root@humbles-lap Humble]#


 


[/cc]


Now, if you are configuring a virtual machine or guest as another hypervisor, you should have virtualization support in its processor. For that you have to export your CPU as "vmx" enabled one. You can achieve this by editing guest configuration file and then starting the vm.


Below is my guest configuration file wrt to the CPU session . The important field here is ""


 


[cc]


[root@humbles-lap Humble]# cat /etc/libvirt/qemu/rhel5.4-x86_64-kvm.xml |grep -w cpu -A 13


  <cpu match='exact'>


    <model>Westmere</model>


    <vendor>Intel</vendor>


    


    <feature policy='require' name='est'/>


    <feature policy='require' name='monitor'/>


    <feature policy='require' name='ss'/>


    <feature policy='require' name='vme'/>


    


    <feature policy='require' name='ht'/>


    <feature policy='require' name='ds'/>


    


    <feature policy='require' name='tm'/>


    


--


  </cpu>


 


[/cc]


//Then I started this VM via "virsh" command..


[root@humbles-lap Humble]# virsh create /etc/libvirt/qemu/rhel5.4-x86_64-kvm.xml

Domain rhel5.4-x86_64-kvm created from /etc/libvirt/qemu/rhel5.4-x86_64-kvm.xml


[root@humbles-lap Humble]#


// Check the 'qemu-kvm' process for "+vmx" flag


[root@humbles-lap Humble]# ps aux |grep -i qemu-kvm |grep vmx

qemu      8389 50.6  1.3 872040 53908 ?        Sl   23:26   0:06 /usr/bin/qemu-kvm -S -M pc-0.13 -cpu core2duo,+lahf_lm,+rdtscp,+aes,+popcnt,+sse4.2,+sse4.1,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+pbe,+tm,+ht,+ss,+acpi,+ds -enable-kvm -m 512 -mem-prealloc -mem-path /dev/hugepages/libvirt/qemu -smp 2,sockets=2,cores=1,threads=1 -name rhel5.4-x86_64-kvm -uuid b2d13137-ff17-d505-0a6b-fb79c867584a -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel5.4-x86_64-kvm.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -boot c -drive file=/misc/guest-images/rhel5.4-x86_64-kvm.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=54:52:00:6c:6e:70,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -vnc 127.0.0.1:0 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4

[root@humbles-lap Humble]#


Once "VM" started, try to login to that VM and see whether its processor support virtualization..


 


[cc]


[Humble@humbles-lap ~]$ ssh root@192.168.122.125

root@192.168.122.125's password:

Last login: Thu Jun 14 23:28:20 2012

[root@dhcp208-238 ~]# cat /proc/cpuinfo |grep -i vmx

flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc pni vmx ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm

flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc pni vmx ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm


[/cc]


Now you have to believe me that this VM can act as a host/hypervisor system for another VM.


 


As you do in a host system, try to create VM inside this guest and play.


 


Reference# nested-vmx.txt in kernel source

Where are guest configuration files located in KVM

by

I know it is a very simple question, but at the same time, if you don’t know the answer, it is not simple to you. That made me blog this information here.

In Fedora/RHEL, the guest configuration files are located under “/etc/libvirt/qemu” directory in the ‘name’ of the guest created in KVM.

[root@humbles-lap qemu]# pwd /etc/libvirt/qemu [root@humbles-lap qemu]#  ls networks rhel5.4-x86_64-kvm_backup.xml rhel5.4-x86_64-kvm.xml RHEL-5.xml rhevh.xml Window-2008.xml  [root@humbles-lap qemu]# cat rhel5.4-x86_64-kvm.xml |head -n 2 <domain type=’kvm’> <name>rhel5.4-x86_64-kvm</name> [root@humbles-lap qemu]#

Above output means, I have guests created in my system with names like rhevh, window-2008, rhel5.. etc

© 2026 GeneratePress