Robert Larson

Additional NIC for your Laptop and Hyper-V

If you are like me and use Windows Server 2008 and Hyper-V on your laptop, you have possibly found out that Hyper-V does not support wireless adapters. This is an issue with the Wireless spec no Hyper-V. You can use ICS or bridging to get it to work, but having a 2nd wired network adapter can be helpful in some situations.

What you need is a USB NIC that can be quickly added to your machine when you need it. I have been searching an have bought some adapters from local computer stores to find none that have x64 drivers.

Well another MS consultant told me about an adapter that his friend uses with Hyper-V. I bought one and found some drivers that work

These two adapters work with Vista x64 and Windows Server 2008 x64 if you use the Vista x64 drivers from the chipset manufacturer.

http://www.airlink101.com/products/agigausb.php - 1 Gb version (AS88718)

http://www.airlink101.com/products/asohousb.php - 100 Mb version (AS88772)

Use drivers from chipset mfgr http://www.asix.com.tw

TrendNet also makes a 10/100 USB adapter that has x64 Vista drivers.

http://trendnet.com/products/proddetail.asp?prod=150_TU2-ET100&cat=49

Their gigabit adapter might also have drivers, but I have not investigated it to find out.

So if you find yourself in need of another wired NIC on your notebook running x64, then you have options….doesn’t everyone do clustering on their notebooks :-)

BTW, Fry’s carries the 10/100Mb AirLink101 adapter and it is on sale right now for $2.99 in stores.

Posted: Thursday, July 03, 2008 7:44 AM by RobLarso | 0 Comments

Getting UNDO functionality with Hyper-V Snapshots

Snapshots are not the same as UNDO disks in Virtual Server 2005…go here to read a previous post of mine to learn about how they work.

That said, you get UNDO like functionality using snapshots…..with maybe a little more work.

In Virtual Server, when you wanted to use UNDO, you powered down your VM and enabled UNDO on the Virtual hard disk tab. Then after you power on the VM, when you powered it off you will be asked if you want to Save, Commit, or Discard your changes. Selecting Save kept the changes separate, Commit merged them into the original VHD and then started the UNDO process over again, and Discard threw away the changes and started over again. All of this used Differencing disks in the background.

In Hyper-V, UNDO is not an available option on the virtual disk menu anymore, you now have snapshots. If you want the ability to protect your VHD from any changes getting merged you need to do this.

Before you first power on a VM (the same point you would have enabled UNDO in Virtual Server), take a snapshot and call it something like UNDO DISCARD. This just makes your VHD effectively read only and all changes are written to a working AVHD file.

Power on your VM and work away. When you want to effectively “Turn OFF and Discard” all changes, then apply/revert to the UNDO DISCARD snapshot and it is all gone…start a new test scenario. Just remember that if you made any changes to the VM settings, they are also discarded.

By default all changes are saved to the working file, so you need to do nothing to get the SAVE feature.

If you want a COMMIT capability and want it permanent like it is with Virtual Server, then that takes a little more work. Once you create the UNDO DISCARD snapshot, there is no way to merge any changes back to the original VHD through the snapshot UI.

You can do the following though to get the COMMIT functionality

Power down the VM
Find the working avhd file
Copy it to CHILD.VHD
Backup up your original VHD for protection
Use the Edit disk option in Hyper-V MMC to edit the new CHILD.VHD and select Merge for the action in the wizard
Select to Merge to the parent
Wait for the merge to complete
Apply the UNDO DISCARD Snapshot (which throws away all the changes which you just merged from the copy and creates a new working avhd file that is the child of the original VHD)
Power on the VM and work away

Once again remember that if you had made any changes to the VM settings, that applying the UNDO DISCARD snapshot would have thrown them away…..other than that have fun!!

Let me know if you have any issues...

Posted: Thursday, May 15, 2008 2:54 AM by RobLarso | 1 Comments

Entering Product Keys into Virtual Machines

