Как специалисты Citrix восстанавливали нам удаленную VM

xe vdi-list
xe vdi-list  name-label=Actual_term
vhd-util scan -c -f -p -m VHD-* -l VG_XenStorage-uuid
vhd-util scan -c -f -p -m VHD-* -l VG_XenStorage-uuid | grep uuid
tailf /var/log/SMlog 

OpenSSL certificate generation script  - как ни крути, полезная штука! Честно украдено у freeRADIUS.
#!/bin/ksh
SSL=/usr/local/openssl

export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH}
export LD_LIBRARY_PATH=${SSL}/lib

# needed if you need to start from scratch otherwise the CA.pl -newca command doesn't copy the
new
# private key into the CA directories
rm -rf demoCA

echo "*********************************************************************************"
echo "Creating self-signed private key and certificate"
echo "When prompted override the default value for the Common Name field"
echo "*********************************************************************************"
echo

# Generate a new self-signed certificate.
# After invocation, newreq.pem will contain a private key and certificate
# newreq.pem will be used in the next step
openssl req -new -x509 -keyout newreq.pem -out newreq.pem -days 730 \
 -passin pass:whatever -passout pass:whatever

echo "*********************************************************************************"
echo "Creating a new CA hierarchy (used later by the "ca" command) with the certificate"
echo "and private key created in the last step"
echo "*********************************************************************************"
echo

echo "newreq.pem" | CA.pl -newca >/dev/null

echo "*********************************************************************************"
echo "Creating ROOT CA"
echo "*********************************************************************************"
echo

# Create a PKCS#12 file, using the previously created CA certificate/key
# The certificate in demoCA/cacert.pem is the same as in newreq.pem. Instead of
# using "-in demoCA/cacert.pem" we could have used "-in newreq.pem" and then omitted
# the "-inkey newreq.pem" because newreq.pem contains both the private key and certificate
openssl pkcs12 -export -in demoCA/cacert.pem -inkey newreq.pem -out root.p12 -cacerts \
 -passin pass:whatever -passout pass:whatever

# parse the PKCS#12 file just created and produce a PEM format certificate and key in root.pem
openssl pkcs12 -in root.p12 -out root.pem -passin pass:whatever -passout pass:whatever

# Convert root certificate from PEM format to DER format
openssl x509 -inform PEM -outform DER -in root.pem -out root.der

echo "*********************************************************************************"
echo "Creating client private key and certificate"
echo "When prompted enter the client name in the Common Name field. This is the same"
echo " used as the Username in FreeRADIUS"
echo "*********************************************************************************"
echo

# Request a new PKCS#10 certificate.
# First, newreq.pem will be overwritten with the new certificate request
openssl req -new -keyout newreq.pem -out newreq.pem -days 730 \
 -passin pass:whatever -passout pass:whatever

# Sign the certificate request. The policy is defined in the openssl.cnf file.
# The request generated in the previous step is specified with the -infiles option and
# the output is in newcert.pem
# The -extensions option is necessary to add the OID for the extended key for client
authentication
openssl ca -policy policy_anything -out newcert.pem -passin pass:whatever \
 -key whatever -extensions xpclient_ext -extfile xpextensions \
 -infiles newreq.pem

# Create a PKCS#12 file from the new certificate and its private key found in newreq.pem
# and place in file cert-clt.p12

openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out cert-clt.p12 -clcerts \

-passin pass:whatever -passout pass:whatever

# parse the PKCS#12 file just created and produce a PEM format certificate and key in cert-clt.pem

openssl pkcs12 -in cert-clt.p12 -out cert-clt.pem -passin pass:whatever -passout pass:whatever

# Convert certificate from PEM format to DER format

openssl x509 -inform PEM -outform DER -in cert-clt.pem -out cert-clt.der

echo "*********************************************************************************"

echo "Creating server private key and certificate"

echo "When prompted enter the server name in the Common Name field."

echo "*********************************************************************************"

echo

# Request a new PKCS#10 certificate.

# First, newreq.pem will be overwritten with the new certificate request

openssl req -new -keyout newreq.pem -out newreq.pem -days 730 \

-passin pass:whatever -passout pass:whatever

# Sign the certificate request. The policy is defined in the openssl.cnf file.

# The request generated in the previous step is specified with the -infiles option and

# the output is in newcert.pem

# The -extensions option is necessary to add the OID for the extended key for server authentication

