Posts Tagged‘card’

BitInstant, BitCoin Market Corrections and Cryptocurrency’s Future.

There seems to be a prevailing idea that the price of BitCoins is somehow intrinsically linked to the overall confidence in the use of the nascent cryptocurrency. If you’ve read any of my previous articles on BitCoin you’ll know that I strongly believe that that isn’t the case and indeed a rising price is usually a signal of speculative investors gaming the market to turn a quick profit more than it being an indication of market confidence. Indeed I was most bullish on the idea of BitCoin when its price  stop fluctuating which meant it was far less risky for people to use it as a wealth transfer vehicle, especially for those who are taking the risk of using them in their business.

Now I’ll be completely honest here, when I saw the first stirrings of an upward tick in BitCoin’s price I wasn’t too worried that it would lead to a speculative bubble. Sure it was dangerously close to the same ramp up just a year previous but I felt that the higher transaction volume, larger amount of wealth contained in the BitCoin network and hopefully the market’s long term memory would ensure that any growth in the price was purely organic and sustainable. Of course this discounted external actors with larger amounts of capital working to skew the market in order to turn a profit but I felt that the speculators had had their fun last year and had moved onto other, more lucrative endeavours.

Looks like I was wrong.

As you can see from the above graph the BitCoin price took a turn for the volatile side around the middle of July. Since then there’s been several spikes in trading volume most of which have coincided with a jump in the price. Whilst there appears to be islands of stability that last about a week it never lasted long before another trading bout would push the price upwards. This culminated in a peak price of about $14 late last week quickly followed by a swift downward correction in price with it stabilizing around the $10 mark. As I’ve said before this kind of price volatility is very much at odds with BitCoin being a proper currency and it’s unfortunate to see history repeating itself here again.

Interestingly though the correction in price may actually be due to dwindling confidence, but not in the BitCoin idea itself. The first lawsuit involving BitCoins and the failed wallet service Bitcoinica was lodged just days prior to the value taking a swift nose dive. This was most likely exacerbated by people attempting to cash out at the current peak as you can see the transaction volume on that day was several times higher than the average for the preceding couple of months. Bitcoinica, unfortunately, isn’t the only story of BitCoin based services that have endured failure and this could have very easily shaken the market enough to attempt to dump out early to avoid losing all their value.

The underlying cause to much of the volatility that the BitCoin market experiences is the relatively small amount of value that it captures. Whilst as a whole the BitCoin market is valued at some $97 million (total number of BitCoins in existence multiplied by current price) the total transaction volume on any given day usually only averages $800,000. That’s incredibly open to manipulation and showcases just how crazy those peak trading days, the ones where the value changing hands is on the order of 3 times the average, really are.

Now I don’t pretend to have a solution to this but a new startup called BitInstant might have the right idea when it comes to injecting more value into the market and hence (hopefully) reducing its volatility.

BitInstant is a clever little idea using prepaid MasterCard debit cards which are then backed with either real US currency or BitCoins. The cards can be recharged either by traditional means or by using a BitCoin address that’s printed on the back of the card. They make this even easier by also including a QR code on the back which would enable users to transfer BitCoins between them using things like BitCoin enabled apps on their smart phones. The details on it are still being finalized but this has the potential to take BitCoins from their current niche operations to a much larger scale and hopefully with that bring a lot more stability to the BitCoin price.

BitCoin purists will probably detest the cards since they will require some level of formal identification for them to be able to use it, thus eliminating the benefits of anonymity, but I don’t believe BitInstant’s product is aimed at them. Indeed it seems to be more of a way to make BitCoin function more like a traditional currency as currently it really is only for the technical elite or those who have a need to transfer funds in a completely untraceable manner. Giving people a physical card they can use anywhere will go a long way to making BitCoins much more palatable for the masses, something that all the current BitCoin services I feel have failed to do.

BitInstant is just one piece in the larger puzzle though and realistically its going to take many, many BitCoin enabled services to make it viable as a currency. Good news is that appears to be happening with BitInstant being just the latest contender to throw their hat into the BitCoin ring. Hopefully this means that the peaks and troughs in BitCoin’s trading price will soon be a lot more tame and then I’ll stop harping on about how BitCoin’s price is the last thing we should be thinking about if we’re serious about it being a currency.

VMware VIM SDK Gotchas (or Ghost NICs, Why Do You Haunt Me So?).

I always tell people that on the surface VMware’s products are incredibly simple and easy to use and for the most part that’s true. Anyone who’s installed an operating system can easily get a vSphere server up and running in no time at all and have a couple virtual machines up not long after. Of course with any really easy to use product the surface usability comes from an underlying system that’s incredibly complex. Those daring readers who read my last post on modifying ESXi to grant shell access to non-root users got just a taste of how complicated things can be and as you dive deeper and deeper into VMware’s world the more complicated things become.

I had a rather peculiar issue come up with one of the tools that I had developed. This tool wasn’t anything horribly complicated, all it did was change the IP address of some Windows servers and their ESXi hosts whilst switching the network over from the build VLAN to their proper production one. For the most part the tool worked as advertised and never encountered any errors, on its side at least. However people were noticing something strange about the servers that were being configured using my tool, some were coming up with a “Local Area Network 2” and “vmxnet3 Ethernet Adapter #2” as their network connection. This was strange as I wasn’t adding in any new network cards anywhere and it wasn’t happening consistently. Frustrated I dove into my code looking for answers.