I create virtual machines every day. I have a set of product keys that I use from my MSDN subscription and I hate playing the visual copy typing game (ok I am a lousy typist). It turns out that I had overlooked a nice little feature in VMConnect that makes this VERY easy.

If you open up VMConnect console to a virtual machine, you will see an option on the menu called Clipboard. The first option is Type Clipboard Text. This nice little time saver allows you to highlight a string of text on the host and then have it pasted into the VM at the current cursor position.

To copy a product ID into a setup dialog, copy the product ID and the hyphens from a notepad file or other location on the host, place your cursor within the borders of the VM (or click inside the VM if you do not have integration components loaded), click into the product ID box, and press CTRL-V. The feature types the contents of the clipboard text.

Short, simple, easy to use.

Posted: Monday, May 12, 2008 4:39 PM by RobLarso | 1 Comments

Virtual Machine Snapshots with Hyper-V

Snapshots are a new feature of Windows Server 2008 Hyper-V. Snapshots are a point in time version of a virtual machine…..what does that mean you ask? It means that you can be running a virtual machine, take a snapshot and at any point you can select a previous snapshot and revert back to that point in time. You end up with the virtual machine in the EXACT configuration that it was when you took the snapshot…and I mean exact….memory, virtual hardware, processes, state, etc. So you can have a running virtual machine, take a snapshot, change the virtual hardware configuration, format the disk and install a different OS, it does not matter, when you apply the previous snapshot it looks exactly like it did when you took the snapshot.

Snapshots do not affect the running state of the virtual machine, meaning that taking a snapshot does not change the virtual machine hardware, applications, or the currently running processes. It also means that deleting a snapshot does not change the virtual machine either….it just means that you cannot go OOPS and go back to that point in time to get you out of something you just did.

The snapshot files consist of the following:

A copy of the VM configuration .xml file
Any save state files
A differencing disk(.avhd) that is the new working disk for all writes that is the child of the working disk prior to the snapshot.

If you create snapshots one right after each other and never apply a previous snapshot, the you will have a tree with one branch. if you apply a previous snapshot, then you will get another branch to the snapshot tree starting at the applied snapshot.

Creating Snapshots – How does it work?

When you create a new VM in a directory, let’s say D:\TestVM, two sub directories are created – D:\TestVM\Snapshots and D:\TestVM\Virtual Machines. The \Snapshots directory contains nothing, but the \Virtual Machines directory contains the original XML configuration file saved with a unique GUID as the filename with an .xml extension and a directory to house the save state files (.VSV and .bin) memory files. The directory also uses the same GUID as the directory name. I will refer to this as the VMGUID.

Note: All the filenames and directories are actual GUIDs, I am using friendly names to make it easier to write and understand the concept.

The VMGUID.XML file points to the D:\TESTVM\TESTVM.VHD as the current VHD for all writes. Before you do any snapshots, all changes get written to the D:\TESTVM\TESTVM.VHD file and any save state is saved in the D:\TestVM\Virtual Machines\VMGUID directory.

When you create the first snapshot you have two scenarios: [1] You create it with the virtual machine powered down or [2] you create it while the virtual machine is running.

CASE [1] – VM is powered off

It creates two directories in the D:\TestVM\Snapshots\ folder

One with a folder name of VMGUID – this is where all the avhd files will be stored for all snapshots (This only happens for the first snapshot)
One with a new GUID for a folder name – this is where the memory save state for this snapshot is stored, I will refer to this as SNAPGUID
In this case no files are written to D:\TestVM\Snapshots\SNAPGUID here because the VM is powered down and there is no memory state

It also creates a copy of the VM’s XML configuration file with filename SNAP1GUID.XML
It creates a working .avhd files with another GUID and stores it in the D:\TESTVM\Virtual Machines\VMGUID directory. I will refer to this as WORKING.AVHD
The VM’s original VMGUID.XML file is updated to point to the new WORKING.AVHD as current VHD

CASE [2] – VM is powered on

