Konrad Ruess
-
Posts
36 -
Joined
-
Last visited
Content Type
Forums
Articles
Labs
Videos
TechZone
Citrix Community Articles
Events
Profiles
Posts posted by Konrad Ruess
-
-
You might try to boot the Win7 into rescue mode / safe mode and then remove all Xentools traces, especially the "upperfilter=xenfilt" occurences in the registry (hklm\system\currentcontrolset). I got best results by using RAPR driver store explorer to remove the drivers. If all those drivers are fully removed, it should - in theory - come up with the windows 7 basic drivers for the disks.
BfN, -k
-
Hi guys,
I know this is quite an old thread, but I was fighting with the BSoD "INACCESSIBLE_BOOT_DEVICE" for quite a while, too. But lately, I struggled over a way to solve this problem during upgrades (ie. LTSC 1809 -> 21H2). Here my steps to succeed:
*) download and execute RAPR tool and perform forced deletion of all xen drivers
xenbus.inf might require a 2nd attempt to get it off the system
*) uninstall the XenTools / XenAgent
NO reboot at this moment!
*) delete any remaining 'upperfilters = xenfilt' from registry (hklm\system\currentcontrolset)
*) not necessary, but worth to clean up
net stop xenagent && sc delete xenagent del %systemroot%\system32\xen*.* del %systemroot%\system32\drivers\xen*.*
*) reboot
*) perform the Windows upgrade from .iso
*) reinstall the xen agent & drivers
I hope, this helps others to get ahead on this topic.
BfN, Konrad
-
Hey guys,
I know, it's a bit late, but I had this issue with XenCenter stating "Management Agent not installed" after I switched an older Ubuntu 18.04 LTS from PV to HVM. All was well before the switch.
Comparing the metadata to a freshly built Ubuntu 18.04 from the latest Ubuntu template (16.04 in my case with XenServer 7.1), I stumbled over these settings that were different. Changing them accordingly on the guest did the trick:
xe vm-param-get uuid=<vm-uuid> param-name=platform
I've had to switch these ones after stopping the guest VM:
xe vm-param-set uuid=<vm-uuid> platform:nx=true xe vm-param-set uuid=<vm-uuid> platform:viridian=false xe vm-param-set uuid=<vm-uuid> platform:acpi=1 xe vm-param-set uuid=<vm-uuid> platform:device_id=0001
A boot later, all was just fine. ?
So, the problem most probably was that the guest VM contained some old settings form an ancient template used to create the VM in the beginning, that never changed to the more modern settings. I hope this helps others in the same situation.
BfN, Konrad
-
Hey Ryan & welcome to the forums!
Sorry, a bit late, but I was just dealing with similar issues in my environment and stumbled over your thread here. May it help someone else to solve that.
If the guest OS is mentioning missing management tools after the switch to HVM, it might be because some platform settings are missing due to an older template being used while setting up the guest OS initially. Check these:
xe vm-param-get uuid=<vm-uuid> param-name=platform
In my case (Ubuntu 18.04 built loooong time ago) it was one or some of the following:
xe vm-param-set uuid=<vm-uuid> platform:nx=true xe vm-param-set uuid=<vm-uuid> platform:viridian=false xe vm-param-set uuid=<vm-uuid> platform:acpi=1 xe vm-param-set uuid=<vm-uuid> platform:device_id=0001
Bfn, Konrad
-
This reminds me of the bug where the OS was collecting thousands of subkeys within HKCU. We've corrected it by cleaning it up on logoff of each user:
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\UFH\SHC" /va /f
BfN, Konrad
-
Hey guys,
I've installed ThinPro 7.2 SP3 few days ago and I have the feeling that it did improve the s(h)ituation. So far, 3 days in a row without wfica hang.
Maybe TP7.1 SP16 brings the same relieve?
BfN, Konrad
NB: SP3 changed the resolution scaling from 100 to 150%, but a registry tweak on the thin client brought all back to 'normal' (users/user/autoscale=0, users/user/desktopScaling=100)
-
I found the following similarities between the freezes:
/tmp/connection-mgr_Web Browser_{<GUID>}.log
[xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. wfica.bin: ../../src/xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. Aborted
So far, all the freezes that I checked this log afterwoods, showed the same lines at the very end of the log file.
-
Hi there,
Same issue here with HP t630 on ThinPro 7.1 and 7.2 and various CWA versions. It happens regardless of the location of the thin client (internet vs LAN). Sometimes, the ‚minimize‘ shortcut works, sometimes it doesn‘t and I have to kill the wfica process on the thin client and perform a reconnect or power-cycle the client. I have the feeling that it is more common to happen during some multimedia activities (video, audio). We have no such reports on non-ThinPro clients.
Has anyone of you already opened a ticket with HP or Citrix on this?
BfN, Konrad
-
I might again not answer your question, but I seriously doubt that this is a) a valid use case for XenServer and b) that they will look at the problem. For a quick dive into another hypervisor, it's most probably sufficient to go without optimised environment and for everything else - IMHO - nesting hypervisors is not the way forward.
Also, you won't find VMware as a base environment for XenServer in the HCL.
-
MTU=8900 is what the HPE MSA's need, larger ones won't work based on my experiences. Besides that I cannot comment as we have not yet upgraded any of the MSA environments to XS 8.2.
BfN, Konrad
-
I'd suggest to go with whatever version of xentools were installed on that guest while residing on XS 7.6.
Latest ones most likely won't like W2008R2, as Alan pointed out.
BfN, -k
-
Hi Lucian and welcome to the forums!
Sounds like an admin's playground setup - so I'd suggest to forget about the vmware tools and go with whatever drivers are available in that setup. Speed will not be a topic for such a layout, anyway - I assume.
BfN, Konrad
-
Hi Marco & welcome to the forums!
Usually - and as Tobias I assume that you are looking at LVMoISCSI - a simple 'rescan' of the SR is sufficient to show the new size.
Otherwise there's another way to do it without having to go 'offline':
Online Resizing:1. Identify the SR Universally Unique Identifier (UUID). > xe sr-list type=lvmoiscsi name-label=<Name of your SR> --minimal 2. Identify the device this SR is using: > pvs | grep <UUID from step 1> 3. Identify the iSCSI target name to rescan: > xe pbd-param-get uuid=$(xe pbd-list sr-uuid=<UUID from step 1> --minimal) param-name=device-config param-key=targetIQN 4. Extract the content of the image > iscsiadm -m node --targetname <targetIQN from step 3> -R 5. Update the Physical Volume size: > pvresize /dev/<device from step 2> 6. Update the SR size: > xe sr-scan uuid=<UUID from step 1>
BfN, Konrad
-
I'd go with smaller systems, too
ie. if you have 2 large ones and one goes down, the remaining one has to take the full load of users, so twice the load. If you have 3 systems, a single system failure will only add 50% more load on each of the remaining systems. Add more systems for even less additional load in case of problems.
BfN, Konrad
-
Hi Peter,
I understand your problem and it would really be nice to have the option to completely hide other users on a shared environment. But unfortunately, there seems to be no such thing. And even if the taskmgr would offer such a feature, there would still be various other ways to grab the other usernames on the system (file system, command line queries, 3rd party tools, etc).
The best you could do: go with something such as personal# instead of ordinary username conventions.
BfN, Konrad
-
Hi Crippen,
1st of all, make sure you have Teams installed in machine-wide mode. Then, add the necessary exclusions to UPM policies. Here are few links with more information:
Citrix - Optimization for Microsoft TeamsBfN, Konrad
-
Wow, what the heck... no mentioning in the docs, but a short KB in the dungeons... :-(
-
Pfüet'di Johannes! :-)
Thank you for sharing your information. So, this does not sound really promising... :-(
The requirements listed in docs.citrix.com are very vague for some hypervisors (from ADC 13.0, but 12.1 looks pretty similar):
- XenServer: in the specific notes, it states that AMD is not supported
- ESXi: it only references Intel-VT, but no explicit denial of AMD
- Hyper-V: It does not explicitely name Intel nor AMD, also no virtualisation technology referenced (AMD-V / Intel-VT)
- KVM: Docs explicitely name AMD-V and Intel-VT as required platform, no unsupported items listed
- Azure: no references to either technology or hardware (but Azure offers both, Intel & AMD metals)
The way it behaves on our infrastructure:
- Management vCPU is running flat out for the 'pitboss' process
- No graceful shutdown possible
- Soon after starting the VPX, no SSH connection is possible, anymore
- Web GUI is still functional
- ADC services are running well (LB, vServer, SF proxy, ICA tunneling)
Interestingly, the Citrix ADM also causes head-aches (sshd terminates quickly after startup, GUI not accessible, 1 vCPU fully loaded), but for that VPX, we cannot find any restrictions regarding AMD EPYC or so.
Bleib gesund, Konrad
-
Hello, I hope everybody is doing well in those crazy days....
Does anyone have any insights regarding the missing support for AMD EPYC CPU's in Citrix XenServer - oops, sorry: Hypervisor?
Is that something that is being worked on? I still can't believe that this support is not given and according to my investigations it's really only applying for XenServer but no other hypervisor.
Any hints, ideas, insights are welcome.
BfN, Konrad
-
Hallo Ralf,
You could try to get some better understanding from what happens by analysing the output of
w32
w32tm /query /peers w32tm /query /status
"peers" will tell you when each peer is being contacted, whereas "status" will tell you more insights about the drift and last sync.
Many of the time sync params can be configured through registry / GPO's.
Details about the current client config:
w32tm /query /configuration
BfN, Konrad
-
Hi Mike,
That sounds for me as if these servers would have a different time source to sync with or different settings such as frequency of sync's. Did you check / compare the time sync config on those systems:
w32tm /query /source w32tm /query /configuration w32tm /query /peers w32tm /query /status
You might also try to observe few systems to see if they jump around or so:
w32tm /stripchart /computer:<your-time-source-fqdn> /period5
and compare it to some other time source such as:
w32tm /stripchart /computer:pool.ntp.org /period5
BfN, Konrad
-
Hi Mark,
Thanks for sharing!
Wow, this does not sound optimistic at all... :-( I wonder what other hypervisors make different to still allow application-aware snapshots, if that's really such a problem? And application-aware backups, ideally agentless, is, what it needs to have a nicely integrated backup solution.
BfN, Konrad
-
Moin Claus-Michael and welcome to the forums,
We are using Bitdefender GravityZone, but without HVI, unfortunately (no support for AMD CPU's, sniff). Based on your description, it sounds more like a problem with the BEST configuration than an issue with HVI, if switching between central scanning and local scanning makes a difference.
Our experience with Bitdefender support are very good - but as your issue is not showing a fully reproducable issue, it is also hard to dig into it.
Are you running HVI on a dedicated HVI appliance or on the same appliances which are also used as security servers (central scanning)?
BfN, Konrad
-
Hey Alan, how's life?
Yeah, the quality and granularity of the management agent release notes is very low. No wonder we struggle with bad guest behaviour just to find out the hard way that there was something changed in the XS agents (ie. time-sync problem lately, performance drops, etc).
I also wonder why they completely removed the support for quiesced snapshots - well, they haven't been 100% reliable, but at least an option. And now... gone.
BfN, Konrad
How to get details behind xe task-list
in Command-Line Interface
Posted
Hey Tobias, absolutely correct! ?
That command will show all params for each currently running task.
xe task-param-list uuid=<task-uuid>
would do the same for one single task.
Unfortunately, the details about a VDI.copy or VM.copy are pretty cryptic...
BfN, -k