Can I PXE boot to an iSCSI target from within a virtual machine from VMware or Microsoft?
Yes, you can use winBoot/i to network boot VMware and Microsoft virtual machines from an iSCSI target. HBA-equipped systems hosting virtual machines generally do not allow sharing (or virtualization) of the HBA-capability within the vm environment. We recommend using our Managed Boot Agent on Disk (MBAoD) for VMs to PXE-enable the virtual NIC within the virtual machine.
I was trying to find out how to prevent users for accessing the VMware tools in a Windows 2003 Terminal Server. Seems this is actually a security bug.
I’m running Windows Terminal Server on top of Debian with VMware Server. My solution was to add an explicit DENY permissions to the WTS_Users group I had added to the TS machine’s “Remote Desktop Users” group. I changed these permissions in the locations mentioned in the securityfocus message.
Check this webcast hosted by PlateSpin and Virtual Iron: Reducing Costs and Increasing Agility with Virtualization, and this interface demo. Unfortunately you have to sign up to see it, however it shows some similar stuff to the VI3 demo further down this blog. Virtual Iron is Xen based with some of their own additions, they have Live Migration and DR Migration working now, plus there management interface is very nice.
The one feature I think is perfect and I’ve thought about doing myself is PXE booting the computing nodes and having them join the computing cluster as a resource automagically. This is exactly the right idea. The hardware platform you are running on reduces down to just a software management system. No doubt within a few years server systems will start being designed with the option of a hypervisor as part of the bios. Some one clever could probably do it now with LinuxBios.
The Virtual Iron price structure is very similar to Xen, and beats VMware’s by a huge margin. 500USD plus 125USD per year vs 2875USD per socket plus 700USD per year.
Quick howto with screen-shots for the setup of a iSCSI initiator in VI3.
Up to this point I have not done extensive testing on the overall performance of my setup. What I do know is it performs more than well enough to run an IIS Web Server, an average load SQL Server, and AD Server, an Exchange Server and a File Server without breaking a sweat on the Linux iSCSI Server resources. In addition, the applications respond incredibly well considering the fact that my “Enterprise SAN” cost me less than $500 total. For development purposes to test VMotion, DRS, and HA, this is DEFINITELY a good solution to take a look at. Some brave people, like myself, may even consider using it for production data. I make sure I have a good solid backup every night.
This is running the following setup:
Virtual Machines Running
Windows 2003 Domain Controller – 384MB Memory
Windows 2003 SQL Server – 512MB Memory (Scripts running consistent read/write/update load on server)
Windows 2003 Exchange 2003 Server – 512MB Memory (10 Mailboxes, 5 with a TON of spam being sent for load)
Windows 2003 File Server – 384MB Memory
From the looks of some of the comments this is not totally production ready, although this probably has improved in the last six months. It does point to the way things are going though.
Diskless Processing Units, net (PXE, ISCSI, or ?) booting to a hypervisor and running Software Appliances back-ended to Storage Appliance (brandware or software) Units holding the data.
Some hints here for this right with Netapp equipment.
Warning: require_once(/home/emptysands/stateless.geek.nz/wp-content/themes/copyblogger/footer.php) [function.require-once]: failed to open stream: Permission denied in /home/emptysands/stateless.geek.nz/wp-includes/template.php on line 407
Fatal error: require_once() [function.require]: Failed opening required '/home/emptysands/stateless.geek.nz/wp-content/themes/copyblogger/footer.php' (include_path='/home/emptysands/stateless.geek.nz/wp-content/plugins/openid/lib:.:/usr/local/lib/php:/usr/local/php5/lib/pear') in /home/emptysands/stateless.geek.nz/wp-includes/template.php on line 407