Everything that happens for CASE [1] happens for case [2] except in this case the memory is saved to disk and stored in the D:\TestVM\Snapshots\SNAPGUID folder as a BIN with the actual memory saved and a VSV with supporting process information.

Both Case [1] and [2] proceed the same from here….

From this point on, all writes are written to the WORKING.AVHD file. If you make a bunch of changes and then decide to use Revert (to go back to the point in time of the first snapshot), this is what happens

The WORKING.avhd file is deleted and a new one is created with a different GUID
The VM’s original VMGUID.XML file is updated to point to the new WORKING.AVHD as current VHD
If there was a save state file to load it would be loaded and the VM would be resumed from save state.
If there was no save state file to load, the machine would remain powered down since you took the snapshot when it as powered down.

So you make a bunch of more changes and then take another snapshot, this is what happens

A copy of the current VMGUID.XML files is made, placed in the SNAPSHOTS folder and given a filename with a new GUID, let’s call it SNAP2GUID.XML
A folder is created in the SNAPSHOTS folder using the SNAP2GUID to house the save state files for this snapshot, The VM is save stated to this folder
The current D:\TESSTVM\Snapshots\VMGUID\WORKING.AVHD file is now the point in time state of the VHD (the GUID does not change)
- Its parent is the original TESTVM.VHD file
A new WORKING.AVHD file is created with a new GUID
- Its parent is the old WORKING.AVHD file
The VMGUID.XML file is updated to the new WORKING.AVHD

So for each new snapshot in succession

A copy of the current VMGUID.XML is made and placed in the VMs SNAPSHOTS folder, the filename is a unique GUID
A new directory is created in the SNAPSHOTS folder to hold the save state files, the folder name is the same as the GUID in (a) above
A new avhd file is created with a new unique GUID. This becomes the new working avhd file and the existing one becomes the RO parent.
All new writes are made to the new working avhd file

Hope that provides you with a better understanding on what snapshots are and how they are created under the hood…..I will save deleting snapshots for a future post :-)

Robert….

Posted: Saturday, April 26, 2008 8:33 PM by RobLarso | 4 Comments

Building a Host Cluster with Hyper-V Beta 1

Well by now you have heard the news that Microsoft shipped Hyper-V Beta 1 early!!

Like many of you I have been testing away and thought I would share the steps for creating a host cluster in Windows 2008 and Hyper-V. For those that have built host clusters in Virtual Server, you will find the process in Windows 2008 and Hyper-V much more streamlined and user friendly. One major improvement is the integration of Hyper-V as a cluster aware application and native support for making a virtual machine highly available.

So what are the 10 steps you have to go through to build a host cluster using iSCSI shared storage?

1) Build nodes with Hyper-V
2) Build Virtual Network Switches in Hyper-V
3) Establish iSCSI Target Quorum and Data drives
4) Use iSCSI initiator on each node to connect to targets
5) Install Failover Clustering on each node
6) Run Validate on the cluster nodes
7) Create Cluster
8) Build a VM to make highly available
9) Make the VM highly available
10) Test it by moving the VM to another node

Node1

LAN IP address = 192.168.0.170
Heartbeat IP address = 10.10.10.1

Node2

LAN IP address = 192.168.0.171
Heartbeat IP address = 10.10.10.2

Cluster IP Address = 192.168.0.181

Step 1:

Building the nodes with Windows 2008 Enterprise or Data Center edition is a simple process. Once you have the OS installed, you need to add the Hyper-V role in Server Manager (and reboot)

Step 2:

Once you reboot and Hyper-V installation completes, you need to launch the Hyper-V management console from the Administration Tools menu on each node.

[Do this on both nodes] On the right hand side, click the Virtual Network Manager, and create a new virtual network switch. For simplicity make it a private network and call it Private. The name must be the same on both nodes.

Step 3:

