@splastunov I realize this thread is old, but I think there is important info to keep connected to this thread for future readers.

The IP locking trick doesn't seem to prevent all traffic -- it only prevents traffic that has an IP that isn't 255.255.255.255 or 0.0.0.0. That is, I can still successfully acquire a DHCP IP even when the IP locking mechanism is engaged. I think this is important for others to know since it doesn't fully isolate VMs like the OP wanted.

UPDATE: Setting the locking mode to "disabled" is what you want -- not "locked". Disabled will drop all traffic; locked simply checks if the set of IPs in the VM is permitted. Source: https://docs.xenserver.com/en-us/citrix-hypervisor/networking/manage.html#vif-locking-mode-states

This is a follow up question to the one I posted on ACL inheritance for network objects.. Essentially, when building a self-service resource set, it isn't obvious whether the included resource set is supposed to override any ACLs, or work in tandem.

For example, if I grant "viewer" rights to the pool, why do I need to provide a set of read-only templates, read-only networks, and read-only SRs? It seems to me that the ACLs should take care of that, and the SS should cover anything I need to provide additional operator or admin rights [i.e. read/write SRs, etc.] (in fact, I don't even know what rights the SS resource set actually confers -- is it admin/operator/something else?)

I feel like I have a fundamental misunderstanding of ACLs and SS. Coming from vSphere, I am trying to emulate an inherited DAC permission model, but the XO ACLs seem too limited (I think having an explicit "deny" ACL would dramatically help here by allowing permission "hole-punching"), and the SS isn't dynamic enough.

Can someone help shed some light on how ACLs and SS work together, if at all?

I've been trying to understand the interactions between ACLs and self-service on XO and it seems somewhat inconsistent for Networks.

I have granted a set of users "viewer" access to the entire pool. I have also constructed a self-service set (I have a different question on the self-service restrictions I will post shortly). However, within the self-service set, unless I provide all of the networks in the self-service set, the user is not able to see the network when building a VM.

In our environment, we build/remove networks via VLANs constantly. Having to go into the self-service set to add/remove these networks is not ideal. I would have thought that the inheritance of the networks via the "viewer" ACL would have been enough. Is this not the case?

I see in the XO docs for ACLs that the inheritance says "pools > hosts > VMs". I thought this was an example (i.e. there are other examples that discuss the operations on VMs as a case-study), but perhaps this is the only inheritance path. Is there a reason that networks might not be included in this model (or for that matter, if "pool" is given "viewer", why can't a user see everything in the pool)?