After a while I figured the only place that the error could be originating from was when I was changing the server over from the build VLAN to the production one. Here’s the code, which I got from performing the same action in the VIClient proxied through Onyx, that I used to make the change:

            NameValueCollection Filter = new NameValueCollection();
            Filter.Add("name", "^" + ServerName);
            VirtualMachine Guest = (VirtualMachine)Client.FindEntityView(typeof(VirtualMachine), null, Filter, null);
            VirtualMachineConfigInfo Info = Guest.Config;
            VirtualDevice NetworkCard = new VirtualDevice();
            int DeviceKey = 4000;
            foreach (VirtualDevice Device in Info.Hardware.Device)
            {
                String Identifier = Device.ToString();
                if (Identifier == "VMware.Vim.VirtualVmxnet3")
                {
                    DeviceKey = Device.Key;
                    NetworkCard = Device;
                    Console.WriteLine("INFO - Device key for network card found, ID: " + DeviceKey);
                }
            }
            VirtualVmxnet3 Card = (VirtualVmxnet3)NetworkCard;
            VirtualMachineConfigSpec Spec = new VirtualMachineConfigSpec();
            Spec.DeviceChange = new VirtualDeviceConfigSpec[1];
            Spec.DeviceChange[0] = new VirtualDeviceConfigSpec();
            Spec.DeviceChange[0].Operation = VirtualDeviceConfigSpecOperation.edit;
            Spec.DeviceChange[0].Device.Key = DeviceKey;
            Spec.DeviceChange[0].Device.DeviceInfo = new VMware.Vim.Description();
            Spec.DeviceChange[0].Device.DeviceInfo.Label = Card.DeviceInfo.Label;
            Spec.DeviceChange[0].Device.DeviceInfo.Summary = "Build";
            Spec.DeviceChange[0].Device.Backing = new VMware.Vim.VirtualEthernetCardNetworkBackingInfo();
            ((VirtualEthernetCardNetworkBackingInfo)Spec.DeviceChange[0].Device.Backing).DeviceName = "Production";
            ((VirtualEthernetCardNetworkBackingInfo)Spec.DeviceChange[0].Device.Backing).UseAutoDetect = false;
            ((VirtualEthernetCardNetworkBackingInfo)Spec.DeviceChange[0].Device.Backing).InPassthroughMode = false;
            Spec.DeviceChange[0].Device.Connectable = new VMware.Vim.VirtualDeviceConnectInfo();
            Spec.DeviceChange[0].Device.Connectable.StartConnected = Card.Connectable.StartConnected;
            Spec.DeviceChange[0].Device.Connectable.AllowGuestControl = Card.Connectable.AllowGuestControl;
            Spec.DeviceChange[0].Device.Connectable.Connected = Card.Connectable.Connected;
            Spec.DeviceChange[0].Device.Connectable.Status = Card.Connectable.Status;
            Spec.DeviceChange[0].Device.ControllerKey = NetworkCard.ControllerKey;
            Spec.DeviceChange[0].Device.UnitNumber = NetworkCard.UnitNumber;
            ((VirtualVmxnet3)Spec.DeviceChange[0].Device).AddressType = Card.AddressType;
            ((VirtualVmxnet3)Spec.DeviceChange[0].Device).MacAddress = Card.MacAddress;
            ((VirtualVmxnet3)Spec.DeviceChange[0].Device).WakeOnLanEnabled = Card.WakeOnLanEnabled;
            Guest.ReconfigVM_Task(Spec);

My first inclination was that I was getting the DeviceKey wrong which is why you see me iterating through all the devices to try and find it. After running this tool many times over though it seems that my initial idea of just using 4000 would work since they all had that same device key anyway (thanks to all being built in the same way). Now according to the VMware API documentation on this function nearly all of those parameters you see up there are optional and earlier revisions of the code included only enough to change the DeviceName to Production without the API throwing an error at me. Frustrated I added in all the required parameters only to be greeted by the dreaded #2 NIC upon reboot.

It wasn’t going well for me, I can tell you that.

After digging around in the API documentation for hours and fruitlessly searching the forums for someone who had had the same issue as me I went back to tweaking the code to see what I could come up with. I was basically passing all the information that I could back to it but the problem still persisted with certain virtual machines. It then occurred to me that I could in fact pass the network card back as a parameter and then only change the parts I wanted to. Additionally I found out where to get the current ChangeVersion of the VM’s configuration and when both of these combined I was able to change the network VLAN successfully without generating another NIC. The resultant code is below.

            VirtualVmxnet3 Card = (VirtualVmxnet3)NetworkCard;
            VirtualMachineConfigSpec Spec = new VirtualMachineConfigSpec();
            Spec.DeviceChange = new VirtualDeviceConfigSpec[1];
            Spec.ChangeVersion = Guest.Config.ChangeVersion;
            Spec.DeviceChange[0] = new VirtualDeviceConfigSpec();
            Spec.DeviceChange[0].Operation = VirtualDeviceConfigSpecOperation.edit;
            Spec.DeviceChange[0].Device = Card;
            ((VirtualEthernetCardNetworkBackingInfo)Spec.DeviceChange[0].Device.Backing).DeviceName = "Production";
            Guest.ReconfigVM_Task(Spec);

What gets me about this whole thing is that the VMware API says that all the other parameters are optional when its clear that there’s some unexpected behavior when they’re not supplied. Strange thing is if you check the network cards right after making this change they will appear to be fine, its only after reboot (and only on Windows hosts, I haven’t tested Linux) that these issues occur. Whether this is a fault of VMware, Microsoft or somewhere between the keyboard and chair is an exercise I’ll leave up to the reader but it does feel like there’s an issue with the VIM API. I’ll be bringing this up with our Technical Account Manager at our next meeting and I’ll post an update should I find anything out.