Go to the iSCSI target (hardware or software based) and build two disks enabled for shared access. One disk needs to be 500 MB or larger to hold the cluster configuration info, and other disk needs to be big enough to hold the virtual machine, say 10 GB minimum. Be sure to enable the option for shared or cluster access to the disks.

Step 4:

On NODE1 launch the iSCSI initiator software. Discover the iSCSI target via name or IP address and then establish a connection to the Data and Quorum disks that were established in step3.

Once the disks are connected to Node1, use Disk Management to initialize and format them as NTFS volumes. Assign driver letter Q: to the small disk and a drive letter like S: to the large disk.

Now go to Node2 and use the iSCSI initiator to connect the target disks, you do not need to do anything else.

Step 5:

From Server Manager, install the feature called Failover Clustering on each node. and when done, launch the Failover Clustering Management console .

Step 6:

Verify that Node1 has current ownership of the disk resources (although either disk could have ownership) and then launch the Validate process from Node1 specifying Node1 and Node2 are the nodes of the cluster, run all tests. If issues are identified, the validate report will provide details on what the issue(s) are and how to resolve them.

Click Validate a Configuration

Provide the names of the two nodes

Execute the validation process

Get a report back on the progress, if successful you should see all green checkmarks

Step 7:

Once you have completed a successful validate process, you can now build the cluster. It is a four step process

1) Select Create Cluster from the Failover Cluster Management console.
2) Specify the nodes of the cluster
3) Specify the name and IP address of the cluster
4) Execute the create process

Step 8:

Using the Hyper-V Management console, create a virtual machine called TestVM on Node1 that can be made highly available. Use Windows 2008 for the operating system. The integration components are automatically installed for you.

Do not start TestVM, it must be in the powered off state to make it highly available.

Step 9:

Make TestVM highly available. This allows you to have a planned or unplanned migration of a VM between nodes.

Click Configure a Service or Application

Select Virtual Machine from the list of available services or applications

Select TestVM as the VM to make highly available

Execute the process

Success!!

Now bring the VM online, right click the VM in the list and select "Bring this service or application online"

Step 10:

Once it is online you can test the fail over by moving the VM to Node2.

Right-click the Application and select "Move this service or application to another node", select Node2

Watch the process

1) The VM is placed in saved state
2) The resources are moved to Node2
3) The VM is resumed from saved state

Now the VM has successfully failed from Node1 to Node2.

You have successfully built and tested a 2-node host cluster using Hyper-V. Note that you can have up to 16 nodes in a Hyper-V host cluster.

Hope this helps you understand Hyper-V host clustering......:-)

Posted: Monday, December 17, 2007 2:12 PM by RobLarso | 20 Comments

Virtualization at IT Forum

Well I am off to Barcelona Spain again to speak at TechEd IT Forum November 12-16th. This will be an exciting show for Virtualization. System Center products will be launching and Microsoft will be making some announcements about Windows Server 2008 virtualization.

System Center products focused on virtualization:

Virtual Machine Manager 2007 - centralized management of your Virtual Server 2005 R2 SP1 pool of hosts, Physical to Virtual migration, Virtual to Virtual Migration, Self Service web portal, VM templates, provisioning, and much more....

Data Protection Manager 2007 - centralized backup to disk or tape, native support for Exchange, SQL, SharePoint, and Virtual Server, delta based backup to reduce network traffic, end user file recovery, and much more

Operations Manager 2007 - SCOM has already been launched, but at the show will be new management packs for VMM and Virtual Server

Viridian announcements - While I cannot blog about the announcements...yet, I think you will really like them. So stay tuned....

There will also be many breakout sessions on Virtualization. There will be a surprise at a couple of the sessions....we will be giving away signed copies of the Virtual Server 2005 R2 Resource Kit , so come attend for a chance to win a copy.

See you there!!

Posted: Saturday, November 10, 2007 10:27 AM by RobLarso | 0 Comments

Self Service VM Management with SCVMM

One of the features of VMM that I really like is the power of the Self Service Web Portal (SSWP). The portal provides an individual user or group of users access to a virtual machines that they own or that they create. They can see, manage, and interact with virtual machines remotely using the VMRC ActiveX control.

