Нам например нужно закинуть ISOшник прямо на XenServer

Нам например нужно закинуть ISOшник прямо на XenServer , чтобы виртуалка не тянула его чз сеть с шаринга, т.к. при этом , ну раз сеть, исошник может оторваться в самый ответственный момент установки. Для этого:

1. Создадим папку в Dom0
[root@xenserver1 ~]# mkdir -p /var/opt/xen/iso_import

2.Скопируем ISOшникв эту /var/opt/xen/iso_import через scp.
3.Создадим сторадж
[root@xenserver1 ~]# xe sr-create name-label=ISOs type=iso device-config:location=/var/opt/xen/iso_import device-config:legacy_mode=true content-type=iso
4. Ну и приаттачим его
[root@xenserver1 ~]# xe-mount-iso-sr /var/opt/xen/iso_import

Все, VM может грузиться с .iso
Кста, контролируйте свободное место в Dom0 командой df -h, а то он может и загнуться от Вашего хлама)

как создать ISCSI таргет на базе Линукса и заюзать в XenServer

Сегодня мы рассмотрим регламент создания ISCSI таргета на базе Линукса и его использования в XenServer.
Важное замечание! XenServer не должен быть модифицирован, ни добавлены программы в /ust/bin,ни модифицировано ядро. Стабильность работы Dom0 сильно страдает при его изменениях, проверено. Я как то установил X11 на Dom0 XenServer`а, это было круто, см. здесь. Но при этом не цеплялся сторонний ISCSI таргет инитиатором XenServer`а по разным причинам, в т.ч. и необъяснимым никак. Ну и кроме того, при ЛЮБОЙ модификации ПО Dom0 XenServer`а слетает его лицензия и потом не ставится, пока не восстановишь XenServer в исходное сосстояние переустановкой поверх. Хорошо, что это происходит с сохранением настроек.
Приступим.
1. Имеем например Centos 5.3 на сторонней машине. А можно и виртуальной. ПК имеет выход в инет, ДНС настроен правильно(/etc/resolv.conf)
2. обновляем базу пакетов
-bash-3.2#yum update
если ругани нет, прокси нет, то гуд. Если есть прокси, настраиваем yum на него. Как - см. тут
3. устанавливаем необходимые для сборки исходного кода компоненты
-bash-3.2#yum install kernel-devel openssl-devel gcc rpm-build
4. создадим место для исходников и перейдем туда
-bash-3.2#mkdir /usr/src/iscsitarget
-bash-3.2#cd /usr/src/iscsitarget
5.Скачиваем исходники
-bash-3.2#wget http://dfn.dl.sourceforge.net/sourceforge/iscsitarget/iscsitarget-0.4.15.tar.gz
6.Распаковываем архив
-bash-3.2#tar xvf iscsitarget-0.4.15.tar.gz
7.Переходим в каталог
-bash-3.2#cd iscsitarget-0.4.15
8. Компилируем и устанавливаем
-bash-3.2#make
-bash-3.2#make install
9.Все, переходим к настройке LUNов
Для начала создадим file-based ISCSI LUNы. Они медленнее, чем блочные устройства, но на блочное нужна либо отдельная партиция жесткого диска, либо динамический том LVM. Сделаем и

такие, но потом)
-bash-3.2#mkdir /home/iSCSI
-bash-3.2#dd if=/dev/zero of=/home/iSCSI/LUN0 bs=1024 count=400000
Вот, мы создали в своей домашней папке пустой файл размером примерно 400Мб. Это кстати, небыстро.
10. Настраиваем таргет. Создаем /etc/ietd.conf
-bash-3.2#nano /etc/ietd.conf

Target iqn.2009-09.com:baremetalstorage.disk2.sys1.xyz
Lun 0 Path=/home/iSCSI/LUN0,Type=fileio
Alias iDISK0

Прим: Слова iqn.2009-09.com:baremetalstorage.disk2.sys1.xyz мы придумали сами, но по строгому формату. Действуйте так-же, или читайте про именование таргетов.Ну а запись указывает как раз на наш созданный с нулями файл. Это будет наш таргет LUN.
11. Теперь нужно перестартовать сервис таргета, чтобы подцепился новый LUN
-bash-3.2#/etc/init.d/iscsi-target restart
12. Все, теперь можем из XenCenter создавать новый сторадж, выбираем вариант iSCSI, указываем IP-адрес, тычем Discovery. Нам покажуть таргеты, жмакаем discover luns, увидим наш LUN0, жмакаем его, нам предложуть его форматнуть. Не отказываемся)
13.Все, теперь можем из XenCenter на новом сторадже клепать диски, как душе угодно)
Ales.

Xen local SR, LVM, VHD

Текст пока альфа-версии. Поток разума)
Сперва вспомним матчасть:
как найти uuid ВМ по ее имени
xe vm-list name-label=

как получить параметры ВМ по ее uuid
xe vm-param-list uuid=

как найти все VBD, VDI для ВМ по ее имени
xe vbd-list vm-name-label=
получим свойство vdi-uuid для каждого из VBD

как найти LVM-группу, соответствующую SR:
VG Name = "VG_XenStorage-" + sr-uuid
vgdisplay -v VG Name - получим список LVM дисков
Free PE / Size 1309 / 5.11 GB - покажет сколько свободного места на SR.
Тут видим проблему, решение которой приведет нас в будущем к еще большим проблемам. Но пока мы этого не знаем)
Цифра отличается от точго что пишет XenCenter и от суммы всех в_дисков, т.е. происходит утечка места на SR, предположительно при создании/удалении

в_дисков.
как найти LVM том(диск) , соответствующий xen VDI диску:
1 вариант:
LV Name = "/dev/" + VG Name + "/VHD-" + vdi_uuid
LV Status = NOT available кстати не говорит от том, что этот диск не используется
2 вариант:
lvdisplay-v LV Name

получить список всех VDI для SR
xe vdi-list sr-uuid=2bc17aca-6728-11a7-91d2-9249a10d9a11|grep '^uuid ( RO)'
получить список всех LV для LVMG

но можно и проще. получаем список всех VDI для SR как есть, и сравниваем по именам со списком дисков для SR в XenCenter . Те VDI, которые остались не

именованы , являются лишними. Начинаем их убивать (выяснилось позднее: этот шаг приводит к невозможности назначить любой диск VDI на этом SR любой VM.

SR становится практически бесполезным и нечитаемым)

xe vdi-destroy uuid=c1f7b670-374c-44a8-85e2-814d9c50a9ec
но VHD может и не убиться, если он уже убит, тогда просто отцепляем его запись:
xe vdi-forget uuid=c1f7b670-374c-44a8-85e2-814d9c50a9ec
потом убиваем собсно LVD
[root@xenserver1 ~]# umount /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
umount: /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec: not mounted
[root@xenserver1 ~]# lvremove -d /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
обычно LVD успешно убивается и место высвобождается, типа так:
Do you really want to remove active logical volume "хххххххх"? [y/n]: y
Logical volume "хххххххх" successfully removed

но так может и не случиться, например получим ответ: Can't remove open logical volume "VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec"
это значит, что LVD держит какой-то процесс. смотрим, кто держит динамический диск:
lvdisplay /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
--- Logical volume ---
LV Name /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
VG Name VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11
LV UUID hrl6YB-wo8m-i90b-wunL-Kp6A-gGPo-W3Cd8y
LV Write Access read only
LV Status available
# open 1
LV Size 29.24 GB
Current LE 7486
Segments 5
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 251:5
ага, одна ссылка, надо узнать что за процесс
fuser /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
/dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec: 12202
видим что PID 12202 , кто это?
[root@xenserver1 ~]# ps ax|grep 12202
12202 ? SL 0:00 tapdisk /var/run/tap/tapctrlwrite3 /var/run/tap/tapctrlread3
а tapdisk это библиотека доступа к блочным устройствам самого xen`a, см. http://www.xen.org/files/summit_3/XenSummitBlockTalk.pdf
прибиваем процесс. при этом LVD удаляется сам, но место не высвобождается.
Вроде есть альтернатива , команда для LV , деактивирующая его: lvchange -an , не тестировал.
Свободное место на хранилище постоянно смотрим командой
vgdisplay -v VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11|more
Alloc PE / Size 42908 / 167.61 GB
Free PE / Size 14750 / 57.62 GB
пробуем перечитать хранилище командой xe sr-scan uuid=, место освободилось.
чтобы проверить, что используемое на хранилище место соответствует используемым VHD на SR, сравним в списка:
получить список всех VDI для SR
xe vdi-list sr-uuid=2bc17aca-6728-11a7-91d2-9249a10d9a11|grep '^uuid ( RO)'
из этого списка переносим в excel имя диска и его размер, суммируем размеры.
получить список всех LV для LVMG
vgdisplay -v VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11|more
или командой lvs, она лаконичнее.
в итоге
у нас получилось, что списки совпадают, но итоговый размер по списку меньше того, что занято на диске из вывода команды vgdisplay.
dmsetup info VG_XenStorage--2bc17aca--6728--11a7--91d2--9249a10d9a11-VHD--c1f7b670--374c--44a8--85e2--814d9c50a9ec
lvdisplay /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
после долгих мытарств и экспериментов, после которых нагнулись почти все диски на локальном SR выяснилось, что:
LV c названием "base copy" не являются лишними, несмотря на то, что на них не указывают записи xe VDI. Это основные части виртуальных дисков, которые

