This tutorial is for installing XenWebManager on an XCP host but should work just as well for installing XenWebManager on any Redhat based hosts (CentOS/Fedora).
It's best to install XenWebManager on another machine or even a VM for security reasons but I could see installing it on a host for simplicity's sake.
You will need to be root in order to follow the instructions below.
1. Download and install the packages
cd ~ wget http://iweb.dl.sourceforge.net/project/xenwebmanager/xenwebmanager_beta_full.tar.gz tar -xzvpf xenwebmanager_beta_full.tar.gz cd xenwebmanager/tools bash install_rh.sh
2. Run XenWebManager
Run xenwebmanager service. The install script above already configures it to auto-start on XCP host bootup. To turn auto-start off - chkconfig xenwebmanager off...
service xenwebmanager start
3. Allow port 8080 through the firewall
iptables -A RH-Firewall-1-INPUT -p tcp --dport 8080 -j ACCEPT service iptables save service iptables restart
4. Connect to the XCP Host
Open a web browser and connect to your XCP Host's IP address on port 8080. My host's IP is 192.168.1.147 so I would type http://192.168.1.147:8080/ into my web browser Address bar.
5. Configure xenwebmanager to manage your XCP pool
Once you've connected to XenWebManager you need to add your server. Click on the "Add Server" button in the top left hand corner and enter your XCP poolmaster's Hostname, Username and Password.
Possibly the easiest way to get a graphical management interface running on XCP is to use the Xen Web Manager Appliance. The appliance is a complete Virtual Machine with XenWebManager installed and ready to run.
These commands should be typed into your XCP cloud host.
1. Download and import the appliance
This is a very long URL from Sourceforge but it does work if you copy and paste it.
wget http://downloads.sourceforge.net/project/xenwebmanager/appliances/xenwebmanager.xva.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fxenwebmanager%2F&ts=1365405701&use_mirror=superb-dca3 gunzip xenwebmanager.xva.gz xe vm-import filename=xenwebmanager.xva
2. Verify the appliance and start it
[root@testcloud1 ~]# xe vm-list name-label=xenwebmanager uuid ( RO) : 70f63ce4-b775-22c6-a556-a03a7bea6220 name-label ( RW): xenwebmanager power-state ( RO): halted [root@testcloud1 ~]# xe vm-start name-label=xenwebmanager
3. Get the IP address of the appliance
Opening a console on the VM is done differently on XCP 1.0/1.1 then it is on XCP 1.5/1.6. Copy and paste these instructions.
On XCP 1.0/1.1
DOMID=$(xe vm-list name-label=xenwebmanager params=dom-id) /usr/lib/xen/bin/xenconsole $DOMID
On XCP 1.5/1.6
xe console vm=xenwebmanager
Log with the following credentials
Username: root Password: xenwebmanager
Get appliance IP address
Once we've logged into our Appliance get the IP address using the ifconfig command.
[root@xenwebmanager ~]# ifconfig eth0 Link encap:Ethernet HWaddr B2:5C:69:8C:22:1E inet addr:192.168.1.147 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::b05c:69ff:fe8c:221e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2377 errors:0 dropped:0 overruns:0 frame:0 TX packets:42 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:273930 (267.5 KiB) TX bytes:7146 (6.9 KiB)
My appliance IP address is 192.168.1.147. Exit the console by pressing the Control Key and the right square bracket - control ]
4. Connect to the appliance
Open a web browser and connect to your appliance IP address on port 8080. My appliance IP is 192.168.1.147 so I would type http://192.168.1.147:8080/ into my web browser Address bar.
5. Configure xenwebmanager to manage your XCP pool
Once you've connected to your xenwebmanager appliance you need to add your server. Click on the "Add Server" button in the top left hand corner and enter your XCP poolmaster's Hostname, Username and Password.
Getting VMs to boot up automatically when an XCP host powers up is fairly easy but not entirely logical. With the old Xen we'd just copy the config file into /etc/xen/auto but XCP/Xenserver has no such directory. Using XCP/Xenserver you have to tell the pool to turn on auto_poweron and you also have to set it for the VM you want to autoboot as well.
1. Get the Pool UUID number
Use xe pool-list to get the UUID of the pool. We see the pool UUID is d47b4251-60bc-aa36-c572-c425fdc1b897.
[root@testcloud1 ~]# xe pool-list uuid ( RO) : d47b4251-60bc-aa36-c572-c425fdc1b897 name-label ( RW): name-description ( RW): master ( RO): c76a1ba7-8cdd-45a7-8399-38f242355a43 default-SR ( RW): 735f9d8e-64eb-71b7-9fd4-47c342c7c9e4
2. Set auto_poweron for the pool
To set the value of a pool parameter we'll use the xe pool-param-set. Use the pool UUID from the previous step here. We'll be setting the auto_poweron item of the other-config map parameter to true.
xe pool-param-set uuid=d47b4251-60bc-aa36-c572-c425fdc1b897 other-config:auto_poweron=true
3. Get the VM UUID number
Use xe vm-list to get the UUID of the VM you'd like to autoboot. We see the VM UUID is d2e81fdd-e2cd-b0db-8b0e-e280611eb446.
[root@testcloud1 ~]# xe vm-list uuid ( RO) : d2e81fdd-e2cd-b0db-8b0e-e280611eb446 name-label ( RW): CentOS6 power-state ( RO): halted
4. Set auto_poweron for the VM
To set the value of a VM parameter we'll use xe vm-param-set. Use the VM UUID from the previous step here. We'll be setting the auto_poweron item of the other-config map parameter to true.
xe vm-param-set uuid=d2e81fdd-e2cd-b0db-8b0e-e280611eb446 other-config:auto_poweron=true
Test your work by rebooting the host.
Xenserver hotfixes are released as patches that need to be applied with patch-pool-apply. Although technically this could work with XCP as long as you got the correct Xenserver patch it's better to apply patches the "new" way using Yum and the default xcp repository.
Any minor software updates to Xen Cloud Platform will be released into the XCP Yum repository at downloads.xen.org. XCP 1.6 comes with a ready made Yum repository file at /etc/yum.repos.d/xcp.repo although by default the repository is disabled.
To apply updates use the yum update command you have to enable the repo and tell rpm not to gpg check the packages. Hopefully the latter behavior will change in the future.
yum --enablerepo xcp --nogpgcheck update
If you'd like to enable the repo and turn gpg checking off by default so future updates are easier then change the enabled=0 line to enabled=1. Also add a line to the /etc/yum.repos.d/xcp.repo file to turn gpgchecking off for this ONE repository.
[xcp] name=XCP 1.6 Updates baseurl=http://downloads.xen.org/XCP/repo/xcp-1.6.10/ enabled=1 gpgcheck=0
I don't know if I recommend enabling by default as I like to do my updates manually. I really have issues with turning gpg checking off but currently the packages are distributed without a gpg signature so if you have it turned on the update will fail. Our only choice is to turn it off.
Using my tutorials it's fairly easy to install Linux... as long as I've written a tutorial for it. It's also fairly easy to start and stop your VMs... if you understand the XE command or you've installed xenapi-admin-tools. If you're the type of person who appreciates a good graphical interface you can run Citrix' own Xencenter software which does a great job. However it's a Windows application so if you (like me) don't run Windows then you can't easily run Xencenter. There is a free GUI based management tool named XVP that allows you to do simple administration of your VMs like starting and stopping them. It also handles the messiness of tunneling through network and firewalls to provide a VNC console on your local desktop which can be very handy if you want to do a graphical install.
There are two ways to getting XVP to run on your xapi cloud:
- Create a CentOS VM and install/configure all of the XVP packages
- Download the XVP Appliance VM image and run it
We will choose the latter as it's a great deal easier to do.
Creating a download location large enough for the xvpappliance VM image
You have an issue with just downloading the XVP Appliance and importing it into XCP as the image is too big for the stock XCP Operating System drive so we will remedy this by creating an ext3 formatted Logical Volume to store the image in temporarily.
Get the name of your Storage Repository named "Local Storage". This would be the default SR created on install.
[root@testcloud1]# xe sr-list uuid ( RO) : 735f9d8e-64eb-71b7-9fd4-47c342c7c9e4 name-label ( RW): Local storage name-description ( RW): host ( RO): testcloud1 type ( RO): lvm content-type ( RO): user
Now get the name of the LVM Volume Group associated with it.
[root@testcloud1]# vgs VG #PV #LV #SN Attr VSize VFree VG_XenStorage-735f9d8e-64eb-71b7-9fd4-47c342c7c9e4 1 7 0 wz--n- 181.91G 115.84G
We can see the Volume Group is named VG_XenStorage-<UUID of Local Storage SR>. We can also see that there is 115.84 GB of free space on it which is perfect. Now we will create a new Logical Volume 10 GB in size named TESTLV in the Volume Group named VG_XenStorage-735f9d8e-64eb-71b7-9fd4-47c342c7c9e4. NOTE: Your Volume Group will be named something different. Due to the long lines a break (\) has been inserted.
[root@testcloud1 share]# lvcreate -L 10G -n TESTLV \
VG_XenStorage-735f9d8e-64eb-71b7-9fd4-47c342c7c9e4 Logical volume "TESTLV" created
Format the new Logical Volume as ext3. Due to the long lines a break (\) has been inserted.
[root@testcloud1 ]# mkfs -t ext3 \
/dev/VG_XenStorage-735f9d8e-64eb-71b7-9fd4-47c342c7c9e4/TESTLV mke2fs 1.39 (29-May-2006) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 1310720 inodes, 2621440 blocks 131072 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=2684354560 80 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 32 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.
Now make a mountpoint (/media/TESTLV) and mount the new Logical Volume. After being mounted we use the df command to check for free space. Due to the long lines a break (\) has been inserted.
[root@testcloud1]# mkdir /media/TESTLV [root@testcloud1]# mount /dev/VG_XenStorage-735f9d8e-64eb-71b7-9fd4-47c342c7c9e4/TESTLV \
/media/TESTLV/ [root@testcloud1]# df -h /media/TESTLV Filesystem Size Used Avail Use% Mounted on /dev/mapper/VG_XenStorage--735f9d8e--64eb--71b7--9fd4--47c342c7c9e4-TESTLV 9.9G 151M 9.2G 2% /media/TESTLV
Now that you have a place to put the VM image we can download the zipped image to your new formatted Logical Volume. Go to http://www.xvpsource.org/?topic=releases&page=download and copy and paste the xvpappliance link. At the time of this writing it was http://xvpmirror.webguyz.net/xvpappliance-1.15.0-1.zip.
[root@testcloud1]# cd /media/TESTLV/ [root@testcloud1 TESTLV]# wget http://xvpmirror.webguyz.net/xvpappliance-1.15.0-1.zip
Once xvpappliance is downloaded unzip it and import the image into XCP. This may take a while as the xva formatted image file is 1.9 GB extracted.
[root@testcloud1 TESTLV]# unzip xvpappliance-1.15.0-1.zip Archive: xvpappliance-1.15.0-1.zip inflating: xvpappliance-1.15.0-1.xva [root@testcloud1 TESTLV]# xe vm-import filename=xvpappliance-1.15.0-1.xva
Verify the xe vm-import worked by listing the xvpappliance VM.
[root@testcloud1 TESTLV]# xe vm-list name-label=xvpappliance[root@testcloud1 TESTLV]# cd .. [root@testcloud1 media]# umount /media/TESTLV [root@testcloud1 media]# lvremove /dev/VG_XenStorage-735f9d8e-64eb-71b7-9fd4-47c342c7c9e4/TESTLV Do you really want to remove active logical volume TESTLV? [y/n]: y Logical volume "TESTLV" successfully removed [root@testcloud1 TESTLV]# cd .. [root@testcloud1 media]# umount /media/TESTLV [root@testcloud1 media]# lvremove /dev/VG_XenStorage-735f9d8e-64eb-71b7-9fd4-47c342c7c9e4/TESTLV Do you really want to remove active logical volume TESTLV? [y/n]: y Logical volume "TESTLV" successfully removed [root@testcloud1 TESTLV]# cd .. [root@testcloud1 media]# umount /media/TESTLV [root@testcloud1 media]# lvremove /dev/VG_XenStorage-735f9d8e-64eb-71b7-9fd4-47c342c7c9e4/TESTLV Do you really want to remove active logical volume TESTLV? [y/n]: y Logical volume "TESTLV" successfully removed uuid ( RO) : 2d3fb5e7-4ea7-69f4-e652-1895995ca4b6 name-label ( RW): xvpappliance power-state ( RO): halted
Turn off VNC so our commandline console works on the xvpappliance VM and boot it up. We will need the xvpappliance UUID for this.
[root@testcloud1 TESTLV]# xe vm-list name-label=xvpappliance uuid ( RO) : 2d3fb5e7-4ea7-69f4-e652-1895995ca4b6 name-label ( RW): xvpappliance power-state ( RO): halted
[root@testcloud1 TESTLV]# xe vm-param-set uuid=2d3fb5e7-4ea7-69f4-e652-1895995ca4b6 \
other-config:disable_pv_vnc=1 [root@testcloud1 TESTLV]# xe vm-start name-label=xvpappliance
Connect to the console and configure the xvpappliance
Press control ] to exit the console.
Remove the temporary Logical Volume (if don't have a need for it).
[root@testcloud1 TESTLV]# cd .. [root@testcloud1 media]# umount /media/TESTLV [root@testcloud1 media]# lvremove /dev/VG_XenStorage-735f9d8e-64eb-71b7-9fd4-47c342c7c9e4/TESTLV Do you really want to remove active logical volume TESTLV? [y/n]: y Logical volume "TESTLV" successfully removed
To use XVP just point your web browser to the IP address you specified above. In my case it was 192.168.1.15. It will ask you to accept the unsigned certificate and log in. Login with the username and password you entered above as well.
I've been wanting to revive some equipment from the garage. I have some old dual Xeon machines that I picked up from a contract a while back. I also bought some "Designed for Google" dual CPU Xeon boards that I haven't used for anything. I've been using one of these boards in a server that's been running non-stop for probably 6 years and it's always been rock solid. Now that I'm documenting Xen Cloud Platform as part of the Xenapi Admin Project I wanted to put together a multi-host cloud using Xen Cloud Platform and it's best if your hosts match thus the renewed interest in getting this machine up and going.
However, there's been a few problems.
- The CPUs from the Google boards don't work in the ASUS boards due to different FSB
- I only had three CPUs for four sockets
- I was missing a heat sink too
- They use DDR2 ECC Registered ram which isn't common
- Intel should have their teeth kicked in for designing three (count them) different heat sink/fan designs for one socket.
- I needed backplates for two CPUs, the ones that arrived had no spring clips
- My replacement heatsink came with one spring clip
- Only one retailer had spring clips
So I started by ordering a new copper heatsink because at the time I thought I could use the CPUs out of the Google boards. The heatsink arrived with one spring clip, I needed two. After I realized that I couldn't use the CPUs from the Google boards I then ordered a new CPU. Armed with a new CPU and heatsink I installed them only to find out that I needed a spring clip to keep the heat sink ON the CPU. Only one retailer even carried it so I ordered one. Now if only I had a power supply strong enough to run the board. Back to the garage again.
In the garage I found a brand new computer case which surprisingly also had a brand new Pentium D motherboard in it. More booty from contracts. I wasn't concerned with the Pentium D but it had a Sparkle Power 600 watt power supply... Score!!
As of today I now have a dual Xeon server in a 4u case to match it's duplicate. I need to score some ddr2 ecc registered ram as it only has 2 GB in it. That crap is expensive so I went to Ebay and I have bids on a couple batches of 8GB. We'll see if I get them.
The board was too big for the case too. I had to get out the hacksaw and cut away at the drive cage so it would fit. and drill new holes in the side of the case to mount a fan for more direct airflow.
This board is a little interesting. It has...
- Two Ultra-SCSI 320 channels
- A zero channel raid slot
- 64 bit, 133 mhz PCI-X slots
- 8x PCI Express slot
- 133 MB/sec IDE
- 8 Dimm slots
- 2 CPU sockets
The Xeons don't have VT in them so I'll only be able to paravirtualize but that's all I ever do anyway. However Xeon 7030s have VT and will fit the board if anyone has any they want to get rid of cheap.
To develop the Xenapi Admin Tools for the Xenapi Admin Project I install git on the XCP host so I can write tools and keep the github project up to date as well. Following is how to get git working on XCP 1.6. To develop tools I just mount my XCP hosts / partitoin on my development machine via sshfs so I can edit tools remotely. When I'm satisfied with the tools I commit them using git commit -a followed by git push to send the changes to the xenapi-admin-tools github repository.
Add the EPEL repo, install git then disable the repo
We add the EPEL repo (which is necessary), install git and then disable the repo immediately to keep other system specific packages from updating.
rpm -ivh http://mirror.itc.virginia.edu/fedora-epel/5/i386/epel-release-5-4.noarch.rpm yum install git sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel.repo
To use git to clone our Xenapi Admin Tools repository you'll need to set a few configuration items. Change "Your User Name" to your actual username you want to authenticate with. Change "Your Email Address" to your own email address.
git config --global user.name "Your User Name"
git config --global user.email "Your Email Address" git config --global credential.helper cache git config --global credential.helper 'cache --timeout 3600'
Clone the xenapi-admin-tools github and add it to your PATH (OPTIONAL)
Cloning the github repo is pretty easy. Below we clone the Xenapi Admin Projects tools repo which will create a /root/xenapi-admin-tools directory. The tools are in xenapi-admin-tools/releases/<version number> but to use them we'll need to add that directory to our system $PATH variable.
cd /root git clone https://github.com/Xenapi-Admin-Project/xenapi-admin-tools.git echo 'PATH="$PATH:/root/xenapi-admin-tools/releases/4.1"' >> ~/.bashrc
The Xenapi Admin Tools are starting to become so useful that I don't like having XCP hosts without them. Currently you can go to http://xenapi-admin-project.github.com/xenapi-admin-tools/ and download the archive onto your host, extract it and then copy the tools to your PATH. This however, is a lot of work since they get updated often. In the coming weeks (months?) I'll be finishing the Yum repo for Xenapi Admin Tools so the XCP package manager can keep them up to date. Until I get that accomplished however it may be easier to just install git and clone the github repository. Every time you want to get updates you'd just cd into the xenapi-admin-tools directory and run git pull.
With that in mind we have to add the EPEL repository where git is housed in order to use Yum to install it.
Install the EPEL repo
yum install git
Disable EPEL repo
The EPEL repository is enabled by default so we didn't have to do anything special to install git. However, you may not want it enabled all the time because packages that EPEL hosts may replace XCP specific packages and mess up your system
sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel.repo
To use git to clone our Xenapi Admin Tools repository you'll need to set a few configuration items.
git config --global user.name "Your User Name"
git config --global user.email "Your Email Address" git config --global credential.helper cache git config --global credential.helper 'cache --timeout 3600'
Now that git is configured you'll want to clone the repository.
git clone https://github.com/Xenapi-Admin-Project/xenapi-admin-tools.git
This will create a xenapi-admin-tools directory in /root. The tools are in xenapi-admin-tools/releases/<version number> so you'll probably want to copy them to somewhere in the system PATH (or make a symbolic link). I personally use a /root/bin directory to hold them.
On occasion you may want to have access to a VM's Virtual Disk Image from the Control Domain (or another VM). An example of this would be access files in a VM disk that due to corruption will no longer boot. An XCP local Storage Repository is created from an LVM Volume Group. Each Virtual Disk Image represents one Logical Volume. However, mounting the Logical Volume directly isn't possible because there's VHD (Virtual Hard Drive) container inside the Logical Volume. Inside the VHD is the real VM disk's partitions. The hierarchy goes something like this Control Domain Volume Group -> Control Domain Logical Volume -> VHD Container -> VM disk -> VM disk physical Volume -> VM Disk Volume Group -> VM Disk Logical Volume -> VM Disk filesystem. You can see there's quite a few layers here but mounting the VM's disk filesystem IS possible. Here's how.
Since the Control Domain is really a VM itself (privileged VM) we can create a Virtual Block Device using the VM's Virtual Disk Image. From there we use kpartx to map the partitions to Control Domain device nodes.
1. Finding VDI UUID number
[root@testcloud1 ~]# xe vbd-list uuid ( RO) : b68a332b-4155-f1c4-b224-18fb465dc8e4 vm-uuid ( RO): fec94868-0449-3616-39b9-08c3b27dab70 vm-name-label ( RO): Fedora17 vdi-uuid ( RO): 199619f0-e483-4618-bbd4-bdc9c524bde1 empty ( RO): false device ( RO):
2. Finding the Control Domain UUID number
[root@testcloud1 ~]# xe vm-list is-control-domain=true uuid ( RO) : 2dfc3f33-4afa-47dd-8af6-21877326f8e4 name-label ( RW): Control domain on host: testcloud1 power-state ( RO): running
3. Creating a virtual block device for the VDI on our Control Domain. This returns the VBD UUID.
[root@testcloud1 ~]# xe vbd-create device=autodetect vm-uuid=2dfc3f33-4afa-47dd-8af6-21877326f8e4 vdi-uuid=199619f0-e483-4618-bbd4-bdc9c524bde1 11740055-f8d4-3d84-1f90-fb1f4b646fd6
4. Plugging in the Virtual Block Device gives us a /dev/sm/backend/<sr-uuid>/<vdi-uuid> device which fdisk will list.
[root@testcloud1 ~]# xe vbd-plug uuid=11740055-f8d4-3d84-1f90-fb1f4b646fd6
5. Showing the VBD attached to the control domain AND to the Fedora17 VM
[root@testcloud1 ~]# xe vbd-list uuid ( RO) : b68a332b-4155-f1c4-b224-18fb465dc8e4 vm-uuid ( RO): fec94868-0449-3616-39b9-08c3b27dab70 vm-name-label ( RO): Fedora17 vdi-uuid ( RO): 199619f0-e483-4618-bbd4-bdc9c524bde1 empty ( RO): false device ( RO): uuid ( RO) : 11740055-f8d4-3d84-1f90-fb1f4b646fd6 vm-uuid ( RO): 2dfc3f33-4afa-47dd-8af6-21877326f8e4 vm-name-label ( RO): Control domain on host: testcloud1 vdi-uuid ( RO): 199619f0-e483-4618-bbd4-bdc9c524bde1 empty ( RO): false device ( RO): sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1
6. Showing the Device Node using ls and fdisk
[root@testcloud1 ~]# ls -l /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1 brw------- 1 root root 253, 0 Jan 12 00:52 /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1
[root@testcloud1 ~]# fdisk -l $(ls /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1) Disk /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1: 8589 MB, 8589934592 bytes 255 heads, 63 sectors/track, 1044 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bd * 1 980 7863296 83 Linux Partition 1 does not end on cylinder boundary. /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bd 980 1045 524288 82 Linux swap / Solaris [root@testcloud1 ~]# kpartx -a $(ls /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1) [root@testcloud1 ~]# ls /dev/mapper/ 199619f0-e483-4618-bbd4-bdc9c524bde1p1 199619f0-e483-4618-bbd4-bdc9c524bde1p2 control VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-MGT VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-VHD--199619f0--e483--4618--bbd4--bdc9c524bde1 VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-VHD--6c663b1b--d9c4--45bd--9071--3f6b4668d164
7. Use kpartx to create /dev/mapper entries for each partition.
[root@testcloud1 ~]# kpartx -a $(ls /dev/sm/backend/ec2eb4df-040c-2a75-1c9f-69b953ac9e8d/199619f0-e483-4618-bbd4-bdc9c524bde1)
8. kpartx creates /dev/mapper nodes
[root@testcloud1 ~]# ls /dev/mapper/ 199619f0-e483-4618-bbd4-bdc9c524bde1p1 199619f0-e483-4618-bbd4-bdc9c524bde1p2 control VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-MGT VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-VHD--199619f0--e483--4618--bbd4--bdc9c524bde1 VG_XenStorage--ec2eb4df--040c--2a75--1c9f--69b953ac9e8d-VHD--6c663b1b--d9c4--45bd--9071--3f6b4668d164
9. Mount the partitions
[root@testcloud1 ~]# mount /dev/mapper/199619f0-e483-4618-bbd4-bdc9c524bde1p1 /media/Fedora17-rootfs/
[root@testcloud1 ~]# ls /media/Fedora17-rootfs/ bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
Notes: Be careful with mounting VDI's from VMs on the Control Domain. Best practice is to make sure that the VDI is not accessible from the Control Domain AND the VM at the same time. Mounting to two locations at once is a great way of corrupting your disk by having two different Operating Systems writing to the disk at the same time.
Note: updated for XCP 1.5b/1.6
- Network boot
- Access to Internet
- Working DHCP server
- Working DNS name resolution
This tutorial was written in the spirit of my CentOS 6 virtual machine (64 bit) installation on Xen howto which was based on the CentOS 5 version of the same. In those tutorials I created a disk, downloaded a kernel, kickstart file plus a xen config file which installed CentOS using the kickstart file. This has proven very popular since you can't install a paravirtualized domain using an install disk. This has been a very nice installation howto because you don't have to download any install CD/DVDs and you could create VMs using nothing more than a commandline login. It's also very nice because it can be mirrored locally if you're doing a bunch of them just by rsyncing a CentOS mirror locally then downloading my files and editing them.
I've recently migrated a lot of my XEN systems to Xen Cloud Platform and it's a very different animal indeed. However, I still needed a system of creating CentOS Virtual Machines in that same manner. I didn't want to download a CentOS install DVD or need a graphical login to install the OS thus this tutorial was born.
It uses the very same CentOS 6 kickstart file from my site as the Xen tutorial. It also uses the very same CentOS 6 repositories on the Internet so in a lot aspects it IS the same tutorial crafted for XCP but will be a bit shorter.