You can create a portal and limit a group of users to specific actions or management capabilities. The use of the SSWP is limited only by your imagination. Here are some examples that I have thought about

1) Remote development environment for internal or outsourced developers.
2) Remote training environment, you can build a view only environment for end users so they can remotely attend a training class and watch the instructor teaching them a new skill from the instructors view-only VM, then switch over to a development VM to try it themselves.
3) Remote admin into a production environment (one you own or a hosted environment)
4) Remote test and Q/A environment
5) Remote proof of concepts for your software applications
and many more....

Enabling the SSWP for end users requires the following steps:

1) Install the Web Portal on a server (I just installed it on the VMM server for test purposes)

2) Create a Host Group and place one or more managed hosts in the host group (only the hosts in the host group are available resources for new VM creation)

3) Create a Self Service Policy (or multiple if you want different ones to apply to different VMs, View Only policy, Manage Policy, Create and Manage Policy)

4) Configure any pre-existing VMs for the policy

5) Build templates for the self services users if you are going to allow them to create virtual machines

Installing the web portal is easy and well documented, so I will not go over it again here.

Creating the host group is pretty easy also, in the VMM Admin Console, go to the Host view, then in the Actions menu on the right hand side, you will see a section called Host Groups, Click New Host Group, give it a name (I called mine SelfServe) and press OK.

Once you have the host group, you can drag and drop one or more managed hosts into the group. Once you do that, then select the group and then in the Host Group actions, Press New Self-Service Policy.

Provide a name for the policy

Set the policies that you want to apply to the user or group of users that you selected and save the policy.

If you already have Virtual machines on the host or if you will be pre-creating the virtual machines and not allowing the users to create virtual machines on their own, then you must configure the VM properties to recognize the policy. When you allow the users to create their own VMs, these values will be automatically set as the VM is created.

If you are creating the VMs for the user, then you must change the owner value of the VM to be owned by the user or group you selected for the policy. Select the VM and look at it properties. In the Owner box, set the owner.

Next click the Self-Service Tab and set the policy and the quota value for the VM.

Press OK.

Now you have the host group, self-service policy, and the existing VMs all configured for the policy.

The user can now connect to the Self-Service Portal to access the VMs that they have rights to. When they go to the self service web site, they will be prompted for their credentials, then presented with the screen below. On the left hand side is the list of all the VMs they have rights. If they select a VM, they will be presented with information on the VM and a menu of actions will be presented on the right hand side. For this VM the policy allows the user to Start, Stop, and view the properties of the VM.

As the administrator, if you go to the self service portal, you will see the same screen as a regular user. The administrator will be presented with a troubleshooting screen that allows you to help users of the portal.

Entering a user name in the box and pressing Enter will allow you to see the same interface the user sees so you can determine any issues they are having.

As you can see, setting up a Self Service Web Portal is not that complicated.

Enjoy!!

Posted: Saturday, November 10, 2007 10:27 AM by RobLarso | 0 Comments

Microsoft publishes the Hypercall APIs via the Open Specification Promise

Microsoft announced today with it will be publishing the Hypercall APIs through the Open Specification Promise when Windows Server Virtualization ships. In addition they posted a draft of these interfaces in the form of a Hypervisor top-level functional specification on Microsoft downloads here. This document gives you and view of the external interfaces of the first generation hypervisor from Microsoft and contains the following information:

Introduction
Basic Data Types, Concepts and Notation
Feature and Interface Discovery
Hypercall Interface
Partition Management
Physical Hardware Management
Resource Management
Guest Physical Address Spaces
Intercepts
Virtual Processor Management
Virtual Processor Execution
Virtual MMU and Caching
Virtual Interrupt Control
Inter-Partition Communication
Timers
Message Formats
Partition Save and Restore
Scheduler
Event Logging
Guest Debugging Support
Statistics
Booting
Appendix