openssl ca -policy policy_anything -out newcert.pem -passin pass:whatever -key whatever \

-extensions xpserver_ext -extfile xpextensions -infiles newreq.pem

# Create a PKCS#12 file from the new certificate and its private key found in newreq.pem

# and place in file cert-srv.p12

openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out cert-srv.p12 -clcerts \

-passin pass:whatever -passout pass:whatever

# parse the PKCS#12 file just created and produce a PEM format certificate and key in cert-srv.pem

openssl pkcs12 -in cert-srv.p12 -out cert-srv.pem -passin pass:whatever -passout pass:whatever

# Convert certificate from PEM format to DER format

openssl x509 -inform PEM -outform DER -in cert-srv.pem -out cert-srv.der

#clean up

rm newcert.pem newreq.pem

10. OpenSSL extensions file

[ xpclient_ext]

extendedKeyUsage = 1.3.6.1.5.5.7.3.2

[ xpserver_ext ]

extendedKeyUsage = 1.3.6.1.5.5.7.3.1

Проброс USB в XenServer 6.2 (USB Passthrough)

Проброс USB из XenServer 6.2 в виртуальную машину

В XenServer 6.2 пробросить USB порт в виртуальную машину нельзя. Можно пробросить целиком контроллер USB, а вместе с ним в "виртуалку" попадут и все порты связанные с этим контроллером. По такому же принципу можно пробросить практически любое устройство из хостовой системы. Как правило, на сервере от 2 USB контроллеров. Узнать это можно командой хостовой системе:

[root@xen ~]# lspci | grep USB
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)

Нас интересуют идентификаторы контроллеров 00:1a.0 и 00:1d.0 именно их мы и будем использовать в дальнейшем. Наверняка, угадать к какому контроллеру подключено устройство будет сложно. Для этого есть команда lsusb из пакета usbutils, но в XenServer этот пакет не установлен. Можно попытаться использовать dmesg. Или данные из файла /proc/bus/usb/devices:

cat /proc/bus/usb/devices

Например информация о флешке Transcend в этом файле выглядит таким образом:

T:  Bus=02 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 11 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=8564 ProdID=1000 Rev=11.00
S:  Manufacturer=JetFlash
S:  Product=Mass Storage Device
S:  SerialNumber=643SX46T1R2IPSGQ
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us

Видно, что используется Bus=02, значит контроллер будет 00:1d.0
Это отражено в описании самого контроллера:

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 2
B:  Alloc=  0/800 us ( 0%), #Int=  1, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 2.06
S:  Manufacturer=Linux 2.6.32.43-0.4.1.xs1.8.0.835.170778xen ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:1d.0         <------------------------------------<------------------------<---------
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

Далее необходимо узнать UUID ВМ, в которую будет проводиться проброс.

Например так:

[root@xen ~]# xe vm-list name-label=test
uuid ( RO)           : cd9c4655-dc8a-c086-103c-c1716293449d
     name-label ( RW): test
    power-state ( RO): running

Зная идентификатор контроллера в консоли XenServer нужно выполнить команду:

[root@xen ~]# xe vm-param-set other-config:pci=0/000:00:1d.0 uuid=cd9c4655-dc8a-c086-103c-c1716293449d

Где 0/000: - обязательная часть, далее идет сам идентификатор контроллера.
Проверить правильность настроек можно командой:

xe vm-param-list uuid=cd9c4655-dc8a-c086-103c-c1716293449d | grep other-config

Должно присутствовать: pci: 0/000:00:1d.0

После перезапуска ВМ, в диспетчере задач, в случае если установлен Windows, появится хостовый USB контроллер с подключенным к нему устройством.

Для того чтобы отключить проброс контроллера, в консоли XenServer необходимо выполнить команду:

xe vm-param-remove param-name=other-config param-key=pci uuid=cd9c4655-dc8a-c086-103c-c1716293449ds

Украдено с http://wiki.autosys.tk/Citrix.%D0%9F%D1%80%D0%BE%D0%B1%D1%80%D0%BE%D1%81-USB-%D0%B2-XenServer-6-2-USB-Passthrough.ashx

Xenserver + Debian wheezy install

Чтобы добавить темплэйт Debian Wheezy в ксен нужно выполнить такой скрипт:

https://gist.github.com/hingstarne/5320400