образуются при операциях Fast Clone, Snapshot. При этом VDI указывает на разностный LV, а тот уже использует LV "base copy" как основную информацию диска.

Вообще это стандартный режим работы LVM Snapshot.
Когда LV используется, напрямую или опосредованно как LV "base copy" , его "держит" специальный процесс tapdisk. Это можно посмотреть так:
[root@xenserver1 ~]# fuser /dev/VG_XenStorage-210d867d-c6fb-2609-624a-f3151adf7d6b/VHD-1cec624e-1c5e-4b2c-9497-5c0acf08c0e3
/dev/VG_XenStorage-210d867d-c6fb-2609-624a-f3151adf7d6b/VHD-1cec624e-1c5e-4b2c-9497-5c0acf08c0e3: 14613
[root@xenserver1 ~]# ps ax|grep 14613
1645 pts/4 S+ 0:00 grep 14613
14613 ? SL 0:00 tapdisk /var/run/tap/tapctrlwrite4 /var/run/tap/tapctrlread4
а вот все задействованные диски. Это совпадает с количеством примапленных дисков у работающих VM в XenCenter.
[root@xenserver1 ~]# ps ax|grep tapdisk
1649 pts/4 S+ 0:00 grep tapdisk
6019 ? SL 0:14 tapdisk /var/run/tap/tapctrlwrite1 /var/run/tap/tapctrlread1
6061 ? SL 0:00 tapdisk /var/run/tap/tapctrlwrite2 /var/run/tap/tapctrlread2
6439 ? SL 0:00 tapdisk /var/run/tap/tapctrlwrite3 /var/run/tap/tapctrlread3
14613 ? SL 0:00 tapdisk /var/run/tap/tapctrlwrite4 /var/run/tap/tapctrlread4
[root@xenserver1 ~]# ls -l /var/run/tap/
total 0
prwxr-xr-x 1 root root 0 Oct 29 11:35 tapctrlread1
prwxr-xr-x 1 root root 0 Oct 29 11:35 tapctrlread2
prwxr-xr-x 1 root root 0 Oct 29 11:36 tapctrlread3
prwxr-xr-x 1 root root 0 Oct 29 17:37 tapctrlread4
prwxr-xr-x 1 root root 0 Oct 29 16:15 tapctrlread5
prwxr-xr-x 1 root root 0 Oct 29 11:35 tapctrlwrite1
prwxr-xr-x 1 root root 0 Oct 29 11:35 tapctrlwrite2
prwxr-xr-x 1 root root 0 Oct 29 11:36 tapctrlwrite3
prwxr-xr-x 1 root root 0 Oct 29 17:37 tapctrlwrite4
prwxr-xr-x 1 root root 0 Oct 29 16:15 tapctrlwrite5
вот эти файлы - видимо флаги работы с дисками, но что за атрибут файла "p"? Знаю атрибуты "l" = "link," "d" = "directory.","b" или "c" =Device file. а "p"?
Ааа, это "named pipe", т.е. программа tapdisk использует 2 именованных канала, один для ввода, другой для вывода, один канал направлен видимо в сторону LV

