Mounting an ISO-Image on ESX-VM (own Client, similiar to VI) with mks

[fhoffmann]

Hello,

i work on a application (c#.NET) which connects to a vmware esx-server and embedd the console of the vm.

I use the MKS-Lib (http://communities.vmware.com/message/1116657#1116657) to do this.

Now I have to mount an client-iso file to make it accessible inside the vm, but it doesn't work.

The method i use is AttachRemoteCDROM and I became a true as result and also the OnDeviceConnectionStateChange is triggered with true.

But inside the vm is just an empty cd-drive, nothing mounted.

Here is the code I use for the connection:

string hostname = ESX_Data.IPAddress;

int authPort = ESX_Data.Port; // 902

string vmCfgPath = VM_Data.VMPath;

string username = ESX_Data.Username;

string password = ESX_Data.Password;

string deviceNode = "3000"; // found by the managed object browser (https://esxip/mob), it's the cdrom device-id

bool imageISO = true;

string localDevicePath = @"H:\images\bootimage.iso";

Console.WriteLine("Is connected before: " + this.axQuickMksAxCtl1.IsRemoteDeviceConnected(localDevicePath).ToString());

bool ret = this.axQuickMksAxCtl1.AttachRemoteCDROM(hostname, authPort, vmCfgPath, username, password, deviceNode, rawDevice, exclusiveDevice, imageISO, localDevicePath); Console.WriteLine("Try to connect: " + ret); Console.WriteLine("Is connected after: " + this.axQuickMksAxCtl1.IsRemoteDeviceConnected(localDevicePath).ToString());

I hope that someone can help me with this.

Greetings,

Florian

[jrackliffe]

Hey Florian,

This one bugged me for a while. http://communities.vmware.com/message/1026613

After a bit of playing with these dark and mysterious client side libs I figured out what was wrong.

You are on the money excepting the one field that I had to figure out by intercepting the javascript of the web console and throwing in an alert in the VC web code.

The device Node is not just the devices ID as I thought and you as well.

It is a composite id: "ide" + BusNumber of the VM's CDROM IDE Controller + " :" + CDROM's unit Number...so it would be something like "ide0:0"

You can get the busNumber reliably by using the VirtualCDROM.controllerKey over the VirtualHardware collection to get the IDEController.

As a note I used raw=true, exclusive=false and ISO=true.

And... yes it will always return true so testing the return is a frustrating test so continue using the isRemoteDev.

I know I have put the RFE to have the MKS system documented and "opened" for VI API users so I advise you do the same if you have a support contract as it will help get that up the priority list.

OHHH... and BTW do not use that widget on the VM that you are changing the VM's config on (mount an ISO in a VM to itself) creates a huge contention on ESX and will freeze the VM. You can demo the same with the web console.

J

[fhoffmann]

Hello jrackliffe,

thanks for the answer but I didn't make it work.

I changed the deviceID to "ide0:0" (at the vm it's the first ide-controller and only the cd-drive is connected. hdd-> scsi), but there is no change.

Would you be so kind to give me a little code-snippet that worked?

At the moment I try to reverse engineer the vi-website (like you did) and hope to find something.

Florian

---

VM-Config (CD-Drive) image attached.

[jrackliffe]

Providing code will be difficult as it is baked into my client side libs I developed and use a number of other parts.

Hmm.... maybe I assumed something.

Just wondering are you getting your lables "ESXData" object from the AcquireMksTicket(MoRef VM) call? That is the key from the VC/Host side of MKS connections. Again not the best doco on use, but my call to AttachCdrom goes something like this.

VirtualMachineMksTicket _ticket = AcquireMksTicket(vmMoRef);

mks.AttachRemoteCDROM(ticket.Host, _ticket.Port, _ticket.VMCfgPath, _ticket.Ticket, _ticket.Ticket, _cdNode, true, false, true, ISOPath);

So most of the params come from the Mks session alloaction by VI. The cdNode is the compsite Id and you know the rest.

How about that?

J

[fhoffmann]

Short explanation: The ESXData is an object from my ESX-Class. It just contains all neccessary data to connect to an esx-server (ip, port, username+pwd and the VimAPI ServiceRef etc.

For the connection I used the normal root-account and also tried the ticket data from a AcquireMksTicket, but none of it worked.

Perhaps I just need the "cdNode" value (an example), or is it the string correct I typed before?

Ahh, this problem gets on my nerves...

Florian

[jrackliffe]

Not sure what to tell you. Now I use the Acquire against a VC and not the direct Host, but that shouldn't matter.

I took a look at a couple of VM examples and all came out to as I noted before where the deviceNode is "ide0:0" and the mks ticket works w/o issue.

Do you have the COM objects registered on the client you are running the final code?

J

[fhoffmann]

Currently I just run the Software directly on my develop-pc.

The VI-Client is installed and the WebAccess has been visited (so the ActiveX plugin is installed).

So I don't think that the lib isn't registerd correctly.

I think I try some other combinations, like an other esx-host or other iso-image..

Florian

[jrackliffe · Accepted solution]

K thought of a couple other things.

1) When you instance the Mks control in the code how does it look? Mine looks like this... QuickMksAxLib.IQuickMksAxCtl _mks = new QuickMksAxLib.QuickMksAxCtlClass();

I never really got into COM, but from past experience the Interface is the access.

2) Did you setup your VM with the proper backing info? I use VirtualCdromRemotePassthroughBackingInfo, deviceName = Empty string and exclusive = false.

I just wrote a simple console app in two lines that was successful, this is what I did

1. Added ref to the QuickMks class from the COM tab in VS references

2. Instanced MKS as noted above

3. In MOB I Invoked the AcquireMks method

4. Used the params returned to fill out the AttachRemoteCDROM method

5. Set my VM to use Client Device and Passthrough (no exclusive) in VI Client

6. Called Attach method

7. Leave Form open as the session will close when MKS instancing process ends

After call I had a happily mounted ISO. Now the steps above are codable, but for testing this might help.

J

[fhoffmann]

Thanks for the steps, there are some differences with me.

1) In VisualStudio (2005) I added the QuickMKSCtrl with the Toolbox, so i can simply drag & drop the mks-window into my applications.

The VS automatically added the code (and references) to interop with the com-object:

<----

---

>

private AxQuickMksAxLib.AxQuickMksAxCtl axQuickMksAxCtl1;

System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(mksctrl));