#!/bin/bash
# Script to install a debian wheezy template on xcp 1.1 and above, or
# Citrix (TM) Xenserver 5.6 and above.
# Copyright (C) 2012 Arne-Kristian Hingst - All Rights Reserved
# Permission to copy and modify is granted under the eupl license
# http://ec.europa.eu/idabc/servlets/Docbb6d.pdf?id=31979
# Last revised 04/04/2013
#

# Add your favourite mirror here
MIRROR=http://mirror.yandex.ru/debian/

# No need to edit something below
SQUEEZE=$(xe template-list name-label=Debian\ Squeeze\ 6.0\ \(64-bit\) --minimal)
if [[ -z $SQUEEZE ]] ; then
  SQUEEZE=$(xe template-list name-label=Debian\ Squeeze\ 6.0\ \(64-bit\)\ \(experimental\) --minimal)
if [[ -z $SQUEEZE ]] ; then
  echo "Cant find Squeeze 64bit template, is this on 5.6 or above?"
exit 1
fi
fi
NEWUUID=$(xe vm-clone uuid=$SQUEEZE new-name-label="Debian Wheezy 7.0 (64-bit)")
xe template-param-set uuid=$NEWUUID other-config:install-methods=http,ftp,nfs other-config:default_template=true
xe template-param-set uuid=$NEWUUID other-config:install-methods=http other-config:debian-release=wheezy
xe vm-param-set uuid=$NEWUUID other-config-install-repository=$MIRROR

Себе на заметку

Asterisk 1.8 + chan_sccp 4.1/chan_sccp41_RC1 < Asterisk 1.6 + chan_sccp_3.1.3

внезапно 4.0/4.1 стал  вызывать странные рестарты астериска.


Пофиксил:

для 7942 стабильно заработало с прошшивкой SCCP42.8-5-4S
а 7965 перестал валить Атериск  с прошивкой SCCP45.9-0-2SR1S

copy vhd from nfs/cifs

Итак задача: скопировать в локальный стораж VHD с сетевого хранилища.
Можно сделать это через импорт в XenCenter, но тут есть свой ньюанс - надо приаттачить сетевой диск к машине и трафик будет идти по схеме NAS - машина с XenCenter - XenServer, что соответственно негативно скажется на скорости. Еще можно приаттачить NFS-VHD storage, тут уже всё ок, но не всегда работает. ( кстати: чтобы добавить туда свой VHD-образ надо создать новый диск, а затем заменить его своим образом )

А можно пойти другим путем.
Нам нужна будет утилитка vhd2xen от акрониса ( можно взять тут )
качаем: wget http://download.acronis.com/vhd2xen.i686
даем права на исполнение: chmod +x vhd2xen.i686
ну и запускаем установку: ./vhd2xen.i686
далее отвечаем на несложные вопросы
и вуаля - всё готово для нашего действа.
Установилась наша утилитка вот сюда: /usr/lib/Acronis/VHD2XEN/.

Далее нам надо смонтировать наш сетевой диск
mount -t nfs ip:/path /mnt/storage
или mount -t cifs //share /mnt/storage -o username=**** password=****

Все готово к импорту, можно начинать:




[root@WWiskas disk_c]# /usr/lib/Acronis/VHD2XEN/vhd2xen.sh /mnt/storage/path/to/vhd.vhd

Copyright (C) Acronis, 2000-2008.
All rights reserved.

VHD to XEN converter

Select the storage repository to import VHD file to:
1. uuid - XenServer... (unknown)
2. uuid - Local... (local)
3. uuid - DVD... (unknown)
4. uuid - Removable... (unknown)
2

A VHD file must be decompressed before importing to an internal
storage. You need about 98Gb free space to save the raw
uncompressed image and write permissions in the location where
the original VHD file is stored.

Enter XEN name for imported disk:
ИМЯ_ДИСКА_для_XEN

Importing may take a long time depending on vhd size.


спустя некоторое время:
Conversion done, importing to XEN...

и еще немного погодя:
Import successfully finished!

в общем по гигабиту у меня копирование диска в 100ГБ ( 40 занято ) заняло около 4х часов. ( ну вернее скорость копирования в среднем была 20-35 Мб/сек )


Всё, нам остается только ожидать счастливого окончания операции.
А, и еще - нам потребуются права на запись в папку с VHD, иначе импорт закончится крашем.

но этот способ тоже не идеален - сначала оно делает RAW обрах, который равен по объему всему месту, а не только данным, и затем копирует его.

Xenserver 6.1 raid monitoring

