Mark Syms
-
Posts
296 -
Joined
-
Last visited
-
Days Won
8
Content Type
Forums
Articles
Labs
Videos
TechZone
Citrix Community Articles
Events
Profiles
Posts posted by Mark Syms
-
-
Xenbr is where the IP address should be, this is the virtual network bridge which permits sharing the network links between the Hypervisor control domain and the Guest VMs.
If you can login then you can run `lspci -vvv` to confirm that your Network Card is being seen.
-
I don't think this is terribly surprising, you've added another layer of latency to the system in the intermediate VPLEX system so the hypervisor's IO path becomes
Hypervisor -> VPLEX -> XtremIO -> VPLEX -> Hypervisor
and, as the hypervisor always uses DIRECT IO with FORCE UNIT ACCESS (FUA) to ensure that data written is committed to the storage before the IO is confirmed to the VM and thus avoid some of the more common causes of VM data corruption this latency becomes significant. Additionally if the VPLEX adds more latency through processing time of pushing the data to clustering backend then that will be an additional source of slowness over and above that added as a result of the additional interconnect hops.
Whether the VPLEX can be safely configured to complete the response back to the caller before it has completed the IO to the backend storage tiers would be a question for Dell but it would require a significant amount of non-volatile or battery backed memory to be even remotely safe and even then there are risks associated with the backend tiers going down/losing contact and the VPLEX being unable to flush.
-
This means that the VM is continuously writing data to its virtual disk at a rate faster than the garbage collection process can consolidate the data into the parent node in the VHD tree. As you can see the GC has several attempts and then gives up marking the VDI as not leaf coalescable.
As the GC process has to read data from one VHD node and write to another it is unfortunately quite common that a VM with a moderately high IO throughput will win the race as that only has to write data to the disk and not perform the secondary read.
-
As Alan says, just because you've deleted the snapshots it does not mean that the space can be freed. In order to free the space for the snapshot the parent and sibling nodes (to the deleted snapshot) in the tree have to be merged together. This means copying data from the child into the parent and may require the size of the parent to be increased in order to accommodate extra data blocks which are not present in the parent. Once the parent is a complete superset of the data in the child node the child becomes redundant and can be removed, releasing the storage space used by the child.
-
1
-
-
That is the solution and the only supported way to attach an ISO to a VM.
-
As far as I know (but I'll go and check) there's nothing in Multipath Boot from SAN which precludes using the Rolling Pool Upgrade wizard. If there is that IMO that's a bug and we should fix it.
-
You may need to apply an updated driver disk as part of the installation process, see https://support.citrix.com/article/CTX257603/driver-versions-for-xenserver-and-citrix-hypervisor, in particular there is a new mlx driver - 5.4-1.0.3.0. We have actually seen exactly this issue internally with some new hardware that should in theory have been supported by the in-box not upgraded driver but which did not work until we added the updated driver.
-
The reason these hosts are not on the Citrix Hypervisor HCL (or at least one reason) is that the Intel CPUs in them are EOL and no longer supported by Intel, which means that they no longer make Microcode Security Updates available for them. So, you need to be consciously aware of the risks that this may introduce to your environment and workloads running on the hosts, in particular Speculative Execution flaws in the CPUs may not be mitigated either in firmware or software.
-
1
-
-
I assume you're trying to ingress through a firewall to allow the Windows UI to run on the otherside of the firewall to where the hypervisor is located. Unfortunately you can't change the ports here as redirects would end up sending you the wrong port. Whether you can set a different virtual host on the firewall so that there are two different things exposing 443 based on the specific virtual host that is connected to would depend on the specific firewall system/application and whether it supports doing that.
-
Don't export the VM, use the Citrix Hypervisor Conversion Manager - https://docs.citrix.com/en-us/citrix-hypervisor/8-2/conversion-manager.html
-
Thanks for that update Jeff, I'll take that to the planning team.
You should note that XenServer 7.1 CU2 goes End of Life and End of Support in 1 week from today after which time no further security fixes will be released for it. So, that upgrade evaluation needs to get hurried up or your customers are going to be running on unsecure systems. We are aware that there will be more Security Fixes to Citrix Hypervisor 8.2 CU1 in the coming months as security researchers discover new novel ways to exploit CPU hardware speculative execution vulnerabilities and these issues will now only be fixed on Citrix Hypervisor 8.2 CU1 and Citrix Hypervisor 8 Cloud edition.
Mark.
-
Of the three Linux versions you list two of them should be HVM already. Ubuntu 12.04 is now so long out of support that you should destroy that VM and install an in support version.
-
There is no free version of Citrix Hypervisor, a license is required for all usage.
-
As Tobias says, it's not supported to install anything into the Hypervisor control domain and it will definitely void any support you have and has a high chance of causing your VMs to fail, up to and including total data corruption of the VM data storage.
-
Jeff,
If you're willing, we'd like to get more input from you and also do bi-directional feedback on the concerns that your customers may have and feed that into any future plans for new versions. Ideally I guess we'd like to make it so that they were comfortable taking a cloud management plane for the on premises component but that may of course not be possible depending on the exact reasons and problems they see with doing that.
Thanks,
Mark.
-
13 hours ago, Jeff Berntsen said:
Will there be future releases of Hypervisor supported for on-premises-only installations or will 8.2 CU1 (or 8.2 with some future CU) be the last? I have several clients in high security environments where cloud-based anything is forbidden.
It is likely that Citrix Hypervisor 9 when it happens will have an on-premises LTS version but those plans are not yet in place.
-
There is also a dedicated forum for the Preview release - https://discussions.citrix.com/forum/1840-citrix-hypervisor-8-cloud-release-tech-preview/
-
Not in any great detail, it's being worked on but we do not currently have any publicly disclosable dates for release, it almost certainly will first be made available in the new Citrix Hypervisor 8 Cloud edition.
-
Citrix Hypervisor Engineering are delighted to invite you to partake in the Citrix Hypervisor 8 Cloud Public Preview
https://www.citrix.com/blogs/2022/08/02/the-power-of-citrix-hypervisor-is-coming-to-the-cloud/
-
Was the CentOS NFS server also affected by the power outage? Has it actually restarted the NFS service after coming back up or does it have an error on it?
-
XenServer 7.0 is long out of support and didn't ever support those AMD CPUs.
-
Nested virtualization is categorically not supported with Citrix Hypervisor and will very likely eat your data and/or crash your hosts.
-
When a VM is initially created it is associated with a single VDI (on all but GFS2 this is a VHD file or a VHD formatted logical volume).
After taking a snapshot the current VDI for the VM is truncated to the smallest size required to contain all the "dirty" blocks that have been written (this may be bigger, sometimes significantly bigger, than the "used" space in the VM) and a new delta VDI is created for new writes to be written to. Technically the snapshot size is the size of the read-only piece as that is what you get if you, for instance, clone from snapshot. The size of the delta VDI depends on the SR type. For block LVM SRs (local LVM, LVM over iSCSI, LVM over HBA, LVM over FCoE) delta VDI will be the full size of the disk allocated to the VM to permit the VM to write to any block in the disk without needing to dynamically resize the logical volume. For file based SRs (Local ext, NFS, SMB3, GFS2) the size of the delta VDI will be just what is required to contain the data that the VM has written since it was created and it will grow on demand as required potentially up to (but not more than) the full size of the disk allocated to the VM.
With a single snapshot the worst case is that 2x full disk size storage is consumed for the VM and for LVM there is never less than 100% full disk size consumed. Scale this dependent on the number of snapshots for the VM.
HTH,
Mark.
-
As Tobias says, the garbage collection system needs some free working space to permit the VDIs to be merged, temporarily you will end up with 8d2130bb being the superset of the data in 8d2130bb and the data in f908a214 and then f908a214 can be deleted once it's no longer required.
SR Storage Expand
in Storage
Posted
Loai,
That looks like a bug in the code for the Storage Management layer. The 1200 error indicates that a low level error occurred but nothing handled it until the process exited. There should be more details in the /var/log/SMlog file or you can raise a support request.
This is functionality which is expected to work so even if you don't have support please see if you can find the log data and post it here so that we can look at it.
Thanks,
Mark