диска, а другой - в сторону Xen VM, которая использует диск.

диски
a3da1eac-060d-4759-8a1d-a326796403e3
c1f7b670--374c--44a8--85e2--814d9c50a9ec

Как установить X11+RDP непосредственно на XenServer и ходить на терминалки без добавочного ПК или терминала

Привет Все!
Преамбула: обычно, чтобы развернуть инфраструктуру XenServer и управлять ей, нам нужен собственно хост XenServer и дополнительный ПК для XenCenter, чтобы управлять виртуалками и иметь к ним RDP или VNC доступ. Идея состоит в том, чтобы отказаться от второго ПК или терминала.
Решение: нужно поставить графическое ядро X-Windows и RDP-клиент на Xen хост.
НО! :при ЛЮБОЙ модификации ПО Dom0 XenServer`а слетает его лицензия и потом не ставится, пока не восстановишь XenServer в исходное сосстояние переустановкой поверх. Хорошо, что это происходит с сохранением настроек. Так что делать то что здесь написано, Не рекомендую!

Ход работ:
1.садимся за консоль XenServer, нажимаем Alt-F3 чтобы попасть в свободное терминальное окно, т.к. первое у нас занято xsconslole`ю. Логинимся.
2.настраиваем XenServer на доступ к интернету: определяем сетевой интерфейс, который смотрит в офисную сеть с интернетом. Например это eth0 , мы помним, что физические интерфейсы доступны Xenу через виртуальные мосты xenbr:
[root@xenserver1 ~]# ifconfig
xenbr0 Link encap:Ethernet HWaddr 00:1F:29:37:EF:26
inet addr:192.168.8.41 Bcast:192.168.11.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
3. Проверяем маршрутизацию по умолчанию.
[root@xenserver1 ~]# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 xenbr1
192.168.8.0 0.0.0.0 255.255.252.0 U 0 0 0 xenbr0
0.0.0.0 192.168.11.254 0.0.0.0 UG 0 0 0 xenbr0
если не видим маршрута 0.0.0.0 или Gateway не тот, настраиваем:
[root@xenserver1 ~]# route add default gw 192.168.11.254
что писать Вам вместо 192.168.11.254 узнайте у своего сисадмина.
4. Настраиваем DNS
[root@xenserver1 ~]# vi /etc/resolv.conf
попадаем в редактор. Очень геморойный для людей привыкших к нотепаду 8)
нажимаем букву "a" - попадаем в режим добавления буков. пишем. Нажимаем "Esc" потом ":" потом "wq", "Enter". Получится типа:
[root@xenserver1 ~]# cat /etc/resolv.conf
; generated by /etc/sysconfig/network-scripts/ifup-post
nameserver 192.168.1.1
nameserver 192.168.1.2
5. Настраиваем менеджер пакетов yum на прокси, если оно есть. Типа так:
[root@xenserver1 ~]# vi /etc/yum.conf
[main]
proxy=http://192.168.1.7:8080/
proxy_username=MyDomain\MyName
proxy_password=MyPassword