this.axQuickMksAxCtl1 = new AxQuickMksAxLib.AxQuickMksAxCtl();

((System.ComponentModel.ISupportInitialize)(this.axQuickMksAxCtl1)).BeginInit();

this.axQuickMksAxCtl1.Dock = System.Windows.Forms.DockStyle.Fill;

this.axQuickMksAxCtl1.Enabled = true;

this.axQuickMksAxCtl1.Location = new System.Drawing.Point(0, 0);

this.axQuickMksAxCtl1.Name = "axQuickMksAxCtl1";

this.axQuickMksAxCtl1.Size = new System.Drawing.Size(374, 324);

this.axQuickMksAxCtl1.TabIndex = 0;

this.splitContainer1.Panel1.Controls.Add(this.axQuickMksAxCtl1);

((System.ComponentModel.ISupportInitialize)(this.axQuickMksAxCtl1)).EndInit();

<----

---

>

There are some unimportant parts included, but that's the hole init-process.

2) I connect the console to the vm:

ESX_Data = new ESXConLib.ESX(esx_ip, esx_port, esx_user, esx_pwd, esx_dc);

ESXConLib.MKSTicket ticket = ESXConLib.ESXTasks.AcquireMksTicket(ESX_Data, vmname);

this.mksctrl1.ConnectToVm(ESX_Data, ticket);

▼

