Below are the steps that I followed to clone an RHEL5 guest running under vmware ESX-3.5 to Xen environment over the network. The method that I followed can be used to clone any virtual machine (except windows?) running under any virtualization product to any other virtualization product (Correct?). I agree that there are specific tools provided by vendors for p2v and v2v conversions, but they are limited to their virtualization product. Eg, Vmware tools may not be used to convert a virtual machine running under vmware to run on Xen/KVM and vice-versa.
Pre-requisites.
- Linux based LiveCD. (Which should have coreutils and nc - netcat - packages installed).
Below are the steps that I followed:
- Downloaded the LiveCD for Fedora 10 from here (You can use whatever Linux LiveCD you want.)
- Booted the rhel5 virtual machine already available in Vmware ESX from this ISO by attaching this ISO to the guest and selecting cdrom as the first boot device. (Consult the concerned documentation for more details)
- Created a new blank guest in Xen and assigned it a hard disk with the same size of vmware disk. I just created a fully virtualized guest using virt-manager and when it started the anaconda installation, aborted the installation and shutdown the guest. Now I have a guest with a blank image.
- Then started the blank guest under Xen from the Fedora LiveCD. (If not sure how to do it, please consult xen documentation).
Now we have both Vmware guest (will be called GuestA from now onwards) and a guest with blank image in Xen (will be called GuestB from now onwards) booted of the Fedora 10 Live CD.
- On both guests flush the iptables firewall.
# iptables -F
- Networking should be enabled automatically by the LiveCD. Make sure that networking is working as expected on both guests and they can ping each other.
- Run fdisk -l on both guests and identify how the hard disk has been detected. I had them detected as "/dev/sda" on both GuestA and GuestB.
- On GuestB, run the below command:
# nc -l 7000 | dd of=/dev/sda bs=16M
- On GuestA, run the below command.
# dd if=/dev/sda bs=16M | nc ip-of-GuestB 7000
Replace ip-of-GuestB with the actual ip of GuestB and replace /dev/sda with the actual block device in both commands. 7000 is the port number, you can use other unused ports as well.
The process of copying the hard disk image will take sometime depending upon the network bandwidth and the IO bandwidth availability of storage. Please be patient and restart GuestB once the process is over from the hard disk.
- Went to bed and had a good sleep. When I was up in the morning, I had the guest cloned successfully and started off the new guest.
Showing posts with label xen. Show all posts
Showing posts with label xen. Show all posts
Sunday, September 6, 2009
Monday, March 9, 2009
Network failure with xen/kvm while using round-robin bonding + bridging?
If anyone of you are facing complete network failure or unacceptable packet loss in guest communication while using RHEL5 for Virtualization using xen + bonding (only mode0/round robin) + briding, please refer redhat kbase to know how to solve or work around it. This can also be applicable for KVM virtualization in Fedora if public bridge is used for networking with bonding in mode0
Tuesday, February 10, 2009
How to configure kdump with xen in RHEL5?
Most poeple get confused when it comes to configuring kdump for dom0. Since there are two entries in grub.conf, one representing the hypervisor and the other representing the dom0 kernel, the confusion is while thinking where should one give the "crashkernel" parameter. Have seen some people who are not ready to do trial and error passing the "crashkernel" parameter to both hypervisor and kernel. If you are too lazy to do a trial and error, this blog may help you.
The crashkernel parameter need to be passed to the hypervisor.
Eg, (Taken from my test system)
title Red Hat Enterprise Linux Server (2.6.18-92.1.18.el5xen)
root (hd0,0)
kernel /xen.gz-2.6.18-92.1.18.el5 crashkernel=128M@16M
module /vmlinuz-2.6.18-92.1.18.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
module /initrd-2.6.18-92.1.18.el5xen.img
- Configure /etc/kdump.conf appropriately. The file is self descriptive.
- Run "service kdump propagate"
- Run "service kdump start"
The crashkernel parameter need to be passed to the hypervisor.
Eg, (Taken from my test system)
title Red Hat Enterprise Linux Server (2.6.18-92.1.18.el5xen)
root (hd0,0)
kernel /xen.gz-2.6.18-92.1.18.el5 crashkernel=128M@16M
module /vmlinuz-2.6.18-92.1.18.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
module /initrd-2.6.18-92.1.18.el5xen.img
- Configure /etc/kdump.conf appropriately. The file is self descriptive.
- Run "service kdump propagate"
- Run "service kdump start"
Thursday, November 20, 2008
Is it possible to resize the storage for a xen guest in RHEL5, If yes how?
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
OR
# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=5120 oflag=append
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.
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
OR
# dd if=/dev/zero of=/vm/images/guest.img bs=1M count=5120 oflag=append
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.
Monday, November 17, 2008
How to migrate guests using virsh commands?
Usually "xm migrate -l" is used to migrate a guest from one system to other system. There is no option in virt-manager to migrate a guest from one host to another. Libvirt based virsh command can be used to do this. The syntax of "virsh migrate" is a bit confusing to a lot of beginners. Details given below would help in solving those confusions.
- There are two systems - HostA and HostB. HostA is the source machine and HostB is the destination machine.
1 - If you are currently logged into HostA as root, below command can be used to migrate a guest to HostB.
# virsh migrate --live xen+ssh://HostB
Replace HostB with its ip or FQDN. You would be asked for the root password of HostB. Upon entering the right password for HostB, migration would happen successfully.
2 - If you are currently logged into a third system in the network which has "virsh" command available in it, the below command can be used to migrate a guest from HostA to HostB.
# virsh --connect xen+ssh://HostA migrate --live xen+ssh://HostB
Replace HostA and HostB with its ip addresses or FQDNs. You would be asked for the root password of HostA first, then the HostB. Upon entering the right password for both hosts, migration would happen successfully.
3 - If you are currently logged into HostB and want to migrate a guest from HostA to HostB, can this be done using virsh? Try it out yourself.
Libvirt connection over ssh (xen+ssh) is the the method used in the above example. Libvirt remote TLS connection can also be established using certificates. Since that needs a bit more deails to setup, that is apt for another doc.
- There are two systems - HostA and HostB. HostA is the source machine and HostB is the destination machine.
1 - If you are currently logged into HostA as root, below command can be used to migrate a guest to HostB.
# virsh migrate --live
Replace HostB with its ip or FQDN. You would be asked for the root password of HostB. Upon entering the right password for HostB, migration would happen successfully.
2 - If you are currently logged into a third system in the network which has "virsh" command available in it, the below command can be used to migrate a guest from HostA to HostB.
# virsh --connect xen+ssh://HostA migrate --live
Replace HostA and HostB with its ip addresses or FQDNs. You would be asked for the root password of HostA first, then the HostB. Upon entering the right password for both hosts, migration would happen successfully.
3 - If you are currently logged into HostB and want to migrate a guest from HostA to HostB, can this be done using virsh? Try it out yourself.
Libvirt connection over ssh (xen+ssh) is the the method used in the above example. Libvirt remote TLS connection can also be established using certificates. Since that needs a bit more deails to setup, that is apt for another doc.
Wednesday, October 29, 2008
I can't access the PV guest serial console via "xm console" or "virsh console" in RHEL5 xen. How can I fix it?
This would work out of the box in most cases, but in certain scenarios it may not work as expected. If someone hits such a situation, please make sure below things are done correctly.
1 - Edit /boot/grub/grub.conf of the guest and add "console=tty0 console=xvc0" to the kernel line, if you wanted the boot messages to appear on the serial console.
Eg, RHEL4 PV guest grub.conf would look like as below.
title Red Hat Enterprise Linux ES (2.6.9-78.ELxenU)
root (hd0,0)
kernel /boot/vmlinuz-2.6.9-78.ELxenU ro root=LABEL=/ console=tty0 console=xvc0
initrd /boot/initrd-2.6.9-78.ELxenU.img
2 - Add the below line to /etc/inittab under "Run gettys in standard run levels" if a login prompt is needed on serial console after system is booted.
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
3 - Add "xvc0" to /etc/securetty if root to log in need to be allowed from this console.
Make sure that the guest is rebooted after checking the abov three points.
1 - Edit /boot/grub/grub.conf of the guest and add "console=tty0 console=xvc0" to the kernel line, if you wanted the boot messages to appear on the serial console.
Eg, RHEL4 PV guest grub.conf would look like as below.
title Red Hat Enterprise Linux ES (2.6.9-78.ELxenU)
root (hd0,0)
kernel /boot/vmlinuz-2.6.9-78.ELxenU ro root=LABEL=/ console=tty0 console=xvc0
initrd /boot/initrd-2.6.9-78.ELxenU.img
2 - Add the below line to /etc/inittab under "Run gettys in standard run levels" if a login prompt is needed on serial console after system is booted.
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
3 - Add "xvc0" to /etc/securetty if root to log in need to be allowed from this console.
Make sure that the guest is rebooted after checking the abov three points.
Friday, October 17, 2008
How to install a fully virtualized guest using multiple cds which requires cdrom media change during installation?
RHEL3 and RHEL4 till U6 comes in multiple cds. With RHEL-5.2, a fully virtualized guest can be installed using these multiple cds. CD change is possible whenever requested by anaconda. Steps are similiare to the methods we follow in Vmware. Below are the steps.
- Start the installation of the Fully virtualized guest from the first CD, as usual from virt-manager.
- When anaconda requests to change the cd and insert 2nd cd, please do the following.
- On the virt-manager console click View -> Details -> Hardware -> Select "Disk hdc" (the one with the cdrom icon in the right side) -> Click "Disconnect" in the right side-> The button would change to "Connect". Click "Connect" -> Select the 2nd cd from the Brwose list and click OK -> Click "OK" in the disk change window from anaconda.
This should work fine and the installation would resume from the second cd. Follow the same steps for all cds till installation is finished. The same steps would work for windows guests as well if a media change is required.
Note: You may need to edit /etc/xen/guest configuration file and change,
boot = "d"
to
boot = "c"
to properly start the guest after the installation is finished.
- Start the installation of the Fully virtualized guest from the first CD, as usual from virt-manager.
- When anaconda requests to change the cd and insert 2nd cd, please do the following.
- On the virt-manager console click View -> Details -> Hardware -> Select "Disk hdc" (the one with the cdrom icon in the right side) -> Click "Disconnect" in the right side-> The button would change to "Connect". Click "Connect" -> Select the 2nd cd from the Brwose list and click OK -> Click "OK" in the disk change window from anaconda.
This should work fine and the installation would resume from the second cd. Follow the same steps for all cds till installation is finished. The same steps would work for windows guests as well if a media change is required.
Note: You may need to edit /etc/xen/
boot = "d"
to
boot = "c"
to properly start the guest after the installation is finished.
What is pci-passthrough and how to do it with xen in RHEL5?
The informations below are specific to RHEL5 and could be applied to fc6 and above.
Pci passthrough is used to exclusively export a pci device to a paravirtualized or fully virtualized guest rather than sharing that for guests and dom0. While doing this, the exported pci device wouldn't be available for dom0 and any other guests. Ex, NIC.
Paravirtualized guests: Pci passthrough should work on RHEL5 guests. It's not expected to work on rhel4 PV guests. PCI passthrough requires support in both dom0 (backend) and in the guest (front end). This front end support has not been implemented in RHEL4 PV kernel yet.
Fully Virtualized guest: Not supported. PCI passthrough to fully virtualized guests requires special hardware support. This is called VT-d on intel paltform and IOMMU on AMD platform. (AMD is yet to release such a hardware). Even if someone possesses this hardware, it requires support in xen code and the RHEL version of xen doesn't have this code.
Bottom line. PCI passthrough would work only if the guest is RHEL5 PV and fc6 and above guests. Below is details on how to configure this.
- Get the pci id of a pci device in dom0 by running "lspci".
- Hide the pci device from dom0. I added the below entry in my /etc/modprobe.conf to hide my Broadcom network card from dom0 which uses bnx2 driver and rebooted dom0. Change it to suite your requirement
install bnx2 /sbin/modprobe pciback ; /sbin/modprobe --first-time --ignore-install bnx2
options pciback hide=(0000:09:00.0) verbose_request=1
- Pass the deivce through by adding the below line in /etc/xen/ file.
pci = [ "0000:09:00.0" ]
Pci passthrough is used to exclusively export a pci device to a paravirtualized or fully virtualized guest rather than sharing that for guests and dom0. While doing this, the exported pci device wouldn't be available for dom0 and any other guests. Ex, NIC.
Paravirtualized guests: Pci passthrough should work on RHEL5 guests. It's not expected to work on rhel4 PV guests. PCI passthrough requires support in both dom0 (backend) and in the guest (front end). This front end support has not been implemented in RHEL4 PV kernel yet.
Fully Virtualized guest: Not supported. PCI passthrough to fully virtualized guests requires special hardware support. This is called VT-d on intel paltform and IOMMU on AMD platform. (AMD is yet to release such a hardware). Even if someone possesses this hardware, it requires support in xen code and the RHEL version of xen doesn't have this code.
Bottom line. PCI passthrough would work only if the guest is RHEL5 PV and fc6 and above guests. Below is details on how to configure this.
- Get the pci id of a pci device in dom0 by running "lspci".
- Hide the pci device from dom0. I added the below entry in my /etc/modprobe.conf to hide my Broadcom network card from dom0 which uses bnx2 driver and rebooted dom0. Change it to suite your requirement
install bnx2 /sbin/modprobe pciback ; /sbin/modprobe --first-time --ignore-install bnx2
options pciback hide=(0000:09:00.0) verbose_request=1
- Pass the deivce through by adding the below line in /etc/xen/
pci = [ "0000:09:00.0" ]
Tuesday, January 22, 2008
Bonding with xen
1 - Stop all guests. Reboot dom0 after running "chkconfig xend off" and "chkconfig xendomains off".
2 - Configure bond0 by enslaving eth0 and eth1 to it. I added the below two entries to /etc/modprobe.conf.
alias bond0 bonding
options bond0 mode=1,miimon=100
Content of /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
Content of /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
Content of /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=
NETMASK=
ONBOOT=yes
BOOTPROTO=static
USERCTL=no
Did "modprobe bond0" and "service network restart" after that.
3 - Edit /etc/xen/xend-config.sxp
Change
(network-script network-bridge)
To
(network-script 'network-bridge netdev=bond0')
4 - Start xend. "service xend start".
5 - chkconfig xend on.
6 - Create guest images as usual and bridge it to xenbr0.
2 - Configure bond0 by enslaving eth0 and eth1 to it. I added the below two entries to /etc/modprobe.conf.
alias bond0 bonding
options bond0 mode=1,miimon=100
Content of /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
Content of /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
Content of /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=
NETMASK=
ONBOOT=yes
BOOTPROTO=static
USERCTL=no
Did "modprobe bond0" and "service network restart" after that.
3 - Edit /etc/xen/xend-config.sxp
Change
(network-script network-bridge)
To
(network-script 'network-bridge netdev=bond0')
4 - Start xend. "service xend start".
5 - chkconfig xend on.
6 - Create guest images as usual and bridge it to xenbr0.
Subscribe to:
Posts (Atom)