Good bye Visual Studio Emulator for Android and hello problems

I recently tested a prototype of a Xamarin Android app that should run on Android 4.1+. So I fired up Visual Studio Emulator for Android and saw that API level 16 (4.1) is missing from the list. The oldest is level 17/4.2.

Since they have a nice smiley icon for feedback I wrote a quick request to include level 16 as well since a lot of apps are targeting 4.1+, not just me.

The shocker came few seconds later in a form of an automated e-mail response (emphasis mine):

Hello,

This is an automated message. Unfortunately, we have no plans to publish Android images past 4.4. We recommend that you try Google or GenyMotion’s emulator for future images of the Android operating system.
 
When we first released the Visual Studio Android emulator, the Google emulator was slow, out-of-date, and a significant source of pain for mobile developers. In addition to the great work performed by GenyMotion, the Visual Studio Android Emulator proved that emulators can be fast, productive tools for mobile development.
 
Since then, Google has responded to developer feedback by increasing their investment in their tools. The next generation Google Android Emulator has closed the feature gap that previously differentiated Visual Studio’s emulator. Google’s emulator has become much faster and more feature rich.
 
We also know that, for mobile developers, authenticity is key. We believe that Google, as the platform owner, is best positioned to provide ongoing support for new versions of the platform in a way that accurately and authentically reflects the real-world behavior on devices.
 
For developers like you who’ve come to love and depend on the VS Android Emulator, thank you! We will continue to support in-market platform images according to Visual Studio’s generous support policy. However, Microsoft will no longer produce new Android images for the VS Android Emulator. We consider this a successful project that has come to a natural conclusion.
 
Happy coding!

Wait, what? First time I heard that VSE4A is no more. Which wouldn't be that tragic if Hyper-V wasn't involved. See, VSE4A is the only Android emulator based on Hyper-V. Why do I even care? Oh, I do and you should do as well. When Hyper-V is enabled it doesn't allow any other virtualization host to run. Sure, you can disable Hyper-V (reboot required) and go with Google's Emulator or a better one from Genymotion. But then you can't run Docker, Windows Emulator and  your other Hyper-V guests at the same time. More here.

Happy coding, indeed.

There is light of hope though. Miguel tweeted that there might be a solution in the future



Hopefully that's the case. In the meantime VSE4A still works and is available for download, it is just missing images, specially newer ones (latest is API level 23 aka 6.0).

But at the end I'd really like Microsoft to address the cause of this blunder: the monopolistic Hyper-V behavior on desktop. If Windows virtualization worked like others do ("live and let live") there won't be a problem whatsoever. The way it works now it makes sense on servers, not on desktops.

But instead of fixing that, Microsoft choose to create all imaginable emulators on top of Hyper-V. What could go wrong?

The long path of installing Windows Home Server 2011 under Hyper-V R2

Here is my experience of Windows Home Server 2011 aka Vail installation under Hyper-V R2 server (Core2 Duo E7600, 8GB RAM, 500GB RAID 1 and 3TB RAID5). What could have gone wrong it actually went but let’s go by steps.

  1. During file copy at the very beginning I was experiencing couldn’t copy file XY. Problem: corrupt ISO file I was using. Solution: re-download the file.
  2. The setup make it further but I started experiencing random reboots and BSODs during install, this time it was happening soon after initial files copy finished. On the bright side I caught few of them and they were mostly mentioning memory corruption. Time for memtest86+ and for RAM test. It turned out that one of four Patriot DDR2 2GB CAS6 memory sticks was bad. Solution: Throw out the problematic stick and run the server with three sticks. Also donated to memtest86+, well deserved.
  3. Memory issues were still present during setup. Argh.  Solution: Throw out the third memory stick (they like to work in pair it seems and a pair and a third wheel obviously isn’t something one should use) and replaced it with two older 1GB sticks I had collecting dust.
  4. I’ve made it to the step when setup says “Waiting for installation to continue” and shows a marquee progress bar. Except it didn’t finish. Ever. Now what. After peeking into log files located at C:\Users\All Users\Microsoft\Windows Server\Logs I’ve more or less soon understood that it has something to do with the “waiting for a web page to show”. After more digging I’ve found out that there were problems connecting to the internet and the internal web page wasn’t showing. Problem: the network card didn’t get an address from my DHCP for some reason. Solution: I’ve set a fixed IP and DNS records.
    Hint: Type Ctrl+Alt+End to simulate Ctrl+Alt+Del from Hyper-V client. Pick Start Task Manager and File/Run. Run explorer.exe and you can browse around the file system.

It took me a couple of days to make it through but at least I did it. Hura. It took me that much because I was installing on a 1TB VHD disk on a RAID5 array and setup takes time each retry.

So, that’s it. Now it looks fine.

Migrating a Windows Home Server guest machine from VMWare Virtual Server 2.x to Hyper-V

I was running a Windows Home Server under VMWare Virtual Server as a guest machine. It had a dedicated 750GB hard disk to host a fixed size virtual disk spanning entire hard disk.

These days I am migrating this and other virtual machine to the Hyper-V 2008 R2 free server and here is how I did migrate it.

  1. Uninstall Virtual Server Tools from guest machine (this is important at this point in time because later it can’t be done easily through add/remove programs).
  2. Shut down guest.
  3. Copy all VMDK files to a spare (new) 1.5 TB Seagate disk. This step isn’t strictly necessary but it was for me because the source disk had troubles reading some sectors – if I wanted to proceed I had to have all the files on a good disk. This step took something like 4 hours over 1Gb LAN.
  4. Download and run VMDK to VHD Converter.
  5. Convert VMDK files (as input select the one without numbers if your virtual disk is partitioned across many files, i.e. SomeDisk.vmdk). I converted to the same hard disk (it barely fits) and it took something like 7 hours.
  6. Copy the resulting VHD to the Hyper-V server (I could pick the server as target location in step 5. but I felt more comfortable doing conversion locally). This step again took something like 4 hours.
  7. Create a new Virtual Machine on Hyper-V server, attach the resulting VHD file as its disk.
  8. Run the machine, activate OS (it will detect “huge” hardware change and it will require activation).
  9. Install Integration Services (Action/Insert Integration Services Setup Disk on connection window) and that’s it.

Lessons learned:

  • Hard disks are growing fast in size but network speed doesn’t. Thus such transfers will be slower and slower due to the sheer amount of data to transfer between disks.
  • Such operation might take whole day
  • If you use an external disk like I am then you should really stick with e-Sata instead of USB 2 or firmware (it is up to 4x faster)
  • Have enough free space on hard disks