|
|
|
Forum Newbie
Group: Forum Members
Last Login: Monday, November 05, 2007 12:21 PM
Posts: 4,
Visits: 18
|
|
Great product for field engineers that need to demo capabilities of any software along with SAN.
Setup a VMware Server with VSA and expanded (array0) disk to 30 GB. Added 10 more VMs, all running Win2k3. One of the VMs was setup as an emBoot winBoot/i Server, the remaining ones were setup as winBoot/i Boot-from (LeftHand VSA) iSCSI SAN Clients (yes, they fit in under 30 GB of space if you trim them right...).
Advantages:
1. Can demo most VSA features (clustering / snapshots, etc.) / emBoot features (shared image / client menus, etc.) from one small portable system (ASUS Pundit P3-PH5, 95 x 357 x 398 mm) that can be easily carried on a plane.
2. Power - can easily connect / demonstrate to 10+ independent users via VMware Server Remote Console, each with individual Windows client booting from SAN. System configuration => DuoCore / 6+ GB RAM / 2 HDDs / 5 NIC ports (only using one port in this setup)
3. Recoverability / Transportability - VMs can be copied to 2nd HDD, or burned off to DVD for easy recreation of demo environment on alternative hardware.
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: Sunday, July 20, 2008 4:31 PM
Posts: 20,
Visits: 105
|
|
Hi Boot from SAN
Looks like you answered my question about Netboot in the Network Area of the Forums, also holy bat socks that rocks!!!
Would you be willing to provide a breakdown of this Solution for the Viewers like me, such as the netboot setup on this type of platform?
Terry
Reality is defined by the physical universe and your mind - "Its the second one that varies" :-)
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: Monday, November 05, 2007 12:21 PM
Posts: 4,
Visits: 18
|
|
Breakdown....can do: (environment is VMware Server v1.0.3 on Windows 2003 host, winBoot/i v2.0)
1. Setup VSA: I wanted to use (for manageability) just one VSA with multiple boot luns instead of multiple VSAs with single boot luns.
Prior to use of the VSA:
- I grew the array0 disk to 30 gb. Contrary to VSA instructions, there is no need to delete the disk and recreate it in a bigger size. I simply used the command "vmware-vdiskmanager -x 30Gb array0.vmdk" (assumes the command is in your path).
- Make sure to bump up the VSA memory another 15 mb or so to accommodate the 30 gb in storage.
- Setup the VSA vm to use a host-only network because:
---- no need to rely on external DHCP for vm client PXE boot. VMware internal DHCP handles it fine.
---- virtual machines become completely portable, because one can exactly replicate the host-only network
---- setup is easier than using bridged network - based on past experience on a bridged network with DHCP and iSCSI targets running on the host OS.
- start the VSA vm. Login, create administrative name and password, and set the network for DHCP for now. Observe the IP address provided, and then reset this to a dedicated IP address using the same IP address already provided by DHCP. Keep this open so you can quickly remember the IP address when you eventually access the LeftHand VSA Management Console from the winBoot/i Server.
2. Setup Windows 2003 virtual machines:
I created one Windows 2003 vm (using the standard VMware Server template) - I changed the disk size to be 4 gb. Do remember that this is considered, for the winBoot/i client purposes, local boot from local (vmdk) disk. Eventually, one can ditch the local disk (vmdk) once booting from SAN (as exposed by the VSA).
- Install Windows 2003 OS. Unless you have all Windows installation files available local (hotfixes, patches, service packs, updates, etc.) I suggest leaving the network bridged so you can access files externally until the OS installation is complete. Set them for DHCP. Need to get them under 4 gb? Trim the page file down, get rid of $uninstall$ files from your Windows directory, etc. I can get this down to 3.5 gb with not too much effort.
- Install the winBoot/i client - this puts down the Microsoft iSCSI boot initiator that all Windows vms (including the winBoot/i server) will use.
- set the network to host-only. Release and renew your DHCP lease to pick up an IP for the host-only network.
- Copy your Windows 2003 vms. Follow VMware guidelines for avoiding activation headaches - install VMware tools first, watch your memory size, etc. The finer points of efficiently - and legally - creating clones of this Windows 2003 OS are left to other sources.
- Make the necessary adjustments (depending on cloning process used) to set each of these vms to be unique - primarily, computer name and iSCSI initiator name.
- on one of the vms, install the winBoot/i Server. No need to uninstall the winBoot/i client. Prior to configuring the winBoot/i Server, install the LeftHand Centralized Management Console (CMC). Use the wizards to point to the VSA, and create the necessary management groups, clusters, volumes, authentication groups, etc. For my purposes, 4 gb vols were fine. You can cut and paste initiator names in from the other Windows vms (if they are different - see note immediately below first)
- Run the winBoot/i server management console to setup access for targets and winBoot/i clients. In my case, I cheated, and use the same initiator name across all Windows vms. This way, when I browse for target names inside winBoot/i, I get all the names of the VSA targets, since winBoot/i calls the MS iSCSI initiator to do the browsing.
- point each winBoot/i client to a distinct target. There are several ways to grab the MAC address for the various winBoot/i client vms : a) ipconfig /all from a 2k3 command prompt, or b) from the .vmx file, or, c) easiest way: reboot the 2k3 winBoot/i client vm, hit F12 for PXE boot. The PXE boot will fail, and stop. However, the winBoot/i Server captures these PXE broadcasts, and lets you stuff in the MAC address field from the 'failed' PXE boot by using the browse button on the 'new client' dialog. Repeat this one at a time for each of the winBoot/i clients.
3. Setup 2k3 winBoot/i client vms:
- Follow winBoot/i quick start instructions to do this, but generally:
- Use the MS initiator to login to the already prepared VSA target
- Run the Disk Management mmc to prep the VSA boot lun - initialize, partition, format, mark active, etc.
- run System Copy to copy the local disk (vmdk) to the VSA disk.
- reboot client vm, set to PXE boot (F12) and test boot from VSA target.
4. Once you have this working, some considerations / variations:
- stagger system copy(s) across multiple VMs, as well as stagger boot from iSCSI (or even .vmdk local boot), as these concurrent operations can spin your CPU cycles on the host to near 100%, although the host system will survive this without crashing.
- if using this for classroom or other demo purposes, setup the boot clients once first. Then use SystemCopy with volume / incremental options to more quickly 'copy' a 2nd time to same target.
- add another separate VSA to demo clustering or other VSA features
- One quick cloning scenario (perhaps for demo purposes) - sysprep a winBoot/i boot from VSA SAN client, and snapshot it. Add the snapshot to a volume list as a read/write volume and connect to it with a new iSCSI initiator. Repeat as necessary to deploy clones.
- Use the winBoot/i client write filter read-only function, along with wildcarded client MAC addresses to quickly point multiple boot- from-iSCSI vms to a single boot lun. This function is native on netBoot/i, and requires a separate client utility for winBoot/i. Toggle the 'use computer name' to avoid duplicate computer name warnings on boot up. Great way to minimize VSA disk space utilization by pointing multiple VDI clients to a single boot lun.
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: Sunday, July 20, 2008 4:31 PM
Posts: 20,
Visits: 105
|
|
Thanks for this, I appreciate it
However, it is going to take me a bit of effort to beat that!
thanks again
Reality is defined by the physical universe and your mind - "Its the second one that varies" :-)
|
|
|
|