Нормально Dell Openmanage не встает на XenServer 6.1, так что приходится извращаться.


сначала добавим репозитарии делла:

wget -q -O - http://linux.dell.com/repo/software/bootstrap.cgi | bash

в конце увидим:
Installing repository rpm: http://linux.dell.com/repo/community/content/el5-i386/noarch/dell-community-repository-1-11.2.el5.noarch.rpm

Done!

далее второй реп:

wget -q -O - http://linux.dell.com/repo/hardware/bootstrap.cgi | bash

затем установим необходимые для мониторинга пакеты:

yum -y install srvadmin-base
yum -y install srvadmin-storageservices

после этого было бы неплохо перезагрузиться, но можно и потом.

после этого можно смотреть статус с помощью команды 

omreport storage vdisk

если у вас не работает, то вероятнее всего надо создать симлинк: 

ln -s /opt/dell/srvadmin/sbin/omreport /usr/local/sbin/omreport

скрипт для удаления всех .rpm в директории

for i in $(ls *.rpm)
do
DIR=`echo $i | sed 's/\.deb//g'`
rpm -e $i
echo $DIR
echo "============================================="
done

так же можно и устанавливать.

а можно и к дебиану приспособить - поменять маску, и заменить rpm на dpkg

Автостарт для XenServer

http://kopacb.github.com/XenHelp/

все очень просто - добавляем в крон с нужной периодичностью, время на запуск машин можно не учитывать - второй раз скрипт не запустится.

Далее добавляем тег Autostart для машин, которые нужно стартовать.