This is really cool and gives you a detailed view of how to interface with the Microsoft hypervisor.

For more information, go to the Virtualization Product team blog entry here

Posted: Thursday, October 25, 2007 4:26 AM by RobLarso | 0 Comments

Changes to Virtual Networks in Virtual Server 2005 R2 SP1

In Virtual Server 2005 R2, a virtual network operated like a hub with a switched uplink port. Traffic on all guests plugged into the network was visible on every port of the virtual network, but that traffic was not visible to anything on the other side of the uplink port because it was switched. The pro was that it was easy to use Network Monitor to trace what was going on the network. The con was every guest saw every packet and extra overhead existed.

In Virtual Server 2005 R2 SP1, the virtual network was converted to a switch for all ports. This reduced the traffic that each VM saw and reduced the network overhead, but made it harder to sniff traffic between guests.

There is a solution to the problem though on a per VM basis. To enable the VM to see all the traffic, you need to enable promiscuous mode for the port. There is a setting in the VMC file called allow_promiscuous_mode that by default the value is false.

This tag exists under the <virtual machines> node and the syntax is

<allow_promiscuous_mode type="boolean">TRUE/FALSE</allow_promiscuous_mode>

Setting the value to TRUE will enable the old behavior from R2.

You will need to do this if you want to load NetMon or other packets sniffer software in the VM and see all the traffic on the virtual network.

Posted: Wednesday, October 24, 2007 5:32 AM by RobLarso | 0 Comments

New bonus scripts for Virtual Server 2005 R2 Resource Kit

My co-author Janique Carbone has posted two new bonus scripts on her site http://vscommunity.com.

Both scripts have to do with finding out information about differencing disks.

GETVHDParentInfo - Allows you to specify a VHD file on the command line and the script will tell you if the VHD is a differencing disk and then walk the tree of dependencies to show you the entire hierarchy of the parent child relationship

ListDiffDisks - Allows you to point at a Virtual Server host and it will enumerate all the virtual machines and all of their VHDs, telling you which ones are differencing disks and also printing the entire hierarchy of the parent child relationship.

These are posted in the Downloads area and require you to be a registered user of the site to download them.

Enjoy....

Posted: Monday, October 15, 2007 11:05 PM by RobLarso | 0 Comments

Windows 2008 Components Posters

Previously published in the July issue of TechNet Magazine, these are two PDFs of Windows 2008: Operating System components and Active Directory components. The posters explain how they work and detail capabilities. They are great resources to have up on your office wall (you will need a big printer though).

http://www.microsoft.com/downloads/details.aspx?FamilyID=c2b9e44e-0bbd-47cb-bc09-b3d48be7f867&DisplayLang=en

The Feature Components poster highlights the following components of the Windows Server 2008 operating system:

Terminal Services
Network Access Protection
IIS 7.0
Server Manager
Server Backup
Server Core
BitLocker
Windows Server Virtualization

The Active Directory Poster highlights the following components of Active Directory in Win2008

AD Lightweight Directory Services
AD Federation Services
AD Rights Management Services
Group Policy
AD Management
AD Read-Only Domain Controllers

These are painstakingly created by two Microsoft employees in Australia, Martin and Astrid McClean. These two have been building these posters for years and they have all been great hits, usually causing multiple re-printings.

Great job once again.....

Posted: Monday, October 15, 2007 10:55 PM by RobLarso | 0 Comments

How does the mapping from a virtual network adapter to a physical adapter work?

Adapted from Chapter 7 of the Virtual Server 2005 R2 Resource Kit book from Microsoft Press

So you are trying to figure out how a virtual machine network adapter is mapped to a physical network adapter in the host through a virtual network. Maybe you moved a virtual machine between hosts and it now gives an error about not finding XYZ virtual network and will be binding to the default virtual network.

There are three pieces to this puzzle.