public void ConnectToVm(ESXConLib.ESX ESX_Data, ESXConLib.MKSTicket ticket)

{

string hostname = null;

int authPort = 0;

if (string.IsNullOrEmpty(ticket.Host)) { hostname = ESX_Data.IPAddress; ;}

else { hostname = ESX_Data.IPAddress; }

if (ticket.Port == 0) { authPort = ESX_Data.Port; }

else { authPort = ticket.Port; }

this.axQuickMksAxCtl1.connect(hostname, authPort, ticket.cfgFile, ticket.Ticket, ticket.Ticket);

}

3) Attach the Image:

this.mksctrl1.AttachRemoteCDROM(ESX_Data, ticket);

▼

public void AttachRemoteCDROM(ESXConLib.ESX ESX_Data, ESXConLib.MKSTicket ticket)

{

string hostname = null, vmCfgPath = null, username = null, password = null, deviceNode = null, localDevicePath = null;

int authPort = 0;

bool rawDevice = false, exclusiveDevice = false, imageISO = false;

if (string.IsNullOrEmpty(ticket.Host)) { hostname = ESX_Data.IPAddress; ;}

else { hostname = ESX_Data.IPAddress; }

if (ticket.Port == 0) { authPort = ESX_Data.Port; }

else { authPort = ticket.Port; }

if (string.IsNullOrEmpty(ticket.cfgFile)) { vmCfgPath = "empty"; }

else { vmCfgPath = ticket.cfgFile; }

if (string.IsNullOrEmpty(ticket.Ticket)) { username = ESX_Data.Username; }

else { username = ticket.Ticket; }

if (string.IsNullOrEmpty(ticket.Ticket)) { password = ESX_Data.Password; }

else { password = ticket.Ticket; }

deviceNode = "ide0:0";

rawDevice = true; // I tried true and false

exclusiveDevice = false;

imageISO = true;

localDevicePath = @"E:\bootimage.iso";

Console.WriteLine("Is connected before: " + this.axQuickMksAxCtl1.IsRemoteDeviceConnected(localDevicePath).ToString());

Console.WriteLine("Try to connect: " + this.axQuickMksAxCtl1.AttachRemoteCDROM(hostname, authPort, vmCfgPath, username, password, deviceNode, rawDevice, exclusiveDevice, imageISO, localDevicePath));

Console.WriteLine("Is connected after: " + this.axQuickMksAxCtl1.IsRemoteDeviceConnected(localDevicePath).ToString());

}

Florian

[fhoffmann]

Ooookkkkayyy...

I'am (just) a little bit confused...

It works!

I created a simple project, added the QuickMks by hand (and created an object to the interface), invoke an ticket and mounted my image.

Back in the vi-client I restarted the vm (with , out of the bios) and the boot-cd were there.

I do not know why it's work exactly, I can just estimate that the way the VS included the com is not compatible with accessing local files.

Never mind!

Thanks for your help!!

Florian

Edit1: So, I think I found the error.

On most developer-machines are 2 com-objects for mks.

One from the VI-Client and one from the WebAccess.

The WebAccess has the newer version (2.1) and seems to be the source of the problem.

In my new Lib i used the dll that comes with the vi-client and it works. In my old project I used the WA dll, which made nothing.

I still have to proof it by changing the dll in my current project to the wa-dll, but I think thats the problem.

[jrackliffe]

Yeah instancing COM+ I have always found is just a bit flaky. Again, probably that is from my lack of depth in the underlying technology, but cest la vie.

Glad to hear that it is working and again I don't know if you work with a company that has a support contract, but make sure to file an RFE on getting a supported library set for client MKS work. It should be much easier when this is a supported model than the current smoke and mirrors it is today.

J

[fhoffmann]

I fully agree with you.

Our company will have a support-contract in january.

And then I will make a mks-support request.

By the way, I dont think the problem was COM but rather the "wrong" library.

Florian