Ну и  радуемся жизни (:

тут всякие полезности для гзена

http://ogris.de/howtos/xen-pci-passthrough.html - пробрасываем pci устройство

Тут буду собирать уязвимости роутеров

D-LINK многие модели отдадут вам пароли по ссылочке http://ip/save_configuration.cgi
D-LINK 615 может отдаться через  http://IP_роутера/tools_admin.htm?page=tools_admin&admin_password1=admin2&admin_password2=admin2&hostname=DIR-615


ну и можно попробовать тут: http://routerpwn.com

Софтварный рейд на ксен 6.*

скопипижжено с: http://kryuchkov62.blogspot.ru/2012/10/software-raid1-citrix-xenserver-602_4.html



Алгоритм работы:


- создать на втором диске файловую систему, аналогичную XenServer
- запустить на нем softraid
- перенести сам XenServer на второй диск
- загрузиться со второго диска, т.е. уже с программного RAID
- подключить к новоиспеченному RAID массиву первый диск


Системный блок:


Материнская плата - Foxconn G31MXP


Процессор - Intel Pentium E5300 @ 2600 МГц


Оперативная память - 4096 Кб (2 x 2048 DDR2-SDRAM )


Дисковая подсистема - 2 Seagate ST3250813AS (250 Гб)






*Примечание: если у вас аналогичная материнская плата, то решение проблемы с определением 3 гигабайт оперативной памяти ****тут.


Устанавливаем XenServer 6.0.2. При установке я выбрал первый диск.

Установили. Переходим в консоль или подключаемся по SSH. Я использую Putty.


Расклад:


sda – диск с XenServer
sdb – пустой диск



Задача: подготовить второй диск к созданию массива (создать на нём копию таблицы разделов первого диска)

Смотрим таблицу разделов на sda


# gdisk -l /dev/sda






Проверяем, что таблица разделов на sdb пуста:


# gdisk -l /dev/sdb




С помощью gdisk вручную создаем на sdb таблицу разделов:


# gdisk /dev/sdb




*Примечание: с помощью клавиши "n" создаём три раздела (номер раздела, стартовые и конечные сектора должны полностью совпадать, тип раздела при этом необходимо указывать fd00 (Linux RAID)). После завершения нажимаем "w" для записи изменений и выходим из gdisk. Все команды можно узнать набрав "?".

Таблица должна быть идентична диску sda.

*Примечание: рекомендую настраивать по SSH, т.к. там легко копируюся любые элементы.






Проверяем наши диски:

# gdisk -l /dev/sda

# gdisk -l /dev/sdb

и если никаких различий (кроме типа раздела) - продолжаем


Создадим устройства MD на втором диске:


1# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 missing


2# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdb2 missing


3# mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sdb3 missing



Создадим и перенесем Local Storage в RAID:

1# pvcreate /dev/md2
2# vgextend VG_[tab] /dev/md2
3# pvmove /dev/sda3 /dev/md2

Примечание: [tab] - означает нажать клавишу Tab, чтобы дописать ваше значение.


Удалим старый storage с первого диска:


1# vgreduce VG_[tab] /dev/sda3
2# pvremove /dev/sda3




Создадим файловую систему на RAID:


# mkfs.ext3 /dev/md0



И смонтируем ее:


# mount /dev/md0 /mnt




Скопируем сам XenServer в RAID:


1# cd /


2# cp -axv . /mnt




Редактируем fstab для монтирования root раздела с RAID:

# nano /mnt/etc/fstab



вместо строки:

LABEL=root-xxx / ext3 defaults 1 1


должна получиться строка:


/dev/md0 / ext3 defaults 1 1






Создаем загрузочный образ для RAID:

1# mkdir /mnt/root/initrd-raid
2# mkinitrd -v --fstab=/mnt/etc/fstab /mnt/root/initrd-raid/initrd-`uname -r`-raid.img `uname -r`
3# cd /mnt/root/initrd-raid
4# zcat initrd-`uname -r`-raid.img | cpio -i




Редактируем файл init:

# nano init



и добавляем после

raidautorun /dev/md0


две строки:

# raidautorun /dev/md1
# raidautorun /dev/md2


Копируем новый диск в каталог /mnt/boot

1# find . -print | cpio -o -Hnewc | gzip -c > /mnt/boot/initrd-`uname -r`-raid.img
2# rm /mnt/boot/initrd-2.6-xen.img
rm: remove symbolic link `/mnt/boot/initrd-2.6-xen.img’? y
3# ln -s initrd-`uname -r`-raid.img /mnt/boot/initrd-2.6-xen.img


Редактируем загрузочное меню:

# nano /mnt/boot/extlinux.conf

Требуется заменить все упоминания:

root=LABEL=root-xxx


на:

root=/dev/md0


Устанавливаем MBR для GPT на втором диске:

1# cat /mnt/usr/share/syslinux/gptmbr.bin > /dev/sdb
2# cd /mnt
3# extlinux --raid -i boot/


Корректно размонтируем второй диск:

1# cd
2# umount /dev/md0
3# sync


Проверяем, что флаг загрузочного диска корректно установлен на обоих дисках:

1# sgdisk /dev/sda --attributes=1:set:2

2# sgdisk /dev/sdb --attributes=1:set:2


Перезагружаем сервер. И ЗАГРУЖАЕМСЯ СО ВТОРОГО ДИСКА, то есть уже с RAID. Во избежание путаницы, возможность загрузки с первого диска лучше вообще отключить в BIOS.

reboot




После загрузки с RAID нам надо настроить файловую систему первого диска для работы в RAID:


# gdisk /dev/sda


*Примечание: с помощью клавиши t меняем типы для всех трех разделов на fd00 (Linux RAID). После завершения нажимаем w для записи изменений и выходим из gdisk. Все команды можно узнать набрав "?".


Теперь можно включать первый диск в RAID:

1# mdadm -a /dev/md0 /dev/sda1

mdadm: added /dev/sda1

2# mdadm -a /dev/md1 /dev/sda2

mdadm: added /dev/sda2

3# mdadm -a /dev/md2 /dev/sda3

mdadm: added /dev/sda3


Процесс синхронизации (ребилда) массива можно смотреть с помощью команды:

# watch cat /proc/mdstat


После завершения ребилда вносим последние изменения в настройки:

# mdadm --detail --scan >> /etc/mdadm.conf


И перезагружаемся. Для корректной загрузки в случае отказа одного из дисков, требуется настроить в BIOS загрузку системы с обоих жестких дисков по-очереди.

Необходимые команды для работы с RAID можно найти здесь.





2# vgextend VG_[tab] /dev/md2
3# pvmove /dev/sda3 /dev/md2


1# vgreduce VG_[tab] /dev/sda3
2# pvremove /dev/sda3

у меня эти команды не выполнялись, поэтому я сам называл VolumeGroup по типу VG1 VG2 и т.д. и в конце сделал руками сторадж. Поэтому НАСТОЯТЕЛЬНО рекомендую делать это на чистой мшине, до того как вы начнете заселять её виртуалками. Ну и соответственно НЕ рекомендую делть это на живой машине.

XEN хранилище ручками ( для 6.* работает так же хорошо )

First there’s a default template in XenServer 5.6 which needs to be removed from the storage:

# xe vbd-list
uuid ( RO)             : f5c9f545-2019-7299-be87-fc7ef00be1e2
          vm-uuid ( RO): e2ad0921-dea8-5a1a-77e8-d3257fdcf48d
    vm-name-label ( RO): XenServer Transfer VM 5.6.0-31124p
         vdi-uuid ( RO): c3a8d327-2036-4ce2-9946-f0522f7572f4
            empty ( RO): false
           device ( RO): 
# xe template-uninstall template-uuid=e2ad0921-dea8-5a1a-77e8-d3257fdcf48d
The following items are about to be destroyed
VM : e2ad0921-dea8-5a1a-77e8-d3257fdcf48d (XenServer Transfer VM 5.6.0-31124p)
VDI: c3a8d327-2036-4ce2-9946-f0522f7572f4 (XenServer Transfer VM system disk) 
Type 'yes' to continue
yes
All objects destroyed
If you really needed that template, you don’t have it anymore. You’ll have to figure out how to get it back. I’m not sure what the purpose of that is for. It is by default installed on all new XenServer 5.6 images, so you should be able to export it from a fresh install and re-import it to fix, but I’m not going to offer instructions on how to do that, and haven’t tested it.

Next, find the uuid of the Local Storage SR:

# xe sr-list name-label="Local storage"
uuid ( RO)                : dacfea90-263e-0811-ab88-22f01b89b1b4
          name-label ( RW): Local storage
    name-description ( RW): 
                host ( RO): vmhost.example.com
                type ( RO): lvm
        content-type ( RO): user
Then find the PBD that is attached to that:

]# xe pbd-list sr-uuid=dacfea90-263e-0811-ab88-22f01b89b1b4
uuid ( RO)                  : daabdf71-641c-900b-3451-bd5c70675fab
             host-uuid ( RO): 23d8a9a0-a317-47a5-a1e6-858ab120b57b
               sr-uuid ( RO): dacfea90-263e-0811-ab88-22f01b89b1b4
         device-config (MRO): device: /dev/disk/by-id/scsi-36001c230bd1017000e4f2ee6554b21c8-part3
    currently-attached ( RO): true
Then unplug the PBD:

# xe pbd-unplug uuid=daabdf71-641c-900b-3451-bd5c70675fab
Now destroy the SR:

# xe sr-destroy uuid=dacfea90-263e-0811-ab88-22f01b89b1b4
Now you can create the SR. I’ve been using servers that have /dev/sda, so the storage partition is /dev/sda3. If you’re doing this on a SATA system (ick) you might have to use /dev/hda3 here, or on an HP probably /dev/cciss/c0d0p3. If you have FibreChannel or iSCSI-attached disk on a SAN you’re on your own to figure out what your block device is.

# xe sr-create content-type=user type=ext device-config:device=/dev/sda3 shared=false name-label="Local storage"
76ec3072-ae85-cd38-e363-34cf6b63d520
This command will take some time to return as it creates the SR.

You now probably want to tune the reserved space down on the ext3 partition to make more of it available. The filesystem reserves 5% of the storage to make block allocation and defragmentation more efficient, but you probably want to manage that yourself (set monitoring alarms at 95% and migrate VMs off if the storage gets above 95%).

The block device to tune is not /dev/sda3, but you can find it from df -k:

# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              4128448   3214896    703840  83% /
none                    384512         0    384512   0% /dev/shm
/opt/xensource/packages/iso/XenCenter.iso
                         44410     44410         0 100% /var/xen/xc-install
/dev/mapper/XSLocalEXT--76ec3072--ae85--cd38--e363--34cf6b63d520-76ec3072--ae85--cd38--e363--34cf6b63d520
                     279556112    191652 265163836   1% /var/run/sr-mount/76ec3072-ae85-cd38-e363-34cf6b63d520
Use tune2fs against that really ugly block device name to set the reserve to 0%:

# tune2fs -m 0 /dev/mapper/XSLocalEXT--76ec3072--ae85--cd38--e363--34cf6b63d520-76ec3072--ae85--cd38--e363--34cf6b63d520
tune2fs 1.39 (29-May-2006)
Setting reserved blocks percentage to 0% (0 blocks)
You should now be able to see the new “Local storage” device in XenCenter and can set it as the default storage location for new VMs. You will also see VHDs associated with your VMs showing up in the /var/run/sr-mount/[...etc...] directory.