Today while tryng to do a V2V migration form Parallels to VMWare, I had the need to boot my current VM into BartPE so I could create an image with Tru Image. When the VM started up, I tried to press al sorts of F key combos to get to the BIOS screen. In Virtual Server/Virtual PC, pressing F2 does the trick; but in Parallels it was not working.
After taking a trip to the VM preferences, I found that this is set within the VM properties, and is actually quite simple:
Today I was helping a colleage to restore an image that was created with TrueImage to an empty VHD. The process can be narrowed down to the following steps:
- Create the image using TrueImage
- Create two VHDs on the target VM (one to store the image, and the other to restote the image to)
- Mount the VHD that will hold the TrueImage image using vhdmount and format it
- Copy the Image from step 1 onto the VHD
- Unmmount the image and commit changes
- Boot into drive image and restore the image
Sounds easy? Well, usually it is - but today I faced a problem with step 3 above. When I mounted the VHD and formatted it, everything seemed fine, but when TrueImage tried to read the VHDs, it barfed and said that it was "unsupported". This was very weird since I mounted the VHDs time and time again without problems and the contents were inside. The VHDs were formatted as NTFS, so there really was no reason for the "unsupported" file format.
We tested and decided to format the partitions from within TrueImage using the new hardware wizard. After formatting them, I mounted the one that would hold the TrueImage image, copied the file and then tried to restore the image once again.
To my surprise, this time around TrueImage read both drives and the image contained on the VHD that I just copied. After that, it was just a matter of specifying the source and target and the P2V migration was underway.
Bottom line, if you are planning on using empty VHDs with TrueImage (the bootable CD), make sure that you format the VHD with the utility itself and not within Windows using vhdmount. Why? Dunno, but if someone would like to shed some light on this issue, please be my guest!
During the last month, due to some testing we had to carry out with a software project, I needed to work with 64-bit virtual machines. Virtual Server does not support 64-bit virtual machines, so I downloaded a copy of VMWare's free server solution and decided to give it a try. After playing around with VMWare Server, I've had my ups and downs which I will try to contrast with my previous experiences with Virtual Server.
PriceBoth are free, no contest there. VMWare requires a registration process to obtain the product key for the server, which can be a bit of a hassle. Virtual Server requires a registration process as well but no product key is needed.
64-bit SupportVMWare's server runs as a 32-bit process on 64-bit hosts and offers support for 64-bit VMs (read again, slowly and it will make sense). Virtual Server runs as a 64-bit process on 64-bit hosts and does not offer support for 32-bit VMs.
Types of Virtual Hard DrivesVMWare offers virtual drives that expand as they become bigger or ones that are of fixed size. It does not offer what is known as Difference Disks in Virtual Server. These disks are amazing when working with lab environments or for multiple restore points, and is one feature I cannot believe is in some way or another on VMWare.
Undo Disks
VMware and Virtual Server both have this option. The restore process under VMWare is easier to carry out than on Virtual Server.
Cross CompatibilityVMWare Virtual Server imports Virtual Servers vhds seamlessly. It does, however, convert them to a big mess of chunks that is hard to maintain. Although Virtual Server does not import any other type of virtual hard drive from another reseller, there are tools out there that will do the job for you.
GUIEven though there are some clear advantages of having a web interface for Virtual Server, there should have been a binary to administer it. There are some
new alternatives out there that might work for Virtual Server, but the bottom line is that the 32-bit client for controlling VMWare's server blows any web application out of the water.
Overall, both are excellent products and the fact that they are free is amazing. I have grown so used to Virtual Server that I will continue to use it unless I have the specific need for a 64-bit VM, and when that time comes, I will hopefully be able to use Longhorn Virtualization.
VMWare, VirtualPC, Virtual Server, Parallels - they all have one thing in common: in order to work faster, they install a set of drivers that patch the VM. This has a very positive effect on the virtual experience, but what happens when, say - the VMWare drivers are running under Virtual Server?
As you might have guessed it, no good things happen.
Products such as Parallels and VMWare Virtual Server allow you to import machines that were created with Microsoft's virtualization products. If you grab a machine from Microsoft's VHD test drive program and import it right away, you are in for a nasty surprise. The drivers for the previous product are still there, and they *will* conflict when you install the additions of the new product.
So remember, get rid of your product's "additions" *before* migrating virtual machines.
On a previous post I was having problems with the VMRC ActiveX control when creating an instance at runtime. The problem boiled down in having an invalid OCX state exception thrown at me whenever I tried to access a property of the VMRC ActiveX control at runtime.
After researching for quite a while on the Internet, it struck me that if I just placed the VMRC ActiveX in a UserControl at Design time, and instantiated that UserControl instead of the ActiveX directly, things would work great. I implemented this into the VMCA application and it worked perfectly fine. You can see I managed to get VMRC connections to different machines in different tabs at runtime on this post.
Some people have asked where they can get a copy of the VMCA. Unfortunately as of now, the application hasn't been thoroughly tested and is missing some functionality which I deem as basic. Also, this is something I have been working on my spare time and lately I have been swamped with other projects. Perhaps the best approach would be to take it to stable phase and then try and get it on CodePlex so that everyone can pitch in...we'll see how that goes.
For all things related to software migration, be sure to visit Artinsoft's website. For training in Visual Basic to C# migrations, Visual Basic to VB.Net, Virtualization, and 64-bit training check our training web page.
As I previously mentioned, I've had some chance of working on the application dubbed as the Virtual Machine Configuration Assistant in the last few days. One of the most noticeable changes are the GUI. This is the old GUI of the app:
This is the revamped, improved version:
The application has undergone major revisions under the hood. I have tried to separate tasks into different classes in order to gain modularity. So far I have a VMManager, a VHDManager, a VMRCManager and so on. Reading the code now makes a lot more sense than before.
This is the part in which most of the work has been lately done, the Disks tab:
From here, you can pretty much do anything related with VHDs. After modifying some ISOs, I have also managed to completely automate the defragmentation-precompaction-compaction phase required to reduce the size of VHDs. Now I just leave the process running and when I arrive the next day, my VHDs are like 50% smaller.
I had not touched C# in a while, and all I can say is "Wow". C# rocks, it is very intuitive and creating efficient GUIs is a bliss. One can only wish that there was a 2.0 framework to run under OS X.
I have also fixed the problem with OCX stats at runtime - actually it was a workaround, not a fix. Here is a video I made of some of the features of the application, which include:
- VHD Attachment
- VHD Creation
- VM Creation
- VMRC in tabs for each of the machines
*sigh*...It has been impossible to embed the video here, here is the
youtube link.
In case the resolution of the movie above is too small, the avi can also be downloaded.
For all things related to software migration, be sure to visit Artinsoft's website. For training in Visual Basic to C# migrations, Visual Basic to VB.Net, Virtualization, and 64-bit training check our training web page.
During the Virtualization labs, which are freely available to anyone interested in Virtualization, the Artinsoft trainers have had a chance to teach the Virtual Server COM API and its uses. One of the attendees showcases the application that they build on his blog. I think the application in its finished state is a great start to create something functional, but it is in no way something that can be used for management right out of the box. The reason for this is simple: we wanted simple in order to reduce the learning curve of the COM API.
I have started to work on my spare time on a new version of the Virtual Machine Configuration Assistant (VMCA) which will be version 2.0 due to major UI overhaul it has had. One of the cool things I wanted to do, was the ability to open VMRC connections within the app in tabs (gotta love tabs in everything!). So here is the interface I have so far (click on the image for larger view, as it has info on what I am trying to accomplish):
Sounds easy, huh? Well, that is what I thought. I have in my application the reference to the VMRC ActiveX control, the image that you see above depicts a VMRC instance placed on the form in Design Time.
When the user selects the VMRC option, I have the following code:
vmrcControl = new AxVMRCClientControl();
vmrcControl.ServerAddress = "vs02";
vmrcControl.Size = new System.Drawing.Size(985, 675);
//Add a New Tab
this.tabPage1 = new TabPage();
tabPage1.Text = VMCA.VirtualInstances.getVMInstance().Name;
//Add the VMRC Control
tabPage1.Controls.Add(vmrcControl);
vmrcControl.Location = new System.Drawing.Point(0, 0);
this.tbcVMRC.TabPages.Add(tabPage1);
vmrcControl.UserName = "Administrator"
The line in red below is where all hell breaks loose:
The problems seems to be that at design time, the VS Designer creates and configures a resource that is used to keep track of the ActiveX instance's state. At runtime, this resource does not exists and that is the reason why the ActiveX is an invalid state. Not being the ActiveX hacker that I would like to be, I am baffled on this problem.
Have you ever suffered with a problem such as the one above? I have looked for help at various locations without any luck. Although not critical, this feature is something that would definitely rock. Help me solve this problem and I will send you a couple of pure quality Costa Rican coffee wherever you may be (if you are in Costa Rica, I'll send you beer instead ;)
I have posted a project which repros the problem:
http://amd.streamload.com/artinsoft/Links/5B75335893
In order to repro, just debug the app, and from the menus select Remote Control...if you can somehow make it through without the invalid OCX state exception, you are right on the money.
UPDATE: In order to run the project above, you *need* to have the VMRC ActiveX control installed on your machine. The following page will guide you with the necessary steps to complete this process:
https://www.microsoft.com/resources/virtuallabs/installactivex-technet.aspxFor all things related to software migration, be sure to visit Artinsoft's website. For training in Visual Basic to C# migrations, Visual Basic to VB.Net, Virtualization, and 64-bit training check our training web page.
Longhorn Server will have a virtualization role that will basically replace the need to use Virtual Server when working with Longhorn. If you want to play around with the new virtualization role as of now, it is not going to be possible because this feature not present in any public betas.
If you are curious about what this "role" is and a little more information on how this will impact that way we run virtual machines, take a look at the following demo done byJeff Woolsey:
Video: Longhorn - Windows Server Virtualization
Try this link instead for no-registration hassle
If you are still a bit lost in terms of what virtualization is, check the Intel webcast below:
These videos introduce virtualization technology and point out the differences between sofware and hardware based virtualization. They explore existing and emerging usage models of Virtualization: Server consolidation, disaster recovery, development/testing, load balancing, fast provisioning, etc They introduce the next generation of Intel� Virtualization Technology (Intel� VT) and VT -d (Directed I/O) and suggest usage models for the future enterprise.
At this point, Parallels is one of the key players when it comes to virtualizing any x86 operating system on OS X. I use it on daily basis and cannot live without it.
VMWare has been working on its own version of the VMPlayer for OS X, called Fusion. The Betas that I have worked with have been not that impressive in terms of performance. VMWare claims that some of the sluggishness comes from debug code embedded into the application. On the other hand, Fusion offers some innovative features:
- Support for 64-bit VMs
- Ability to assign a CPU/core to the host, and the other to the program
Recently they have upgraded their beta to support 3-D acceleration directly from the graphics card. This means that very soon, Mac users will be able to play 3-D games on Windows within OS X. Considering that the list of Mac games is extremely short, this will really make things interesting for the Mac gaming market. There is a video on YouTube that has a demo of the application running:
http://www.youtube.com/watch?v=xF_CoXsXtk4
Your move, Parallels ;)
Yesterday, one of the attendees from the
Virtualization events asked this question which I though would be worthwhile to share:
For a simple .NET application like this, would we need different applications when running on 64 vs. 32 bit hosts?
Before answering, please allow me to elaborate more on where the question is going. Virtual Server has a COM API that allows it to be managed by applications and scripts. Virtual Server R2 SP1 Beta 2 (phew) comes in two flavors: 32-bit and 64-bit. The owner of the question wondered if you could manipulate a 64-bit instance of Virtual Server using a 32-bit application (or vice-versa).
Ok, now that the question is (hopefully) a bit clearer, the answer to the question is
no, you do not need to have a different version for accessing Virtual Server from an application regardless of its bit-architecture. Why? Virtual Server's COM API is accessed by an out-of-process COM library, which means that everything is done by means of RPC. When two applications are communicating with each other by means of RPC, the 1st commandment of 64-bit is
not broken (thou shall not run 32-bit and 64-bit code within the same process space).