6. Настраиваем репозитарии yum на обновление только с сайта самой CENTOS. Изменяем все /etc/yum.repos.d:
[root@xenserver1 ~]# ls /etc/yum.repos.d
CentOS-Base.repo CentOS-Media.repo Citrix.repo
в CentOS-Base.repo нужно все enabled=1
в Citrix.repo, CentOS-Media.repo нужно все enabled=0
7. запускаем yum update. Это обновит список пакетов, которые устарели в нашем Xen который по сути Linux CENTOS. Если не видим ошибок - можно продолжать. А, на подтверждение отвечаем утвердительно
8.собственно, ставим Иксы:
#yum groupinstall "X Window System" "KDE (K Desktop Environment)"
это долго. Косяки могут быть в скачивании. Просто перезапускаем установку.
9.Конфигурируем Иксы
#Xorg -configure
при этом созается файл настроек /root/xorg.conf.new
10. Тестируем Иксы
#Xorg -config /root/xorg.conf.new
Вот тут могут быть косяки. Например, на моем уродском во всех отношениях HP DX2400 встроенная видюшка с чипсетом intel gma 3100. Драйвера на него давно в Иксах есть. Но сразу не заработало. Помогло изучение логов /var/log/Xorg.0.log и подсказки квалифицированного линуксоида.
Заменил в /root/xorg.conf.new строку
Driver "intel"
на
Driver "vesa"
и смог увидеть вожделенный экран с крестиком! У вас будут собственные косяки.
11. Нажимаем Ctrl+Alt+Backspace чтобы вернуться в текстовый экран. Нужно закрепить успех) Копируем настройки Иксов из временных в постоянные:
#cp /root/xorg.conf.new /etc/X11/xorg.conf
12. определяем IP-адрес Икс-сервера
export DISPLAY=192.168.2.1:0.0
13. запускаем!
#startx
Вуаля. Иксы работают. Нажимаем Ctrl+Alt+Backspace чтобы вернуться в текстовый экран.
14. ставим RDP-клиента
#yum install rdesktop.i386
Проблем не должно быть.
15. запускаем Иксы. Запускаем в окошке рдп сессию к виртуалке, типа так:
#rdesktop 192.168.2.5
Вуаля. РДП работает.
Всем Удачи!

