-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IsardVDI in a Microsoft Active Directory Domain Integrated Client Environment #370
Comments
What exactly do you mean with 'outside the working range of the subnet'? In another net? The default network is NAT'ed. You can set another range by editing the default net in the hypervisor (virsh net-edit default) or even editing it in docker/hypervisor/networks/default.xml and building your hypervisor in that net if that solves your problem, but I think this is not the case. I think you want IsardVDI guests to get IP's directly from your physical network. Is this your case? To get this scenario I think you could add a macvtap interface to the hypervisor and create a new xml network bridged to that interface. This is a little bit more complex but can be done. Also you can just move a host interface inside isard-hypervisor container namespace using pipework. |
Hello If my subnet is for example 10.85.X.Y mask 255.255.0.0, -I have several subnets- the dhcp server give to the clients ips of the range 10.85.7.1 - 10.85.7.254 I would not mind having my IsardVDI clients with IPs provided by the existing DHCP in my subnet, how to assign IPs from the range 10.85.6.1 - 10.85.6.254 to IsardVDI clients and that these are assigned by IsardVDI Maybe I would prefer this last option With this "What exactly do you mean with 'outside the working range of the subnet'? In another net?" I mean that my "physical clients" have IPs of the subnet 10.85.7.1-10.85.7.254 (DHCP) and my IsardVDI client are assigned IPs of the type 192.168.1.X |
Let me do some tests with this before giving a final solution. It could be done by creating a bridge on the host and mapping it inside the isard-hypervisor container. Another solution would be to use pipework to just get the host interface inside the container. In your setup, the host has a network interface that can be used to directly pass it through the isard-hypervisor container? |
Hello Of Course. Take the time you need. Regarding your question. I don't sure I understand it. My test environment, it's a installation with ESXi server inside a VM with Ubuntu 20.04 The docker VM actually have a single network interface, but I can assign a second network interface to the VM if it was convenient. Thanks |
Yes! Now there is a pipework container that puts one interface directly inside the hypervisor container and you can play with it. It should be defined in isardvdi.conf:
|
Hello. Thanks for the information and added of this feature. Can be included something of this subject at the documentation with any example? |
Hello I try to search the file isardvdi.conf or isardvdi.cfg, but it's not found. Where is located this file? Thanks |
Hello. The file isardvdi.cfg.example is inside a container? I can't find the location of the file isardvdi.cfg.example in the documentation. Thanks in advance |
Would it be possible to implement a parameterization at the IsardVDI configuration level of the IP range of the clients?
The problem is that when working in an Active Directory environment, having clients with IPs outside the working range of the subnet implemented in the domain has some side effects.
It is not the same concept that your client computer takes an IP of the type 192.168.1.X and with it, through VPN, it is allowed to connect to a remote server or to a computer in the corporate subnet, as it is the client integrated in AD, the one that takes an IP outside the range of the subnet, which is what currently happens with IsardVDI, if we want the desktops to be integrated into an AD domain, which is within the range of the host.
Has anyone implemented IsardVDI and client computers integrated in an Active Directory Domain?
The computer accounts are created in the domain, the software installation gpo directives are applied, etc., but for example, once they are restarted, they take a long time to start up, I think because it remains in logon processes, until it gives a timeout
The text was updated successfully, but these errors were encountered: