Installing from USB Stick. Go find UNetbootin Make the USB stick from the install iso as normal. This will work, but won't install the linux support, to do that in one shot, modify the USB stick as follows: Open the linux support iso with something that can understand it, or make a usb stick of it first and copy out the client_install and packages.linux directories. Copy them into the root of the USB stick with the install image on it. Rename \syslinux.cfg to syslinux_cfg.old Rename \boot\isolinux to syslinux Rename \boot\syslinux\isolinux.cfg to syslinux.cfg Off you go! This is assuming you have more disk space to allocate. Log into http://sanbox.tmr.local/ Username: admin Password: The usual N0... Services - iSCSI Target Choose Targets In the Extents section, find and click the large + symbol. Name the extent the next available number, it will likely already be correct The Type is file The path will be: /mnt/raid/volumeX where X is the number of the extent File size: Generally, 250GB is a good digestable size, and is easy to move to 500,750,1T,1.5T,1.75T disks, etc. Make sure you choose GiB from the drop down. Click Add In the Targets section, find and click the large + symbol. The defaults are generally correct, except for: Auth Group needs to be "Tag 1 Xen iSCSI" Change queue depth from 0 to 255 Click Add Here's where you'll hate me. Sometimes, if you've changed something innocuous, FreeNAS must be rebooted to show the new iSCSI storage. Stupid. I know. That's why I built all the iSCSI exports when I added the disks initially. I did leave a little extra but they are on non-raid disks, so plan accordingly. If you're adding more now, hopefully it's for bigger disks or a new SAN. Plan ahead! If after an uncoordinated reboot, the SAN comes up after the Xen server(s), machines can forget their drives and/or the SAN can come up broken with exclamation marks on the iSCSI mdX icons in XenCenter. How to fix it, in a moment... Prevention is far easier than fixing this! The stupid simple way to fix this? In the event of a total power pooch (middle of the night everything off for hours, ups'es depleted) then everything turns back on at once: Make the Xen boxes have a long timeout at the boot screen, enough for the FreeNAS to come up and represent the iSCSI targets. The FreeNAS is really fast to come up, but may not beat the Xen boxes in the drag race that ensues. Get a console prompt on each Xen server, and run: nano /boot/extlinux.conf and change the timeout setting to 120 Control-X to save and exit. Done. Now to FIX it since you already screwed up: You can right click them and try to repair them, although it doesn't usually work. The next safest way is to right click the iSCSI mdX icon and choose Detach Storage Repository. Right click the grey iSCSI mdX that you just Detached and choose Attach You will need to fill in all the blanks again: Target Host: 10.200.200.250:3260 Use CHAP CHAP User: xen CHAP Secret: xenxenxenxen Target IQN: iqn.2009-08.local.tmr.san.freenas:disk0 (Example!) Target LUN: LUN0: 250 GB (FreeBSD) (Example!, we build them so the diskX number matches the LUN) Click Finish It will give you a warning about ensuring that the LUN is not in use anywhere else, and that mounting it twice will surely hose it beyond belief. Make sure you have the right one, and click Yes. If you're lucky, the disks will reattach themselves to the machines they came from, and you're done. Turn on the virtuals. If you're less lucky, the disks won't reattach themselves, and you'll have to use the names and descriptions to find and reattach the disks to the virtuals. Good luck. I'll bet you remember to label them the next time you create a virtual machine, won't you? If you're even less lucky, or the connection was more hosed that you thought, you won't have any connections or names or descriptions. At that point, you better consult your docs of what you built and when, or fire up an Ubuntu live ISO and mount the disk to see what it is. Best of luck to you! It's a total pain. How to prevent in the future: Shutdown the XenServers first, when they're all down, shut down the SAN. Turn the SAN on first, make sure it's all the way up, turn on the XenServers. If you know which Xen server is "Chief" bring it up first, if you don't just bring them all up, they'll sort it out. There are different stages of getting rid of iSCSI storage, much like old girlfriends: Detach - You can get it back and remember everything. Forget - The attachment is gone, but they remember all the disks and data, but not the connections back to virtuals. Destroy - It's gone, data's gone, connections gone, gone, gone, gone, etc. Basically, format it and start over. On machines that have 4GB or more, sometimes only 3.2GB can be seen. This is an artifact of the PAE extensions for 32bit support failing to realize that there is a 64bit OS installed. Xen is more likely to have this problem than ESXi. The fix is easy: Find and flash a newer BIOS onto the motherboard. Since these are newer Dual/Quad Core Duo's and have 4/8/16GB of RAM, they should support 64bit out of the box or at least have a BIOS available that can. If you need to attach to the ISO library of CD images through Xen or ESXi, the procedure is the same. Use their GUI's to attach to an NFS ISO library, name it what you want. The path is: On the SAN side: 10.200.200.250:/server/images/cd On the LAN side: 192.168.100.250:/server/images/cd The should be attached as Read Only if given the option. When attaching an iSCSI LUN to a Xen server/pool, you can click Discover IQN's and it seems to work and gives you a list of targets, clicking Discover LUNs takes a long time and gives an error that no LUNs were found on 192.168.100.250. TMR's XEN cluster uses CHAP authentication on the SAN to keep the drives from getting stepped on accidentally. Clear the error, check the Use CHAP checkbox, fill in the username as xen and the password as xenxenxenxen. Click Discover LUNs again and it should work. Note that it will show you LUNs that are already attached, so make sure you pick the right IQN before picking your LUN. Note that the FreeNAS will show you TWO of every IQN, one on 192.168.100.250 and one on 10.200.200.250. In general, you want the one on the Gigabit SAN side, 10.200.200.250. I Can't migrate a working machine from one Xen Server to another There are many reasons why this may not work: 1) Is the machine running on shared storage? (iSCSIx) 2) Is the machine running the XenServer tools? 3) Does the destination server have enough RAM to accommodate the moving server? 4) Is there an error logged? 5) Is it moving and you are impatient? 6) Does the server use a network segment that is unavailable on the destination? (DMZ? The shuttle has no DMZ connection) 7) Is a DVD/CD image attached somewhere where it can't disconnect? 8) Is your pool master missing? i.e. is XenCenter behaving properly? You'll probably want to use FreeNAS and NFS instead of iSCSI if you need to clone many machines, as it starts with base images and then makes diff images for the clones.