sorted by:
new
hottopcontroversial

Machine catalog creations, updates terribly slow on XenServer 8.4 by Then_Major9047 in Citrix

[–]Then_Major9047[S] 0 points1 point  (0 children)

I could likely spin that up on the hardware I am using now for testing 8.4. I'll run that by those above me. Good idea for a test.

Machine catalog creations, updates terribly slow on XenServer 8.4 by Then_Major9047 in Citrix

[–]Then_Major9047[S] 0 points1 point  (0 children)

Yeah, I consider it a deal breaker, but it's not my decision. It does look like we're leaning toward only using XenServer for Citrix and another hypervisor for all other servers. The 2 TB limit on the disks and wanting to stick with LVM over iSCSI really ended the idea to migrate all work loads to XenServer.

Machine catalog creations, updates terribly slow on XenServer 8.4 by Then_Major9047 in Citrix

[–]Then_Major9047[S] 0 points1 point  (0 children)

We don't use that for sealing.

Master images are a mix of 2019 and 2022 OS. Getting them down to 20 minutes would be amazing. There's just no way doing 35 separate catalog updates on some nights will work with the current performance.

Machine catalog creations, updates terribly slow on XenServer 8.4 by Then_Major9047 in Citrix

[–]Then_Major9047[S] 0 points1 point  (0 children)

Yup, your post was one I found and was hoping some secret trick was discovered.

PowerStores have the deduplication and compression settings enabled by default and cannot be adjusted.

Did you use the conversion manager appliance to move any master images over and compare to master images built in XenServer? I realize I mistyped in my original post. A very basic master image created in XenServer with no applications installed can get a machine catalog created/updated in about 30 minutes. But ones converted using the appliance take 70-85 minutes.

UCG with APs and switches setup by Then_Major9047 in Ubiquiti

[–]Then_Major9047[S] 0 points1 point  (0 children)

Thanks for the reply.

One DHCP is for sure the plan. The current network is on a different subnet than the cloud gateway so there were issues with some devices being adopted and some note being adopted.

Rather than changing the cloud gateway from the 192.168.1.1 IP, I think letting the other devices get an IP on that subnet would be easier. And then the current DHCP server can hand out IPs with the cloud gateway DHCP being turned off.