XenDesktopSetupWizard запускаем с правами не DomainAdminа

XDSetupWizard запущенный под юзером с правами Domain User(прав DomainAdmin нет) но полными правами на Citrix OU (даже owner) завершается аварийно без предупреждения на этапе работы с AD.

Если разрешим запись лога через файл настроек C:\Program Files\Citrix\XenDesktop Setup Wizard\SetupToolApplication.exe.config, то в логе увидим:

INF:(8/14/2009 11:22:22 AM):Target device New6 successfully added to domain.

…

INF:(8/14/2009 11:22:22 AM):Making Directory entry for LDAP://CN=New6,OU=Citrix,DC=testlab,DC=ctx

ERR:(8/14/2009 11:22:23 AM):Error setting properties on AD computer account

Message = System.UnauthorizedAccessException

General access denied error

…

at Citrix.ManagementAPI.Infrastructure.AD.ADManager.SetPropertiesOnDirEntry(String compAccName, String compOuPath, String compLocation, Boolean provisioned)

Если разрешим directory access audit в политиках контроллера домена и разрешим аудит отказов на нашем Citrix OU в АД то чз EventViewer зафиксируем:

Event Type: Failure Audit

Event Source: Security

Event Category: Directory Service Access

Event ID: 566

Object Operation:

Object Server: DS

Operation Type: Object Access

Object Type: computer

Object Name: CN=New6,OU=Citrix,DC=testlab,DC=ctx

...

Accesses: Write Property

Properties:

...

Additional Info:

Additional Info2:

Access Mask: 0x20

Т.е. не хватает прав на запись атрибутов. Дело в том, что АД имеет специальный флаг у атрибутов объектов, которые могут скрывать их для чтения всеми, кроме DomainAdmins, это своего рода фильтр в дополнение к стандартному механизму прав на чтение. Описано сдесь:

http://support.microsoft.com/kb/922836

http://blogs.dirteam.com/blogs/tomek/archive/2005/11/21/confidential-bit.aspx

Это явный косяк XDSetupWizard, поытка читать/писать confidential attribute и не перехватывать неуспех попытки чз exeptions. Решить проблему можно следующим образом:

1. На КД запустить Ldp.exe tool и обязательно только из Windows Server 2003 R2 диска Active Directory Application Mode (папка CMPNENTS\R2\PACKAGES\ADAM\I386\ADAM). Другой lpd не годится.

2.Connection-Connect-localhost

3.Bind - под аккаунтом Domain Admin

4. View-Tree. В Tree найти свою Citrix OU - правый клик - Advanced- Security Descriptor

5.бязательно отметить SACL

6.нажимаем AddACE

7.пишем имя нашего обрезанного админа CitrixOU, в примере - adminvdi

8. отмечаем все дополнительные маски доступа

9. Ok и Update

Перезапускаем визард. 100% заработает) Удачи!

XenDesktopSetupWizard 3.0 не может получить список vDiskов с PVS5.1

