Xen Virtualization Frequently Asked Questions
what is xvda in .cfg files of DomU ?
xvda is the first Xen Virtual Disk presented to Dom-U.
While you may name this whatever you'd like (as far as i know) it is typically one of hda, sda, xvda; if I recall, there are some performance gains by using xvda in regards to the Dom-U knowing it is para-virtualized and acting accordingly.
Showing posts with label xen. Show all posts
Showing posts with label xen. Show all posts
Wednesday, December 22, 2010
Sunday, October 24, 2010
Xen Custom Network
Xen Custom Network
Steps to be followed to remove Default Bridging of First Network Interfae eth0(peth0)---xenbr0 on xen
1) Create a new custom network script
vi /etc/xen/scripts/multi-network-bridge
#!/bin/sh
#/etc/xen/scripts/network-bridge $@ vifnum=0 netdev=eth0 bridge=xenbr0 #####default eth0 was disabled
/etc/xen/scripts/network-bridge $@ vifnum=1 netdev=eth1 bridge=xenbr1 #### new eth1(peth1)--xenbr1
/etc/xen/scripts/network-bridge $@ vifnum=2 netdev=eth2 bridge=xenbr2 #### new eth2(peth2)--xenbr2
#.
#.
#.
#/etc/xen/scripts/network-bridge $@ vifnum=n netdev=ethn bridge=xenbrn #### new ethn(pethn)--xenbrn
n --- replace it with you ethernet interface number
2) chmod 755 multi-network-bridge
3) vi /etc/xen/xend-config.sxp
search for network-bridge and you can find some thing of like below
(network-script network-bridge) ### comment it and replace with the below
(network-script multi-network-bridge) ### new one it your custom file
save it and reboot the server, once the server comes up check the output of below commands , there should be no peth0(that is you real eth0 interface used in xen environment) , xenbr0.
[root@storage ~]# brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.000000000000 yes
xenbr1 8000.feffffffffff no peth1
vif0.1
Steps to be followed to remove Default Bridging of First Network Interfae eth0(peth0)---xenbr0 on xen
1) Create a new custom network script
vi /etc/xen/scripts/multi-network-bridge
#!/bin/sh
#/etc/xen/scripts/network-bridge $@ vifnum=0 netdev=eth0 bridge=xenbr0 #####default eth0 was disabled
/etc/xen/scripts/network-bridge $@ vifnum=1 netdev=eth1 bridge=xenbr1 #### new eth1(peth1)--xenbr1
/etc/xen/scripts/network-bridge $@ vifnum=2 netdev=eth2 bridge=xenbr2 #### new eth2(peth2)--xenbr2
#.
#.
#.
#/etc/xen/scripts/network-bridge $@ vifnum=n netdev=ethn bridge=xenbrn #### new ethn(pethn)--xenbrn
n --- replace it with you ethernet interface number
2) chmod 755 multi-network-bridge
3) vi /etc/xen/xend-config.sxp
search for network-bridge and you can find some thing of like below
(network-script network-bridge) ### comment it and replace with the below
(network-script multi-network-bridge) ### new one it your custom file
save it and reboot the server, once the server comes up check the output of below commands , there should be no peth0(that is you real eth0 interface used in xen environment) , xenbr0.
[root@storage ~]# brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.000000000000 yes
xenbr1 8000.feffffffffff no peth1
vif0.1
Xen disk images vs LVM
Xen disk images vs LVM
In setting up a Xen virtualized web server with about 15 GB of static files I questioned the wisdom of using a disk image as apposed to LVM. I read a bunch of forums about which is better and it seems the disk images are easier to manage because you can just copy to make backups etc.. LVM you just can't move it and pop it up whereever you want but you have more flexibility in resizeing and backing them up within the host OS. However what I didn't find on the forums is performance tests. People theororized about the speed difference but it seems nobodies sat down and done some tests. It's my goal that after summer vacation to put together a performance whitepaper comparing all the virtual machine solutions. For now I'll just put up xen disk images against LVM.
So I created a 10 GB empty disk image using dd and I created a 10 GB LVM Logical volume and assigned both of them to the domU.
name = "rheltest"
memory = "512"
disk = [ 'tap:aio:/srv/xen/rhelos5.img,xvda,w', 'tap:aio:/srv/xen/rheltest.img,xvdb,w', 'phy:/dev/vgsys/lvtest,xvdc,w' ]
vif = [ 'bridge=xenbr0', ]
bootloader="/usr/bin/pygrub"
vcpus=1
on_reboot = 'restart'
on_crash = 'restart'
Test 1 - disk image
The disk image /dev/xvdb1 was mounted as /media/test1. The images itself was stored on a 500 GB SATA drive.
/dev/xvdb1 10317828 154236 9639476 2% /media/test1
[root@localhost ~]# bonnie++ -s 2048 -d /media/test1 -u root
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
localhost.locald 2G 6065 15 70595 37 20649 2 26878 53 57270 0 135.8 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 17008 99 +++++ +++ 26079 90 16002 94 +++++ +++ 29094 99
localhost.localdomain,2G,6065,15,70595,37,20649,2,26878,53,57270,0,135.8,0,16,17008,99,+++++,+++,26079,90,16002,94,+++++,+++,29094,99
Test 2 - LVM
The LVM Logical Volume was created on the same 500 GB SATA drive and mounted in the domU as /media/test2
/dev/xvdc 10321208 154236 9642684 2% /media/test2
[root@localhost ~]# bonnie++ -s 2048 -d /media/test2 -u root
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
localhost.locald 2G 34825 92 50898 26 24833 4 35920 69 77594 1 137.9 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 15556 92 +++++ +++ 26198 96 16281 98 +++++ +++ 28508 100
localhost.localdomain,2G,34825,92,50898,26,24833,4,35920,69,77594,1,137.9,0,16,15556,92,+++++,+++,26198,96,16281,98,+++++,+++,28508,100
INIT: version 2.86 reloading
LVM soundly trounced the disk image in Sequential Output - Per Chr by about 600% and bettered it by about 20-30% in the other tests. The on interesting one though was Sequential Output - Block where the disk image pulled ahead of LVM by about 20%. This I can't account for and will need to retest because it doesn't make a lot of sense. All of the Sequential Create/Delete stats were within 10% of each other.
Test 3 - Dom0 - LVM
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
vs.soundlinu 10048M 38679 94 74047 42 30272 6 40389 84 75538 2 138.7 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 13678 88 +++++ +++ 28937 97 12704 84 +++++ +++ 26902 94
vs.soundlinuxtraining.com,10048M,38679,94,74047,42,30272,6,40389,84,75538,2,138.7,0,16,13678,88,+++++,+++,28937,97,12704,84,+++++,+++,26902,94
The last test was done in Dom0 and isn't an exact duplicate of the other tests because I have 5 GB of ram available and needed to bump the file size to get the test to run. In the future I'll have a more apples to apples comparison. What is interesting is that the DomU LVM is within 15-20% of the Dom0 LVM performance most of the time and only the very strange results for domU Sequential Output - Block falling further behind.
I think that I need to do more testing but I was surprised that a disk image did as well as it did.
In setting up a Xen virtualized web server with about 15 GB of static files I questioned the wisdom of using a disk image as apposed to LVM. I read a bunch of forums about which is better and it seems the disk images are easier to manage because you can just copy to make backups etc.. LVM you just can't move it and pop it up whereever you want but you have more flexibility in resizeing and backing them up within the host OS. However what I didn't find on the forums is performance tests. People theororized about the speed difference but it seems nobodies sat down and done some tests. It's my goal that after summer vacation to put together a performance whitepaper comparing all the virtual machine solutions. For now I'll just put up xen disk images against LVM.
So I created a 10 GB empty disk image using dd and I created a 10 GB LVM Logical volume and assigned both of them to the domU.
name = "rheltest"
memory = "512"
disk = [ 'tap:aio:/srv/xen/rhelos5.img,xvda,w', 'tap:aio:/srv/xen/rheltest.img,xvdb,w', 'phy:/dev/vgsys/lvtest,xvdc,w' ]
vif = [ 'bridge=xenbr0', ]
bootloader="/usr/bin/pygrub"
vcpus=1
on_reboot = 'restart'
on_crash = 'restart'
Test 1 - disk image
The disk image /dev/xvdb1 was mounted as /media/test1. The images itself was stored on a 500 GB SATA drive.
/dev/xvdb1 10317828 154236 9639476 2% /media/test1
[root@localhost ~]# bonnie++ -s 2048 -d /media/test1 -u root
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
localhost.locald 2G 6065 15 70595 37 20649 2 26878 53 57270 0 135.8 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 17008 99 +++++ +++ 26079 90 16002 94 +++++ +++ 29094 99
localhost.localdomain,2G,6065,15,70595,37,20649,2,26878,53,57270,0,135.8,0,16,17008,99,+++++,+++,26079,90,16002,94,+++++,+++,29094,99
Test 2 - LVM
The LVM Logical Volume was created on the same 500 GB SATA drive and mounted in the domU as /media/test2
/dev/xvdc 10321208 154236 9642684 2% /media/test2
[root@localhost ~]# bonnie++ -s 2048 -d /media/test2 -u root
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
localhost.locald 2G 34825 92 50898 26 24833 4 35920 69 77594 1 137.9 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 15556 92 +++++ +++ 26198 96 16281 98 +++++ +++ 28508 100
localhost.localdomain,2G,34825,92,50898,26,24833,4,35920,69,77594,1,137.9,0,16,15556,92,+++++,+++,26198,96,16281,98,+++++,+++,28508,100
INIT: version 2.86 reloading
LVM soundly trounced the disk image in Sequential Output - Per Chr by about 600% and bettered it by about 20-30% in the other tests. The on interesting one though was Sequential Output - Block where the disk image pulled ahead of LVM by about 20%. This I can't account for and will need to retest because it doesn't make a lot of sense. All of the Sequential Create/Delete stats were within 10% of each other.
Test 3 - Dom0 - LVM
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
vs.soundlinu 10048M 38679 94 74047 42 30272 6 40389 84 75538 2 138.7 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 13678 88 +++++ +++ 28937 97 12704 84 +++++ +++ 26902 94
vs.soundlinuxtraining.com,10048M,38679,94,74047,42,30272,6,40389,84,75538,2,138.7,0,16,13678,88,+++++,+++,28937,97,12704,84,+++++,+++,26902,94
The last test was done in Dom0 and isn't an exact duplicate of the other tests because I have 5 GB of ram available and needed to bump the file size to get the test to run. In the future I'll have a more apples to apples comparison. What is interesting is that the DomU LVM is within 15-20% of the Dom0 LVM performance most of the time and only the very strange results for domU Sequential Output - Block falling further behind.
I think that I need to do more testing but I was surprised that a disk image did as well as it did.
Xen Guest Disk Resize
Xen Guest Disk Resize
This is a million dollar question. The answer can be "yes" and "no" and highly depends upon the configuration of the guest backend and how it has been partitioned inside the guest. Most people want to resize without initiating a reboot of the guest system, but most of these people make wrong choice while configuring the guest backend intially and end up having to reboot the guest or not being able to resize partitions inside the guest.
A lot things need to be taken into consideration to decide how to resize the guest storage. Before proceeding into how to resize, it's good explain different types of backends that can be used for guest.
1 - Block device. A block device in Dom0 can be used as a backend for the guest. It can be raw partitions, LVMs, raid devices and etc. It can even be a unpartitioned disk as a whole (like "sda" which is not recommended).
2 - File based storage. A file built with a specific size using zeros in Dom0 can be used as the backend of the guest. While using a file based storage it can be any of the below two types.
2.1 - Sparse file. While using a sparse file, disk blocks are not pre-allocated while creating the file, but are allocated only when data is written to the disk fom the guest. This is not recommended for production uses due to performance issues.
2.2 - Fully allocated file. Entire blocks are allocated while creating the file based image. This gives more performance and is recommended for production usage if using block devices are not an option.
I would explore different types of storage configurations and how resizing can be done in those scenarios. I prefer to abstain from explaining the nasty methods of resizing partitions using "parted" or "fdisk" inside the guest. So I prefer to say, if LVM is not used inside the guest, resizing a partition is not possible. Only new partitions can be created after extending the backend. If resizing using parted or fdisk is preferred for anyone, it's upto them.
Different Scenarios and How to resize.
----------------------------------------------
1- LVM is used in both Host and Guest. The backend for the guest is an LVM device in Dom0 and this has been repartitioned in guest using LVM. There are two ways to resize it.
1.1 - Create a new LV in Dom0 and attach it to the guest as a second disk. Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred for most xen users.
1.2 - Extend the LV device which is already attached to the guest in Dom0. After the LV is extended in Dom0, the guest should be rebooted to see the new size. There is currently no way to let the guest now that the size of backend has changed without a reboot. Once the guest is rebooted, it would show the new size as free. Create a new partition using the free space, make it a PV, extend the Volume Group using that PV, then extend the LV using the free space in VG. Most people don't like this method since it requires a guest reboot, but most people resize the LVM in Dom0 expecting that the guest would recognize the new space without a reboot and end up rebooting the guest and keep blasting the company that delivers the product.
2 - Raw partition - Eg, sda1 - is used in Host as the backend of the guest and LVM is used inside the guest.
2.1 - Attach a new partition to the guest - Eg, sdb1 - as a second disk. Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred.
2.2 - The other method may be to extend the raw partition in the host using parted or fdisk. Reboot the guest to see the new size and extend LVM inside the guest. This is not preferred and may be dangerous.
3 - Fully allocated file based images are used as the guest backend.
3.1 - Create a new fully allocated file based image in Dom0 and attach it to the guest as a second disk (see 3.2 for details on how to create it). Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred.
3.2 - Extend the fully allocated file image in Dom0 which is already attached to the guest. It's recommended to shutdown the guest while doing this.
A fully allocated 5 GB /vm/images/guest.img disk is created using the below command initially while creating the guest.
# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=5120
To extend and make it 10G without losing data, the below command can be executed which is the safest method, I think.
# dd if=/dev/zero bs=1M count=5120 >> /vm/images/guest.img
Then create new partitions inside the guest and extend the LVs which already exist or use the new partitions individually.
4 - Sparse File based images are used as the guest backend.
4.1 - Create a new sparse file image in Dom0 and attach it to the guest as a second disk (see 4.2 for more details on how to create it). Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred.
4.2 - Extend the sparse file image in Dom0 which is already attached to the guest It's recommended to shutdown the guest while doing this.
A sparse file image with 5 GB of size - Eg, /vm/images/guest.img - is created using the below command initially while creating the guest.
# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=0 seek=5120 conv=notrunc
To extend and make this 10G without losing data, the below command can be executed which is the safest method, I think.
# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=0 seek=10240 conv=notrunc
Then create new partitions inside the guest and extend the LVs which already exists or use the new partitions individually or to create new VGs and LVs.
Note: Sparse files are not recommended for production system due to preformance reasons. Always use fully allocated file based images.
- In all x.1 above, it's ok to use all possible options. Eg, in 4.1, new LVM in Dom0 can be created and attached to the guest, a new raw partition can be created and attached to the guest and a new fully allocated file based image can be attached to the guest to extend the volumes inside it. This is applicable for all x.1 explained above. I used only one option for my convenience.
- The task "attach it to the guest as a second disk" can be achieved by following either of the below two methods. This is applicable only for x.1 above, not x.2.
1 - virt-manager -> Open -> View -> Details -> Hardware -> Add -> Storage Device -> Simple File/Normal Partition -> Device Type - Virtual Disk. This is the hassle free method.
2 - Edit guest configuration file and add the second disk details to the configuration file. See examples from the sample configuration file. Can also be attached live by the xm command as below.
# xm block-attach
Eg, to attach a new lvm block device as xvdb to guest named "guest1" with read-write, below command need to be used.
# xm block-attach guest1 phy:/dev/VolGroup00/LV1 /dev/xvdb w
or
# virsh attach-disk guest1 --driver phy /dev/VolGroup00/LV1 xvdb
To attach a new file based image as xvdb to guest named guest1 with read-write, below command can be used.
# xm block-attach guest1 tap:aio:/vm/images/image1.img /dev/xvdb w
Or
# virsh attach-disk guest1 --driver tap --subdriver aio /vm/images/image1.img xvdb
- Reszing of guest LVs can be achieved without a reboot if x.1 is followed, but a reboot of the guest is necessary if x.2 is followed for the guest to see the new disk size.
- The online attaching of disks may not work as expected for fully virtualized guests which doesn't have PV drivers installed.
This is a million dollar question. The answer can be "yes" and "no" and highly depends upon the configuration of the guest backend and how it has been partitioned inside the guest. Most people want to resize without initiating a reboot of the guest system, but most of these people make wrong choice while configuring the guest backend intially and end up having to reboot the guest or not being able to resize partitions inside the guest.
A lot things need to be taken into consideration to decide how to resize the guest storage. Before proceeding into how to resize, it's good explain different types of backends that can be used for guest.
1 - Block device. A block device in Dom0 can be used as a backend for the guest. It can be raw partitions, LVMs, raid devices and etc. It can even be a unpartitioned disk as a whole (like "sda" which is not recommended).
2 - File based storage. A file built with a specific size using zeros in Dom0 can be used as the backend of the guest. While using a file based storage it can be any of the below two types.
2.1 - Sparse file. While using a sparse file, disk blocks are not pre-allocated while creating the file, but are allocated only when data is written to the disk fom the guest. This is not recommended for production uses due to performance issues.
2.2 - Fully allocated file. Entire blocks are allocated while creating the file based image. This gives more performance and is recommended for production usage if using block devices are not an option.
I would explore different types of storage configurations and how resizing can be done in those scenarios. I prefer to abstain from explaining the nasty methods of resizing partitions using "parted" or "fdisk" inside the guest. So I prefer to say, if LVM is not used inside the guest, resizing a partition is not possible. Only new partitions can be created after extending the backend. If resizing using parted or fdisk is preferred for anyone, it's upto them.
Different Scenarios and How to resize.
----------------------------------------------
1- LVM is used in both Host and Guest. The backend for the guest is an LVM device in Dom0 and this has been repartitioned in guest using LVM. There are two ways to resize it.
1.1 - Create a new LV in Dom0 and attach it to the guest as a second disk. Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred for most xen users.
1.2 - Extend the LV device which is already attached to the guest in Dom0. After the LV is extended in Dom0, the guest should be rebooted to see the new size. There is currently no way to let the guest now that the size of backend has changed without a reboot. Once the guest is rebooted, it would show the new size as free. Create a new partition using the free space, make it a PV, extend the Volume Group using that PV, then extend the LV using the free space in VG. Most people don't like this method since it requires a guest reboot, but most people resize the LVM in Dom0 expecting that the guest would recognize the new space without a reboot and end up rebooting the guest and keep blasting the company that delivers the product.
2 - Raw partition - Eg, sda1 - is used in Host as the backend of the guest and LVM is used inside the guest.
2.1 - Attach a new partition to the guest - Eg, sdb1 - as a second disk. Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred.
2.2 - The other method may be to extend the raw partition in the host using parted or fdisk. Reboot the guest to see the new size and extend LVM inside the guest. This is not preferred and may be dangerous.
3 - Fully allocated file based images are used as the guest backend.
3.1 - Create a new fully allocated file based image in Dom0 and attach it to the guest as a second disk (see 3.2 for details on how to create it). Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred.
3.2 - Extend the fully allocated file image in Dom0 which is already attached to the guest. It's recommended to shutdown the guest while doing this.
A fully allocated 5 GB /vm/images/guest.img disk is created using the below command initially while creating the guest.
# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=5120
To extend and make it 10G without losing data, the below command can be executed which is the safest method, I think.
# dd if=/dev/zero bs=1M count=5120 >> /vm/images/guest.img
Then create new partitions inside the guest and extend the LVs which already exist or use the new partitions individually.
4 - Sparse File based images are used as the guest backend.
4.1 - Create a new sparse file image in Dom0 and attach it to the guest as a second disk (see 4.2 for more details on how to create it). Repartition the second disk in guest, extend the Volume Group using the new disk, then extend the LV using the additinal free space in the VG. This method does not require a reboot of the guest and is preferred.
4.2 - Extend the sparse file image in Dom0 which is already attached to the guest It's recommended to shutdown the guest while doing this.
A sparse file image with 5 GB of size - Eg, /vm/images/guest.img - is created using the below command initially while creating the guest.
# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=0 seek=5120 conv=notrunc
To extend and make this 10G without losing data, the below command can be executed which is the safest method, I think.
# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=0 seek=10240 conv=notrunc
Then create new partitions inside the guest and extend the LVs which already exists or use the new partitions individually or to create new VGs and LVs.
Note: Sparse files are not recommended for production system due to preformance reasons. Always use fully allocated file based images.
- In all x.1 above, it's ok to use all possible options. Eg, in 4.1, new LVM in Dom0 can be created and attached to the guest, a new raw partition can be created and attached to the guest and a new fully allocated file based image can be attached to the guest to extend the volumes inside it. This is applicable for all x.1 explained above. I used only one option for my convenience.
- The task "attach it to the guest as a second disk" can be achieved by following either of the below two methods. This is applicable only for x.1 above, not x.2.
1 - virt-manager -> Open -> View -> Details -> Hardware -> Add -> Storage Device -> Simple File/Normal Partition -> Device Type - Virtual Disk. This is the hassle free method.
2 - Edit guest configuration file and add the second disk details to the configuration file. See examples from the sample configuration file. Can also be attached live by the xm command as below.
# xm block-attach
Eg, to attach a new lvm block device as xvdb to guest named "guest1" with read-write, below command need to be used.
# xm block-attach guest1 phy:/dev/VolGroup00/LV1 /dev/xvdb w
or
# virsh attach-disk guest1 --driver phy /dev/VolGroup00/LV1 xvdb
To attach a new file based image as xvdb to guest named guest1 with read-write, below command can be used.
# xm block-attach guest1 tap:aio:/vm/images/image1.img /dev/xvdb w
Or
# virsh attach-disk guest1 --driver tap --subdriver aio /vm/images/image1.img xvdb
- Reszing of guest LVs can be achieved without a reboot if x.1 is followed, but a reboot of the guest is necessary if x.2 is followed for the guest to see the new disk size.
- The online attaching of disks may not work as expected for fully virtualized guests which doesn't have PV drivers installed.
Xen LVM Based Guest & Cloning
Preparing for an LVM based Xen Guest Domain & Cloning the Host OS on the Guest Root Partition
Intended Audience:
If you may need a minimal Linux installation for your guest OS but If the host system has graphical desktop environments, office productivity applications and other packages not needed by the guest OS then cloning the host environment may not be the best approach and the users are advised to skip at this point and if on the other hand, you are confident that everything on your host operating system will be of use in the guest system, or are unconcerned about disk space then this approach will work well for you.
Tested host Machine: 10.65.70.1 (Dell 1)
Guest cloned : host-cloned-xenguest (10.65.70.111)
Preparing for an LVM based Xen Guest Domain & Cloning the Host OS on the Guest Root Partition
We are using the following logical volumes /dev/sdc5 and /dev/sdc6 to hold the root file system of the operating system and /dev/sdc7 for the guest swap space.
Device used from the storage
/dev/sdc5 9487 10156 5381743+ 8e Linux LVM
/dev/sdc6 10157 10826 5381743+ 8e Linux LVM
/dev/sdc7 10827 11851 8233281 82 Linux swap / Solaris
1) Converting Physical Disks into Physical Volumes
pvcreate /dev/sdc5 /dev/sdc6
2) Information about physical volumes can be obtained by running the pvdisplay tool:
pvdisplay
3) Now that we have two physical volumes the next step is to create a volume group to contain them.
The following command creates a volume group called xenvolg and assigns the /dev/sdc5 physical volume to it.
vgcreate xenvolg /dev/sdc5
4) Next we need to add the second physical volume to xenvolg, again using the vgextend command:
vgextend xenvolg /dev/sdc6
5) Use the vgdisplay command to list information about the new volume group.
vgdisplay xenvolg
6) Next step is to create a logical volume comprising the two physical volumes in our volume group to use for the root filesystem of our Xen guest domain (domU).
lvcreate -L 5300M -n xenlogvol xenvolg
7) Information about the logical volume may be accessed using the lvdisplay command.
lvdisplay /dev/xenvolg/xenlogvol
8) Creating a Filesystem on the Logical Volume
mkfs.ext3 /dev/xenvolg/xenlogvol
The root filesystem is now ready to be mounted and populated with system files.
9) Configuring the Swap Partition for the Xen Guest System.The mkswap command is used to configure this partition as swap space:
mkswap /dev/sdc7
10) Mounting the Root Filesystem
The following commands create a directory named /xen and then mount the filesystem located on /dev/XenVolG/XenLogVol at this location:
mkdir /xen
mount /dev/xenvolg/xenlogvol /xen/
11) Cloning the Host OS on the Guest Root Partition
One of the easiest ways to install the necessary files on the guest OS root filesystem is to simply copy the files from the host operating system. Before doing so, however, it is important to keep in mind a few points.
12) Firstly, the following steps will copy a considerable amount of files from the host operating system to the guest root filesystem. This may well be much more than is actually necessary.
13) For example, you may need a minimal Linux installation for your guest OS. If the host system has graphical desktop environments, office productivity applications and other packages not needed by the guest OS then cloning the host environment may not be the best approach.
14) If, on the other hand, you are confident that everything on your host operating system will be of use in the guest system, or are unconcerned about disk space then this approach will work well for you.
15) The following steps assume that the root filesystem for the Xen guest has been mounted in /xen
16) Having created the mount point and mounted our root filesystem image the next step is to copy the relevant files from the host operating system to guest filesystem image. Execute the following command to copy the required directories and files to the root filesystem (be very careful to substitute the correct destination path if you mounted the filesystem somewhere other than /xen):
cp -ax /{bin,dev,etc,lib,root,sbin,usr,var} /xen
17) Once the copy process is completed a number of directories need to be created (once again the following example assumes the image has been mounted at /xen):
mkdir /xen/{home,proc,opt,sys,tmp}
18) The tmp directory created above must have read/write access for all users. To ensure this the chmod command needs to be run:
chmod 777 /xen/tmp
19) Creating a Xen Configuration File
Now that we have physical disk partitions for the root filesystem and the swap space, and have populated the root filesystem with the necessary system files the next step is to create a Xen configuration file.
In this file we need to specify the kernel and initial RAM Disk image files together with directives to map the disk partitions to devices within the guest OS.
For the purposes of this example we will load the initial RAM disk and kernel images from the host operating system. These are typically located in the /boot directory. The kernel file typically begins with the name vmlinuz and the initial RAM disk begins with initrd. These two images are defined in the Xen configuration file using the kernel = and ramdisk = directives. For example:
kernel = "/boot/vmlinuz-2.6.18-128.el5xen"
ramdisk = "/boot/initrd-2.6.18-128.el5xen.img"
Next, the amount of memory to be allocated to the guest system is defined using the memory = directive. The following assigns 512Mb to the guest:
memory = 256
Each guest domain needs to have a name by which it can be referenced when using the Xen management tools. This is assigned using name = :
name = "host-cloned-xenguest"
Now we specify network configuration options. The following lines indicate to Xen that the IP address of the system will be assigned using DHCP and the empty vif line instructs Xen to use the default values for the network interface configuration:
vif = [ '' ]
dhcp = "dhcp"
Finally the disk = directive is used to map the xenlogvol logical volume we have created with a guest operating system device. The following lines map the root logical volume (reported by lvdisplay as being located at /dev/xenvolg/xenlogvol) and swap partition to /dev/hda1 and /dev/hda2 respectively and define the root filesystem as /dev/hda1):
disk = ['phy:xenvolg/xenlogvol,hda1,w', 'phy:sdc7,hda2,w']
root = "/dev/xvda1 ro"
Note that these device mappings will be needed when the fstab file is configured later in this chapter.
Bringing all these configuration lines together should result in the following configuration file which we will name host-cloned-xenguest
cat host-cloned-xenguest
##################################################################
name = "host-cloned-xenguest"
maxmem = 256
memory = 256
vcpus = 1
kernel = "/boot/vmlinuz-2.6.18-128.el5xen"
#ramdisk = "/boot/initrd-2.6.18-128.el5xen.img"
####Newly created initrd initialization RAM Disk without SCSI
ramdisk = "/boot/initrd-2.6.18-128.el5xen-no-scsi.img"
root = "/dev/hda1 ro"
on_poweroff = "destroy"
on_reboot = "destroy"
on_crash = "destroy"
vfb = [ "type=vnc,vncdisplay=0,vncunused=0,keymap=en-us" ]
disk = [ "phy:/dev/xenvolg/xenlogvol,hda1,w", "phy:/dev/sdc7,hda2,w" ]
vif = [ "mac=00:16:3e:2a:e9:1e,bridge=xenbr0,script=vif-bridge", ]
####################################################################
20) Configuring System Files for the Guest Operating System
It is important to keep in mind that at this point in the process we have copied all of the system files from our host operating system onto the disk image for our guest operating system. It is vital at this point, therefore, that we change any system configuration files to meet the requirements of our guest domain. Typical settings that will need to be changed are:
/etc/fstab
/etc/passwd
/etc/group
/etc/hosts
/etc/sysconfig/network
/etc/exports
The guest OS copy of the fstab file needs to be modified to reflect the device mappings in the Xen configuration file created above (recall that the root filesystem was mapped to /dev/hda1 and swap to /dev/hda2). For example:
vi /xen/etc/fstab
/dev/hda1 / ext3 defaults 1 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/hda2 swap swap defaults 0 0
21) Booting the Guest OS
Now all that remains is to boot the guest operating system. Before booting the guest system it is important to first unmount the guest root filesystem:
umount /xen
22) With the set up and configuration complete we are now ready to start up the guest OS. This is achieved using the xm create command:
xm create host-cloned-xenguest -c
The -c flag above instructs Xen to attach a console to the guest system so that we see output as the system boots. The following output displays the initial phases of a successful boot:
xm create host-cloned-xenguest -c
Using config file "/etc/xen/host-cloned-xenguest".
Started domain host-cloned-xenguest
Linux version 2.6.18-128.el5xen (mockbuild@hs20-bc1-5.build.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Wed Dec 17 12:22:24 EST 2008
BIOS-provided physical RAM map:
Xen: 0000000000000000 - 0000000010800000 (usable)
0MB HIGHMEM available.
264MB LOWMEM available.
NX (Execute Disable) protection: active
ACPI in unprivileged domain disabled
Built 1 zonelists. Total pages: 67584
Kernel command line: root=/dev/hda1 ro
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0744000 soft=c0724000
PID hash table entries: 2048 (order: 11, 8192 bytes)
Xen reported: 3192.204 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Software IO TLB disabled
vmalloc area: d1000000-f4ffe000, maxmem 2d7fe000
Memory: 248960k/270336k available (2124k kernel code, 12848k reserved, 877k data, 176k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 7984.97 BogoMIPS (lpj=15969949)
Security Framework v1.0.0 initialized
SELinux: Initializing.
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 13k freed
Brought up 1 CPUs
checking if image is initramfs... it is
Freeing initrd memory: 5528k freed
Grant table initialized
NET: Registered protocol family 16
ACPI Exception (utmutex-0262): AE_BAD_PARAMETER, Thread C06F2AA0 could not acquire Mutex [2] [20060707]
No dock devices found.
ACPI Exception (utmutex-0262): AE_BAD_PARAMETER, Thread C06F2AA0 could not acquire Mutex [2] [20060707]
Brought up 1 CPUs
PCI: setting up Xen PCI frontend stub
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
xen_mem: Initialising balloon driver.
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: System does not support PCI
PCI: System does not support PCI
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
audit: initializing netlink socket (disabled)
type=2000 audit(1239887579.855:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
alg: No test for crc32c (crc32c-generic)
ksign: Installing public key data
Loading keyring
- Added public key 31B497468CDD12CF
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
rtc: IRQ 8 is not free.
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Xen virtual console successfully installed as xvc0
Event-channel device installed.
Console: switching to colour frame buffer device 100x37
input: Xen Virtual Keyboard/Mouse as /class/input/input0
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
ide-floppy driver 0.99.newide
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
PNP: No PS/2 controller found. Probing ports directly.
i8042.c: No controller found.
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
XENBUS: Device with no driver: device/vbd/769
XENBUS: Device with no driver: device/vbd/770
XENBUS: Device with no driver: device/vif/0
Freeing unused kernel memory: 176k freed
Write protecting the kernel read-only data: 383k
Registering block device major 3
USB Universal Host Controller Interface driver v3.0
megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006)
SCSI subsystem initialized
megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006)
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.11.5-ioctl (2007-12-12) initialised: dm-devel@redhat.com
device-mapper: dm-raid45: initialized v0.2429
netfront: Initialising virtual ethernet driver.
netfront: device eth0 has flipping receive path.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Bridge firewalling registered
virbr0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Kernel 2.6.18-128.el5xen on an i686
vhost1-cloned.redhat.com login:root
Password:
Troubleshooting
Note that using the default host system initial RAM disk can cause problems on some Linux distributions. If the system fails to boot it may be necessary to generate an initial RAM disk without SCSI modules.
The typical full output from this type of Xen Guest OS boot failure is as follows:
Mounting root filesystem.
mount: could not find filesystem '/dev/root'
Setting up other filesystems.
Setting up new root fs
setuproot: moving /dev failed: No such file or directory
no fstab.sys, mounting internal defaults
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
switchroot: mount failed: No such file or directory
Booting has failed.
The most common cause of this problem is a conflict of SCSI modules. In order to resolve this it is necessary to create a new initrd initialization RAM Disk without SCSI modules, and then use this to boot the guest Linux operating system. This can be achieved using the following command:
mkinitrd --omit-scsi-modules --with=xennet --with=xenblk --preload=xenblk initrd-$(uname -r)-no-scsi.img $(uname -r)
Once the new initrd image file has been generated simply refer to it in the "ramdisk" line of the Xen configuration file, for example:
#ramdisk = "/boot/initrd-2.6.18-128.el5xen.img"
ramdisk = "/boot/initrd-2.6.18-128.el5xen-no-scsi.img"
Happy cloning.............
Intended Audience:
If you may need a minimal Linux installation for your guest OS but If the host system has graphical desktop environments, office productivity applications and other packages not needed by the guest OS then cloning the host environment may not be the best approach and the users are advised to skip at this point and if on the other hand, you are confident that everything on your host operating system will be of use in the guest system, or are unconcerned about disk space then this approach will work well for you.
Tested host Machine: 10.65.70.1 (Dell 1)
Guest cloned : host-cloned-xenguest (10.65.70.111)
Preparing for an LVM based Xen Guest Domain & Cloning the Host OS on the Guest Root Partition
We are using the following logical volumes /dev/sdc5 and /dev/sdc6 to hold the root file system of the operating system and /dev/sdc7 for the guest swap space.
Device used from the storage
/dev/sdc5 9487 10156 5381743+ 8e Linux LVM
/dev/sdc6 10157 10826 5381743+ 8e Linux LVM
/dev/sdc7 10827 11851 8233281 82 Linux swap / Solaris
1) Converting Physical Disks into Physical Volumes
pvcreate /dev/sdc5 /dev/sdc6
2) Information about physical volumes can be obtained by running the pvdisplay tool:
pvdisplay
3) Now that we have two physical volumes the next step is to create a volume group to contain them.
The following command creates a volume group called xenvolg and assigns the /dev/sdc5 physical volume to it.
vgcreate xenvolg /dev/sdc5
4) Next we need to add the second physical volume to xenvolg, again using the vgextend command:
vgextend xenvolg /dev/sdc6
5) Use the vgdisplay command to list information about the new volume group.
vgdisplay xenvolg
6) Next step is to create a logical volume comprising the two physical volumes in our volume group to use for the root filesystem of our Xen guest domain (domU).
lvcreate -L 5300M -n xenlogvol xenvolg
7) Information about the logical volume may be accessed using the lvdisplay command.
lvdisplay /dev/xenvolg/xenlogvol
8) Creating a Filesystem on the Logical Volume
mkfs.ext3 /dev/xenvolg/xenlogvol
The root filesystem is now ready to be mounted and populated with system files.
9) Configuring the Swap Partition for the Xen Guest System.The mkswap command is used to configure this partition as swap space:
mkswap /dev/sdc7
10) Mounting the Root Filesystem
The following commands create a directory named /xen and then mount the filesystem located on /dev/XenVolG/XenLogVol at this location:
mkdir /xen
mount /dev/xenvolg/xenlogvol /xen/
11) Cloning the Host OS on the Guest Root Partition
One of the easiest ways to install the necessary files on the guest OS root filesystem is to simply copy the files from the host operating system. Before doing so, however, it is important to keep in mind a few points.
12) Firstly, the following steps will copy a considerable amount of files from the host operating system to the guest root filesystem. This may well be much more than is actually necessary.
13) For example, you may need a minimal Linux installation for your guest OS. If the host system has graphical desktop environments, office productivity applications and other packages not needed by the guest OS then cloning the host environment may not be the best approach.
14) If, on the other hand, you are confident that everything on your host operating system will be of use in the guest system, or are unconcerned about disk space then this approach will work well for you.
15) The following steps assume that the root filesystem for the Xen guest has been mounted in /xen
16) Having created the mount point and mounted our root filesystem image the next step is to copy the relevant files from the host operating system to guest filesystem image. Execute the following command to copy the required directories and files to the root filesystem (be very careful to substitute the correct destination path if you mounted the filesystem somewhere other than /xen):
cp -ax /{bin,dev,etc,lib,root,sbin,usr,var} /xen
17) Once the copy process is completed a number of directories need to be created (once again the following example assumes the image has been mounted at /xen):
mkdir /xen/{home,proc,opt,sys,tmp}
18) The tmp directory created above must have read/write access for all users. To ensure this the chmod command needs to be run:
chmod 777 /xen/tmp
19) Creating a Xen Configuration File
Now that we have physical disk partitions for the root filesystem and the swap space, and have populated the root filesystem with the necessary system files the next step is to create a Xen configuration file.
In this file we need to specify the kernel and initial RAM Disk image files together with directives to map the disk partitions to devices within the guest OS.
For the purposes of this example we will load the initial RAM disk and kernel images from the host operating system. These are typically located in the /boot directory. The kernel file typically begins with the name vmlinuz and the initial RAM disk begins with initrd. These two images are defined in the Xen configuration file using the kernel = and ramdisk = directives. For example:
kernel = "/boot/vmlinuz-2.6.18-128.el5xen"
ramdisk = "/boot/initrd-2.6.18-128.el5xen.img"
Next, the amount of memory to be allocated to the guest system is defined using the memory = directive. The following assigns 512Mb to the guest:
memory = 256
Each guest domain needs to have a name by which it can be referenced when using the Xen management tools. This is assigned using name = :
name = "host-cloned-xenguest"
Now we specify network configuration options. The following lines indicate to Xen that the IP address of the system will be assigned using DHCP and the empty vif line instructs Xen to use the default values for the network interface configuration:
vif = [ '' ]
dhcp = "dhcp"
Finally the disk = directive is used to map the xenlogvol logical volume we have created with a guest operating system device. The following lines map the root logical volume (reported by lvdisplay as being located at /dev/xenvolg/xenlogvol) and swap partition to /dev/hda1 and /dev/hda2 respectively and define the root filesystem as /dev/hda1):
disk = ['phy:xenvolg/xenlogvol,hda1,w', 'phy:sdc7,hda2,w']
root = "/dev/xvda1 ro"
Note that these device mappings will be needed when the fstab file is configured later in this chapter.
Bringing all these configuration lines together should result in the following configuration file which we will name host-cloned-xenguest
cat host-cloned-xenguest
##################################################################
name = "host-cloned-xenguest"
maxmem = 256
memory = 256
vcpus = 1
kernel = "/boot/vmlinuz-2.6.18-128.el5xen"
#ramdisk = "/boot/initrd-2.6.18-128.el5xen.img"
####Newly created initrd initialization RAM Disk without SCSI
ramdisk = "/boot/initrd-2.6.18-128.el5xen-no-scsi.img"
root = "/dev/hda1 ro"
on_poweroff = "destroy"
on_reboot = "destroy"
on_crash = "destroy"
vfb = [ "type=vnc,vncdisplay=0,vncunused=0,keymap=en-us" ]
disk = [ "phy:/dev/xenvolg/xenlogvol,hda1,w", "phy:/dev/sdc7,hda2,w" ]
vif = [ "mac=00:16:3e:2a:e9:1e,bridge=xenbr0,script=vif-bridge", ]
####################################################################
20) Configuring System Files for the Guest Operating System
It is important to keep in mind that at this point in the process we have copied all of the system files from our host operating system onto the disk image for our guest operating system. It is vital at this point, therefore, that we change any system configuration files to meet the requirements of our guest domain. Typical settings that will need to be changed are:
/etc/fstab
/etc/passwd
/etc/group
/etc/hosts
/etc/sysconfig/network
/etc/exports
The guest OS copy of the fstab file needs to be modified to reflect the device mappings in the Xen configuration file created above (recall that the root filesystem was mapped to /dev/hda1 and swap to /dev/hda2). For example:
vi /xen/etc/fstab
/dev/hda1 / ext3 defaults 1 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/hda2 swap swap defaults 0 0
21) Booting the Guest OS
Now all that remains is to boot the guest operating system. Before booting the guest system it is important to first unmount the guest root filesystem:
umount /xen
22) With the set up and configuration complete we are now ready to start up the guest OS. This is achieved using the xm create command:
xm create host-cloned-xenguest -c
The -c flag above instructs Xen to attach a console to the guest system so that we see output as the system boots. The following output displays the initial phases of a successful boot:
xm create host-cloned-xenguest -c
Using config file "/etc/xen/host-cloned-xenguest".
Started domain host-cloned-xenguest
Linux version 2.6.18-128.el5xen (mockbuild@hs20-bc1-5.build.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Wed Dec 17 12:22:24 EST 2008
BIOS-provided physical RAM map:
Xen: 0000000000000000 - 0000000010800000 (usable)
0MB HIGHMEM available.
264MB LOWMEM available.
NX (Execute Disable) protection: active
ACPI in unprivileged domain disabled
Built 1 zonelists. Total pages: 67584
Kernel command line: root=/dev/hda1 ro
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0744000 soft=c0724000
PID hash table entries: 2048 (order: 11, 8192 bytes)
Xen reported: 3192.204 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Software IO TLB disabled
vmalloc area: d1000000-f4ffe000, maxmem 2d7fe000
Memory: 248960k/270336k available (2124k kernel code, 12848k reserved, 877k data, 176k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 7984.97 BogoMIPS (lpj=15969949)
Security Framework v1.0.0 initialized
SELinux: Initializing.
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 13k freed
Brought up 1 CPUs
checking if image is initramfs... it is
Freeing initrd memory: 5528k freed
Grant table initialized
NET: Registered protocol family 16
ACPI Exception (utmutex-0262): AE_BAD_PARAMETER, Thread C06F2AA0 could not acquire Mutex [2] [20060707]
No dock devices found.
ACPI Exception (utmutex-0262): AE_BAD_PARAMETER, Thread C06F2AA0 could not acquire Mutex [2] [20060707]
Brought up 1 CPUs
PCI: setting up Xen PCI frontend stub
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
xen_mem: Initialising balloon driver.
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: System does not support PCI
PCI: System does not support PCI
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
audit: initializing netlink socket (disabled)
type=2000 audit(1239887579.855:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
alg: No test for crc32c (crc32c-generic)
ksign: Installing public key data
Loading keyring
- Added public key 31B497468CDD12CF
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
rtc: IRQ 8 is not free.
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Xen virtual console successfully installed as xvc0
Event-channel device installed.
Console: switching to colour frame buffer device 100x37
input: Xen Virtual Keyboard/Mouse as /class/input/input0
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
ide-floppy driver 0.99.newide
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
PNP: No PS/2 controller found. Probing ports directly.
i8042.c: No controller found.
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
XENBUS: Device with no driver: device/vbd/769
XENBUS: Device with no driver: device/vbd/770
XENBUS: Device with no driver: device/vif/0
Freeing unused kernel memory: 176k freed
Write protecting the kernel read-only data: 383k
Registering block device major 3
USB Universal Host Controller Interface driver v3.0
megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006)
SCSI subsystem initialized
megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006)
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.11.5-ioctl (2007-12-12) initialised: dm-devel@redhat.com
device-mapper: dm-raid45: initialized v0.2429
netfront: Initialising virtual ethernet driver.
netfront: device eth0 has flipping receive path.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Bridge firewalling registered
virbr0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Kernel 2.6.18-128.el5xen on an i686
vhost1-cloned.redhat.com login:root
Password:
Troubleshooting
Note that using the default host system initial RAM disk can cause problems on some Linux distributions. If the system fails to boot it may be necessary to generate an initial RAM disk without SCSI modules.
The typical full output from this type of Xen Guest OS boot failure is as follows:
Mounting root filesystem.
mount: could not find filesystem '/dev/root'
Setting up other filesystems.
Setting up new root fs
setuproot: moving /dev failed: No such file or directory
no fstab.sys, mounting internal defaults
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
switchroot: mount failed: No such file or directory
Booting has failed.
The most common cause of this problem is a conflict of SCSI modules. In order to resolve this it is necessary to create a new initrd initialization RAM Disk without SCSI modules, and then use this to boot the guest Linux operating system. This can be achieved using the following command:
mkinitrd --omit-scsi-modules --with=xennet --with=xenblk --preload=xenblk initrd-$(uname -r)-no-scsi.img $(uname -r)
Once the new initrd image file has been generated simply refer to it in the "ramdisk" line of the Xen configuration file, for example:
#ramdisk = "/boot/initrd-2.6.18-128.el5xen.img"
ramdisk = "/boot/initrd-2.6.18-128.el5xen-no-scsi.img"
Happy cloning.............
Xen Networking
Xen Networking
Domain0 Network Interfaces
Interface Name
When xend starts, the network script network-bridge brings up the virtual bridge interface, xenbr0.
By default, the real physical interface eth0 is changed to the name peth0, connecting to this bridge interface.
Domain0's loopback device veth0 is also brought up, its name is changed to eth0, and its backendvirtual interface vif0.0 is connected to the bridge interface.
The pair of Domain0's virtual interface eth0 and vif0.0 are connected in a loopback fashion.
Bridging Configuration Example
Bridging is the default network architecture that Xen establishes for guest domains. In the Xendconfiguration file /etc/xen/xend-config.sxp, the default directives related to the virtual network are listed below.
################################
(network-script network-bridge)
(vif-script vif-bridge)
###############################
network-script
The network script network-bridge is in the directory /etc/xen/scripts. It sets up the networking environment and uses the bridge-utils tool to set up the software bridge xenbr0.
vif-script
The vif script vif-bridge is also in the same directory as the network script. It sets up the backend vif for the guest domain when a guest domain boots up.
Example of the directive related to the virtual network setup in a guest configuration file.
vif = ['mac=00:16:3e:45:e7:12, bridge=xenbr0']
When the guest domain is booting up, its virtual interface is assigned a user-specified MAC address and is connected to the bridge xenbr0. This directive specifies that the guest domain has one virtual network interface inside that domain, and its backend vif will be attached to the bridge xenbr0.
Domain0 Network Interfaces
eth0
Frontend network interface for driver domain with ID 0 (as in Domain0)
lo
Loopback interface for Domain0
peth0
Physical network interface
sit0
Proxy interface for tunneling from IPv6 over IPv4
veth1~veth4
4 unused frontend network interfaces for Domain0
vif0.0
Backend network interface for Domain0
vif0.1~veth0.4
The corresponding unused backend network interface for Domain0
vif1.0
Backend network interface for guest domain with ID 1
xenbr0
Bridge network interface
When the physical network interface receives the packets, it sends them all directly to the bridge interface xenbr0. The software bridge determines which domain's backend interface to forward those packets to by the packets' MAC addresses. So, peth0 does not need to have an IP, only a MAC address. The physical interface's original IP has been imparted to eth0—the driver domain's virtual frontend interface. xenbr0 directs the packets either to eth0 or vif1.0 by their MAC addresses 00:11:25:F6:15:22 or 00:16:3e:45:e7:12. The guest domain's corresponding frontend virtualinterface eth0 is installed inside the guest domain. From the DriverDomain's view, the eth0 in guest domain is vif1.0. Figure 10.5 shows a virtual device view of bridge mode.
Domain0 Network Interfaces
Interface Name
When xend starts, the network script network-bridge brings up the virtual bridge interface, xenbr0.
By default, the real physical interface eth0 is changed to the name peth0, connecting to this bridge interface.
Domain0's loopback device veth0 is also brought up, its name is changed to eth0, and its backendvirtual interface vif0.0 is connected to the bridge interface.
The pair of Domain0's virtual interface eth0 and vif0.0 are connected in a loopback fashion.
Bridging Configuration Example
Bridging is the default network architecture that Xen establishes for guest domains. In the Xendconfiguration file /etc/xen/xend-config.sxp, the default directives related to the virtual network are listed below.
################################
(network-script network-bridge)
(vif-script vif-bridge)
###############################
network-script
The network script network-bridge is in the directory /etc/xen/scripts. It sets up the networking environment and uses the bridge-utils tool to set up the software bridge xenbr0.
vif-script
The vif script vif-bridge is also in the same directory as the network script. It sets up the backend vif for the guest domain when a guest domain boots up.
Example of the directive related to the virtual network setup in a guest configuration file.
vif = ['mac=00:16:3e:45:e7:12, bridge=xenbr0']
When the guest domain is booting up, its virtual interface is assigned a user-specified MAC address and is connected to the bridge xenbr0. This directive specifies that the guest domain has one virtual network interface inside that domain, and its backend vif will be attached to the bridge xenbr0.
Domain0 Network Interfaces
eth0
Frontend network interface for driver domain with ID 0 (as in Domain0)
lo
Loopback interface for Domain0
peth0
Physical network interface
sit0
Proxy interface for tunneling from IPv6 over IPv4
veth1~veth4
4 unused frontend network interfaces for Domain0
vif0.0
Backend network interface for Domain0
vif0.1~veth0.4
The corresponding unused backend network interface for Domain0
vif1.0
Backend network interface for guest domain with ID 1
xenbr0
Bridge network interface
When the physical network interface receives the packets, it sends them all directly to the bridge interface xenbr0. The software bridge determines which domain's backend interface to forward those packets to by the packets' MAC addresses. So, peth0 does not need to have an IP, only a MAC address. The physical interface's original IP has been imparted to eth0—the driver domain's virtual frontend interface. xenbr0 directs the packets either to eth0 or vif1.0 by their MAC addresses 00:11:25:F6:15:22 or 00:16:3e:45:e7:12. The guest domain's corresponding frontend virtualinterface eth0 is installed inside the guest domain. From the DriverDomain's view, the eth0 in guest domain is vif1.0. Figure 10.5 shows a virtual device view of bridge mode.
RHEL and pciback aka hiding pci card from Xen DOM0
Xen PCI Pass thru
I just recently spent more hours than I care to think about getting a NIC in Xen Dom0 hidden and passed to a DomU
via pciback in RHEL .
Lesson number 1: pciback or pciback.hide is now a module. Putting it on GRUB’s kernel line is no longer sufficien
t.
Lesson number 2: If you NIC module does not load until late in the boot process either use another one or put it
in your initrd. Davicom cards are a good example of this. Use an Intel.
Lesson number 3: Much of the information that you find online about what to put in your /etc/modprobe.config inco
rrect.
So now that we’ve covered all of that here is what you need to do to use pciback in RHEL5 .
Step 1. Put the following and only the following in your /etc/modprobe.conf:
options pciback hide=(01:06.0)
The numbers that you see there are found by running lspci |grep ethernet (or whatever you want to hide such as vg
a, usb, etc).
[root@virtual-host xen]# lspci |grep -i ethernet
01:02.0 Ethernet controller: Davicom Semiconductor, Inc. 21×4x DEC-Tulip compatible 10/100 Ethernet (rev 31)
01:06.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
[root@virtual-host xen]#
Now you need to create a new initrd image. Before doing so make a backup copy of the one that you are currently using. Then create a new initrd so that the pciback module is loaded early on.
mkinitrd -f –preload=pciback /boot/initrd-$(uname -r).img $(uname -r)
This will place the new initrd into your boot directory and overwrite the old one.
Moving on to the /etc/xen directory we have a little work do here. In the domU config file make two entries like the following:
pci = [ "01:06.0"]
vif = [ '' ]
Now open /etc/xen/xend-pci-permissive.sxp and make an entry like the following:
(unconstrained_dev_ids
#(’0123:4567:89AB:CDEF’)
(’8086:100e’) ##Everything but this entry is already in here for an example.
)
You get the 8086:100e number from running lspci -n:
You get the 8086:100e number from running lspci -n:
[root@virtual-host xen]# lspci -n
00:00.0 0600: 8086:254c (rev 01)
00:00.1 ff00: 8086:2541 (rev 01)
00:1d.0 0c03: 8086:2482 (rev 02)
00:1d.1 0c03: 8086:2484 (rev 02)
00:1e.0 0604: 8086:244e (rev 42)
00:1f.0 0601: 8086:2480 (rev 02)
00:1f.1 0101: 8086:248b (rev 02)
00:1f.3 0c05: 8086:2483 (rev 02)
01:02.0 0200: 1282:9102 (rev 31)
01:04.0 0300: 1002:4752 (rev 27)
01:06.0 0200: 8086:100e (rev 02)
As you can see those number match up with the 01:06.0 number that we used in modprobe.conf and the domU config file.
Now if all has gone well you should see that your domU has direct access to the pci card and that dom0 no longer attempts to use it. This can be confirmed by grep’ing dmesg:
[root@virtual-host xen]# dmesg |grep pciback
pciback 0000:01:06.0: seizing device
pciback 0000:01:06.0: enabling permissive mode configuration space accesses!
pciback 0000:01:06.0: permissive mode is potentially unsafe!
pciback: vpci: 0000:01:06.0: assign to virtual slot 0
pciback: vpci: 0000:01:06.0: assign to virtual slot 0
[root@virtual-host xen]#
There you have the results of several hours of reading and trial and error. Don’t forget that if you install a new xen kernel you will again have to make a new initrd.
One way around having to create a new initrd is to create a file named pciback under /etc/sysconfig/mkinitrd. Put an entry into the pciback file that reads PREMODS=”$PREMODS pciback”. That should automatically install the pciback module when your new kernel creates it’s new mkinitrd.
Hope this helps.
I just recently spent more hours than I care to think about getting a NIC in Xen Dom0 hidden and passed to a DomU
via pciback in RHEL .
Lesson number 1: pciback or pciback.hide is now a module. Putting it on GRUB’s kernel line is no longer sufficien
t.
Lesson number 2: If you NIC module does not load until late in the boot process either use another one or put it
in your initrd. Davicom cards are a good example of this. Use an Intel.
Lesson number 3: Much of the information that you find online about what to put in your /etc/modprobe.config inco
rrect.
So now that we’ve covered all of that here is what you need to do to use pciback in RHEL5 .
Step 1. Put the following and only the following in your /etc/modprobe.conf:
options pciback hide=(01:06.0)
The numbers that you see there are found by running lspci |grep ethernet (or whatever you want to hide such as vg
a, usb, etc).
[root@virtual-host xen]# lspci |grep -i ethernet
01:02.0 Ethernet controller: Davicom Semiconductor, Inc. 21×4x DEC-Tulip compatible 10/100 Ethernet (rev 31)
01:06.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
[root@virtual-host xen]#
Now you need to create a new initrd image. Before doing so make a backup copy of the one that you are currently using. Then create a new initrd so that the pciback module is loaded early on.
mkinitrd -f –preload=pciback /boot/initrd-$(uname -r).img $(uname -r)
This will place the new initrd into your boot directory and overwrite the old one.
Moving on to the /etc/xen directory we have a little work do here. In the domU config file make two entries like the following:
pci = [ "01:06.0"]
vif = [ '' ]
Now open /etc/xen/xend-pci-permissive.sxp and make an entry like the following:
(unconstrained_dev_ids
#(’0123:4567:89AB:CDEF’)
(’8086:100e’) ##Everything but this entry is already in here for an example.
)
You get the 8086:100e number from running lspci -n:
You get the 8086:100e number from running lspci -n:
[root@virtual-host xen]# lspci -n
00:00.0 0600: 8086:254c (rev 01)
00:00.1 ff00: 8086:2541 (rev 01)
00:1d.0 0c03: 8086:2482 (rev 02)
00:1d.1 0c03: 8086:2484 (rev 02)
00:1e.0 0604: 8086:244e (rev 42)
00:1f.0 0601: 8086:2480 (rev 02)
00:1f.1 0101: 8086:248b (rev 02)
00:1f.3 0c05: 8086:2483 (rev 02)
01:02.0 0200: 1282:9102 (rev 31)
01:04.0 0300: 1002:4752 (rev 27)
01:06.0 0200: 8086:100e (rev 02)
As you can see those number match up with the 01:06.0 number that we used in modprobe.conf and the domU config file.
Now if all has gone well you should see that your domU has direct access to the pci card and that dom0 no longer attempts to use it. This can be confirmed by grep’ing dmesg:
[root@virtual-host xen]# dmesg |grep pciback
pciback 0000:01:06.0: seizing device
pciback 0000:01:06.0: enabling permissive mode configuration space accesses!
pciback 0000:01:06.0: permissive mode is potentially unsafe!
pciback: vpci: 0000:01:06.0: assign to virtual slot 0
pciback: vpci: 0000:01:06.0: assign to virtual slot 0
[root@virtual-host xen]#
There you have the results of several hours of reading and trial and error. Don’t forget that if you install a new xen kernel you will again have to make a new initrd.
One way around having to create a new initrd is to create a file named pciback under /etc/sysconfig/mkinitrd. Put an entry into the pciback file that reads PREMODS=”$PREMODS pciback”. That should automatically install the pciback module when your new kernel creates it’s new mkinitrd.
Hope this helps.
Installing Xen
Installing Xen on Red Hat Based Distribution
yum install xen kernel-xen
yum install virt-manager libvirt libvirt-python libvirt-python python-virtinst
yum install xen kernel-xen
yum install virt-manager libvirt libvirt-python libvirt-python python-virtinst
Xen VM Snapshots
Creating Snapshots of Xen images
A virtual machine snapshot is a great feature, freezing the current state of a virtual machine. Unfortunately, op
en source Xen doesn't offer support for snapshots -- but Linux does. Since open source Xen always uses Linux as i
ts privileged domain, you can use Linux commands to create snapshots.
Byte-by-byte snapshot
One way of making snapshots in Xen is by using Linux dd after saving the current state of a virtual machine. This
would involve the following steps:
1. Use the xm save command to disable the current state of a virtual machine and write it to a disk file. This
would write the machine state only to a file, not the current state that is used in the Xen disk files or partit
ions. To do this for a domain with the name linux01, use xm save linux01 linux01.sav. Take note that this command
stops the virtual machine.
2. Now dump the current state of the disk image files to a backup file usingdd. The following example would do
this for LVM logical volumes used by Xen:
dd if=/dev/xenvols/linux01_root of=/data/xen_linux01_root.img
3. Restart the virtual machine using the xm restore command.
The major disadvantage of this solution is time. The dd command makes a byte-by-byte copy of the virtual machine
disk file and that can take an incredibly long time. Therefore, this option may not be very practical.
The LVM method
In Linux, the Logical Volume Manager (LVM) can also be used for creating a snapshot, one that takes significantly
less time than the previous disk file method. This method implies that your virtual machine uses an LVM logical
volume as its storage back-end, as opposed to using a virtual disk file. For this logical volume, you next need t
o create a snapshot. This snapshot is a kind of backup that contains metadata and blocks that have changed from t
he moment that you took the snapshot only. The trick is that when you use dd to make a copy of the snapshot via t
he metadata, you'll always make a snapshot of the original blocks on the original volume without the need to de-activate the original volume as well. By working this way, you can reduce the time it takes to create a snapshot of the virtual machine drastically. The procedure is as follows:
1. Use the xm save command to save the current state of the virtual machine and write it to a disk file:
xm save linux01 linux01.sav
2. Assuming that you already have an LVM logical volume that is used as the storage back-end for your virtual machine, use the following command to make a snapshot of this volume. A good guideline is to use 10% of the allocated disk space in the original logical volume as the size to use for the snapshot volume:
lvcreate -s -L 1G -n linux01-snap /dev/xenvols/linux01
3. Since you've now saved the state of your virtual machine in the LVM snapshot, you can restart the virtual machine, reducing the down time of the virtual machine dramatically as compared to the method sketched above:
xm restore linux01-sav
4. Use dd to create the snapshot of the virtual machine and write it to an image file. This will take longer since by using the snapshot you will copy all the disk blocks that are allocated by the virtual machine:
dd if=/dev/xenvols/linux01-snap of=/data/xen01.img
5. Don't forget to remove the snapshot in the last step of this procedure. This is important because a snapshot that stays around will eventually fill up completely and when that happens the snapshot will be disabled. The problem with this is that it will prevent you from remounting the original volume as well, so don't forget to apply this last step:
lvremove /dev/xenvols/linux01-snap
While no Linux distribution offers a solution in the open source Xen stack to create a virtual machine snapshot as of yet, you've read how you can do it anyway by using standard Linux tools such as LVM and dd.
A virtual machine snapshot is a great feature, freezing the current state of a virtual machine. Unfortunately, op
en source Xen doesn't offer support for snapshots -- but Linux does. Since open source Xen always uses Linux as i
ts privileged domain, you can use Linux commands to create snapshots.
Byte-by-byte snapshot
One way of making snapshots in Xen is by using Linux dd after saving the current state of a virtual machine. This
would involve the following steps:
1. Use the xm save command to disable the current state of a virtual machine and write it to a disk file. This
would write the machine state only to a file, not the current state that is used in the Xen disk files or partit
ions. To do this for a domain with the name linux01, use xm save linux01 linux01.sav. Take note that this command
stops the virtual machine.
2. Now dump the current state of the disk image files to a backup file usingdd. The following example would do
this for LVM logical volumes used by Xen:
dd if=/dev/xenvols/linux01_root of=/data/xen_linux01_root.img
3. Restart the virtual machine using the xm restore command.
The major disadvantage of this solution is time. The dd command makes a byte-by-byte copy of the virtual machine
disk file and that can take an incredibly long time. Therefore, this option may not be very practical.
The LVM method
In Linux, the Logical Volume Manager (LVM) can also be used for creating a snapshot, one that takes significantly
less time than the previous disk file method. This method implies that your virtual machine uses an LVM logical
volume as its storage back-end, as opposed to using a virtual disk file. For this logical volume, you next need t
o create a snapshot. This snapshot is a kind of backup that contains metadata and blocks that have changed from t
he moment that you took the snapshot only. The trick is that when you use dd to make a copy of the snapshot via t
he metadata, you'll always make a snapshot of the original blocks on the original volume without the need to de-activate the original volume as well. By working this way, you can reduce the time it takes to create a snapshot of the virtual machine drastically. The procedure is as follows:
1. Use the xm save command to save the current state of the virtual machine and write it to a disk file:
xm save linux01 linux01.sav
2. Assuming that you already have an LVM logical volume that is used as the storage back-end for your virtual machine, use the following command to make a snapshot of this volume. A good guideline is to use 10% of the allocated disk space in the original logical volume as the size to use for the snapshot volume:
lvcreate -s -L 1G -n linux01-snap /dev/xenvols/linux01
3. Since you've now saved the state of your virtual machine in the LVM snapshot, you can restart the virtual machine, reducing the down time of the virtual machine dramatically as compared to the method sketched above:
xm restore linux01-sav
4. Use dd to create the snapshot of the virtual machine and write it to an image file. This will take longer since by using the snapshot you will copy all the disk blocks that are allocated by the virtual machine:
dd if=/dev/xenvols/linux01-snap of=/data/xen01.img
5. Don't forget to remove the snapshot in the last step of this procedure. This is important because a snapshot that stays around will eventually fill up completely and when that happens the snapshot will be disabled. The problem with this is that it will prevent you from remounting the original volume as well, so don't forget to apply this last step:
lvremove /dev/xenvols/linux01-snap
While no Linux distribution offers a solution in the open source Xen stack to create a virtual machine snapshot as of yet, you've read how you can do it anyway by using standard Linux tools such as LVM and dd.
Subscribe to:
Posts (Atom)