Jump to content

Konrad Ruess

Members
  • Posts

    36
  • Joined

  • Last visited

Posts posted by Konrad Ruess

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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)

  6. 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.

  7. 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

  8. 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.

  9. 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

  10. 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

  11. 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

  12. 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. :57_cry:

     

    Any hints, ideas, insights are welcome.

    BfN, Konrad

  13. 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

  14. 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

  15. 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

  16. 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

×
×
  • Create New...