Привет все.
Может случиться такой косяк, что XenDesktopSetupWizard 3.0 не может получить список vDiskов с PVS5.1 и выдает на этом этапе ошибку недоступности сайтов PVS.

Это случается потому, что по умолчанию PVS5.1 настроен на TCP порт 54321, а XenDesktopSetupWizard 3.0 по умолчанию обращается к порту 8000. Нужно менять одно из двух. Проще всего сменить настройки PVS через Provisioning Services Configuration Vizard.

Кроме этого, надо тогда правильно настроить потом и Provisioning Services Console на порт 8000.

Удачи!

настоящая причина неработоспособности XenDesktop VDAgentа

Если Вы устанавливали VDI-инфраструктуру XenDesktop, то наверняка сталкивались с проблемой, когда VDAgent не регистрируется на Desktop Delivery Controllerе. И Вы пробовали все варианты, описанные в статье CTX117248 .Вариантов там немного, IP-стек, DNS, UID фермы в реестре виртуального десктопа, синхронизация времени. Эти причины быстро выявляются и убираются, более того, возникновение этих причин маловероятно в принципе, если все делаешь по шагам инструкции.
Главный, и главное - недокументированный косяк в том, что Provisioning Server управляет аккаунтами таргет_девайсов(они же вируал_десктопы) в Active Directory, и если , введя темплейтный вируал_десктоп в домен, используя private_mode виртуального диска ( а как же иначе это сделать), Вы вдруг обнаруживаете, что вируал_десктоп перестал входить в домен из-за ошибки
Event ID: 4
Source: Kerbeors
Type: Error
"The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/myserver.domain.com. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (domain.com), and the client realm. Please contact your system administrator."
это следствие того, что вируал_десктоп имеет 2(два) CSID в AD, соответствующие его имени. Лечится эта ситуация просто. Нужно УДАЛИТЬ(не СБРОСИТЬ) аккаунт вируал_десктопа в AD и затем воссоздать его же через ProvisioningServicesConsole правым кликом на таргет_девайсе. Таргет_девайс после перезагрузки залогинется в домене, а вируал_десктоп 100% зарегистрится на DDC.
Успехов!

Правильно указывайте MSSQL источник при установке XenDesktop 5.1

Правильно указывайте MSSQL источник при установке XenDesktop 5.1, имеется ввиду, с указанием instance. По умолчанию ODBC мастер позволяет выбрать только имя сервера, а мы знаем, что у MSSQL еще есть и экземпляр. Поэтому в строчке Server дописываем чз слэш экземпляр, в нашем случае это SQLEXPRESS. Удачи)

Выяснился еще косячок с установкой Citrix PVS 5.1 на windows 2008

Привет всем!
Выяснился еще косячок с установкой Citrix PVS 5.1 на windows 2008.
Представьте инфраструктуру: домен на контроллере 2008 уровня 2003, один PVS 5.1 на windows 2008 и один PVS 5.1 на windows 2003. Нужно объединить их в одну ферму. SQL 2005 Express на контроллере домена. Создали ферму из PVS Configuration Wizard на PVS на 2008 . Так вот, PVS на 2003 в принципе отказывается видеть базу фермы при настройке его из PVS Configuration Wizard, не подключается к MSSQLю на КД. Пинг с 2008 PVS до КД на 2008 показал, что используется IPv6 по-умолчанию. Вывод - отключить IPv6 на КД, ну и на всякий случай на PVS 2008. Неизящно, может кто придумает лучше. После этого действа оба PVS 2003 и 2008 подключились к одной ферме на MSSQL на КД на 2008 :)

еще один косячок с установкой Citrix Desktop Delivery Controller 2.0 на русский Windows Server 2003

Добрый день.
Выяснился еще один косячок с установкой Citrix Desktop Delivery Controller 2.0 на русский Windows Server 2003, 2008 не тестировал. Проблема в русском имени Администратор пользователя, из-под которого запускаем программу установки. Все дело опять в MF20.dsn, в каталоге C:\Documents and Settings\Администратор\Local Settings\Temp\ этот файл не создается установщиком. Думаю, дело в .NET, которая работает с интернациональными строками как с UNICODE, и если локаль выставлена неверно, при разборе строки русские буквы превращаются в ????????. Обычное дело и для Java. Интернет пестрит этой ошибкой.
Кароче, для решения проблемы создайте админа Administrator, и выполните установку. При этом вы наступите на следующие грабли с MF20.dsn, описанные мною ранее тут . Успехов! 8)