The options.xml configuration file of the Virtual Server host contains the physical network adapters that have the Virtual Machine Network Services (VMNS) bound to them.
The virtual network configuration (.vnc) file has the mapping to the physical adapter
The virtual machine configuration file has the mapping to the virtual networks it is attached.

To trace a virtual machines mappings, open the .vmc file and look for entries for each virtual network adapter that specifies the ID of the virtual_network that the VM it is attached to. You can see by this example, that the id value is 00D67AACDFC2499DBD9222F7A0A29D54. Record this value.

<ethernet_controller id="0">
                <ethernet_card_address type="bytes">0003FF1B6AD5</ethernet_card_address>
                <id type="integer">5</id>
                <virtual_network>
                        <id type="bytes">00D67AACDFC2499DBD9222F7A0A29D54</id>
        <name type="string">Wireless</name>
                </virtual_network>

Now open up the .vnc file for the virtual network that is attached. Search for the ID that you just recorded, then write down the <gateway> value. You will need this to determine which physical adapter it is bound.

<settings>
<gateway type="integer">22</gateway>
<id type="bytes">00D67AACDFC2499DBD9222F7A0A29D54</id>

Now open up the options.xml file and search each virtual_gateway entry for a value of id that matches the <gateway> value from the .vnc file.

<virtual_gateway id="7">
        <adapter type="string">\DosDevices\VPCNetS2_{CA746289-F2E6-405A-B7C2-E2595ACA750A}</adapter>
        <id type="integer">22</id>
        <name type="string">Intel(R) PRO/Wireless 3945ABG Network Connection #2</name>
        <type type="integer">2</type>
    </virtual_gateway>

Now look at the name value and you know which physical adapter your virtual machine is attached!

Posted: Friday, October 12, 2007 10:43 PM by RobLarso | 0 Comments

Getting Wireless LAN on Windows 2008 RC0

If you are like me and primarily use a notebook, then you live by wireless. If you are also trying to test Windows 2008 RC0 then you might be scratching you head on how you get wireless to work. Windows 2008 has a new feature called the Wireless LAN Service. Until the feature is installed, wireless will not work.

To install the feature:

1) Go to Server Manager

2) Add a new feature

3) Select to add the Wireless LAN Service

4) Finish the installation

5) Install your WIFI drivers if not automatically detected.

For the Windows Server Virtualization testers out there, Wireless is not supported and you will not see a working wireless LAN adapter as a valid network interface to create a virtual network....sorry, but how many real servers do you have with wireless adapters?

Posted: Tuesday, October 09, 2007 1:34 AM by RobLarso | 2 Comments

Looking for Virtualization info..how about some webcasts

Microsoft is holding a series of webcasts to provide information on the virtualization solutions it provides. If you want to learn about Microsoft Virtualization technology or how to manage the virtualization technology, check these out. There are a couple that already happened, but are available on-demand....enjoy

Virtualization and Windows Server 2008 (Level 300) - On-demand

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032351359&EventCategory=4&culture=en-US&CountryCode=US

In this webcast, we provide an overview of the virtualization role, the scenarios, and the features that make server virtualization an important pillar of Windows Server 2008. We also cover the longer-term strategy and road map for Microsoft virtualization technologies.

Examining Virtualization with Windows Server 2008 (Level 300)- On-demand

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032351234&CountryCode=US

In this session, we examine the Microsoft virtualization ecosystem and how to implement it with Windows Server 2008. Taking an overall view of virtualization, we cover topics including: presentation, application, and server virtualization scenarios and technologies

A 360 View Inside the Virtual World (Level 200)

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032352793&Culture=en-US

Monday, October 15, 2007

9:30 AM – 11:00 AM Pacific Time

Join this session for a look at what virtualization is and gain insight into the overall Microsoft virtualization strategy. Learn about the Microsoft road map for virtualization and examine what workloads make good candidates for virtualization and why you would consider moving these workloads into a virtual world.

Windows Server Virtualization Under the Hood (Level 200)

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032352797&Culture=en-US

Wednesday, October 17, 2007