Inform to the Guest some Client's ID

Latest response


We are trying to setup a VDI solution in RHEV 3.3.
So far we have make everything works fine, but in our scenario we need to make some change in the software running inside de VM based on the place where the VDI Client is located.

For example:

Let's say we have a VDI Client in the Room A , named room-a.example , in that room we also have a printer ( printer-a.example ).
This client connects to the Windows Pool an got a VM from the pool.
We want to tell the OS inside the VM , some information about the client in order to configure printer-a.example as the default printer inside the VM.

Anyone knows or have an idea about how to pass that kind of information.
I don't care how it's passed, could it be an enviromental variable o some file in inside the VM.

All our VMs runs the RHEV's guest-agent.



I would recommend to open a support case and ask for a new feature request(RFE) to implement this.
Maybe it can be communicated back to the guest agent from the client. But would definitely require an RFE for this.

The VM guest agent does not keep track of connected clients because clients connect directly to the host that the VM is running on. It is possible to get the client IP address from the host for a currently connected client. First, find which host the VM is currently running on. There are many ways to do this, including using the RESTful API. Then, once the host is located, log in and run the following command:

vdsClient -s 0 list vms: | grep clientIp

where is the UUID of the VM. If you used the API to find the host then you already know the UUID. Here's example output:

vdsClient -s 0 list vms:dd9816d8-84cb-4faf-9665-04f1e222f66d | grep clientIp
    clientIp =

Please note that the vdsClient command/API is completely unsupported, so keep this in mind if you decide to build a solution around it.

Maybe consider the Cloud Init / Sysprep function. This can be used to inject scripts into the VM at build. You may have to upgrade to v3.4.n to use this though. (Probably a good idea anyway)