нужно доставить в xenserver 2ой инсталляционный диск с поддержкой Линукс виртуальных машин, есть только iso, диск писать не хотим, флешки нету

Q:а вот задача: нужно доставить в xenserver 2ой инсталляционный диск с поддержкой Линукс виртуальных машин, есть только iso, диск писать не хотим, флешки нету. как быть?
A:положим XenServer-5.5.0-beta1-linux-cd.iso в CIFS ISO Library и заюзаем ее чз XenCenter. Далее:
1. заходим в консоль xenserver и смотрим что примонтировано в xenserver
[root@xenserver1 ~]# mount
/dev/sda1 on / type ext3 (rw)
...
*****а вот тут увидим ISO Library*************
//192.168.1.ххх/Share on /var/run/sr-mount/5e88823d-6b66-58bd-c1e2-fec2ce512c59 type cifs (rw,mand)
и туда мы положили любой исошник, например
XenServer-5.5.0-beta1-linux-cd.iso
2.Читаем и понмаем что написано в http://www.techspot.com/vb/topic483.html
And ISO image can be mounted just like any device or file system, and here is how...
Create a mount point for the ISO:
#mkdir /mnt/iso
Now mount the ISO in the mount point with the following command:
BASH# mount /var/run/sr-mount/5e88823d-6b66-58bd-c1e2-fec2ce512c59/myiso.iso /mnt/iso/ -t iso9660 -o ro,loop=/dev/loop0
Where myiso.iso is your ISO file.
What I haven't tried yet is omitting the ro (read only) option, so that it might be possible to make changes to the ISO before finally burning, not sure if this works (will check) but the command would probably look like this:
BASH# mount /var/run/sr-mount/5e88823d-6b66-58bd-c1e2-fec2ce512c59/myiso.iso /mnt/iso/ -t iso9660 -o loop=/dev/loop0
3. после того как успешно заюзали исошник,т.е. запустили install.sh , нужно его отцепить чз:
losetup -a
losetup -d /dev/loop0
но все равно ISO Library может пропасть из xenserverа, вернее ее содержимое. Тогда отмонтируем например так
umount //192.168.8.ххх/Share
и в xencentrе делаем detach ISOstorage, потом attach.
Все снова работает

XenServer CIFS ISO Library расположена на шаринге виртуальной же машины

если CIFS ISO Library расположена на шаринге VM по адресу внутренней виртуальной сети, то такую библиотеку невозможно подключить собственно к XenServerу, задача подключения начинается и не заканчивается. Прибить задачу можно только чз CLI командой "xe task-cancel". А вот по внешнему интерфейсу VM шару можно подключить как библиотеку к XenServerу и использовать для других VM, и мапить ISOшники.

Error 26009 - Could not access the Datastore using the DSN File. Username and password given function UseFileDSN returned failure in CTX_MF_IMA_SILENT

при установке Citrix Delivery Controller 2.0 и 3.0 может возникать ошибка "Error 26009 - Could not access the Datastore using the DSN File. Username and password given function UseFileDSN returned failure in CTX_MF_IMA_SILENT_ODBC". Для исправления:
1. создайте File DSN чз ODBC с протестированным соединением к БД. Откройте File DSN в нотепаде. Текст будет такой:
[ODBC]
DRIVER=SQL Server
UID=sa
Network=DBMSSOCN
WSID=XENDESKTOP1
APP=Microsoft Data Access Components
SERVER=RODKINSERVER\SQLEXPRESS
2. в сетапе, когда указываете БД, создавайте подключение MF20.dsn по инструкции, делайте его тест по ходу, но после теста откройте файл C:\Documents and Settings\Administrator\Local Settings\Temp\MF20.dsn в нотепаде и замените его текст на вышеприведенный из File DSN, сохраните файл. Жмите Далее
3. Продолжайте установку