Okay, this makes sense, thank you for the clarification. The reason I was asking I've been having crazy issues with xcp-ng on my server with VMs crashing all the time on boot etc and have been trying to troubleshoot and just wanted to look into this as I've done every other thing I can possibly think of. thanks again!

Yes, for this generation of CPU, you can't run ESXi superior to 6.5.

@johanb7 I had the same problem in the past with FTDI-based USB device. I could see it in Xen host, but not in VM. I've spent many evenings trying to make it visible in VM, but with no luck though.

I don't know why, but seems that some USB devices won't attach to VM.

@gofm not sure on windows but on linux the walltime is written in UTC to the CMOS when you shutdown or when you explicitly call hwclock command. the time written in the virtualized CMOS should contain an offset to the host clock so when the VM start it read the host time plus the offset. I suppose that if you disable the time sync in windows, set the time and reboot you will come up with a correct clock.
I have no link to point you at, this is just a sum of things I remember but may be dated and/or wrong still if you can reboot your Windows VM could be worth testing.

Hi,

It's because of cache. Check more closely what's displayed in htop.

RC will be out this week (Wed. or Thursday). Mainly minor stuff before going to the release one.

So I don't think you'll have issue with it.

@pnunn Got it....

guest tools hadn't installed correctly.

Manually installed them.. ran the xscontainer-prepare-vm again and now have a container tab on the core OS machine showing the containers running.

P.

I think you've opened a ticket right? Let's see there 🙂

Thanks! Just needed to be 200% sure!

I'm not entirely sure it could work without having serious issues. Maybe nested will be in better shape in 8.1, but it's a known 'thing' that nested virt code is a bit fragile at the moment.

@MajorTom thanks that could be a solution. In the end I moved my single-machine Homelab to Proxmox, because I have way better control in this specific use-case - I can see IOMMU groupings and figure out which USB controller I can also passthrough. And this works fine, I'm posting this from this VM.

XCPng isn't bad, it´s just not suited to my very specific use case.

Cheers,

Clément

Right, if your used is 123.4/128, there seems RAM crunch to migrate anything around 4GB. Can you try migration after freeing up some RAM? Also what version of XCP-NG is being used? There is a known issue related to migration - you can find it on forum.

AMD keeps things simpler for security and performance impact of spectre patches. AMD offers just as much performance in a simpler GPU package. AMD for CPU and AMD for GPU.

Thank You for all your work @olivierlambert

Thanks! Enjoy XO and XCP-ng 🙂

Can you be more specific? I think you are mixing number of CPU inside the machine and visible CPU inside the dom0. Remember, Xen is type 1, the "host" you are connecting into is not the physical host, but a privileged VM.

@rjt
The November 2019 security, bugfix, and enhancement updates address this issue in the section "Enable increasing max_grant_frames for guests."

Indicates that with not enough grant frames, the guest VM will not be able to use the all the virtual NICs that it expects. Still wonder if increasing max_grant_frames would speed up existing network interfaces even when they have enough working vNICS.

@andersonalipio

Since something is up with the API, restarting the xapi toolstack on the host might help.

Do not try migrating the running VM at first, but move to the shared NFS StorageRepository. Then after the VDI is hopefully successfully moved, then try moving the running VM.

Does it move to the other Citrix XS 7 host?

During VM export, the ssh connection is gone and the result is frustrating. the disk of the virtual computer does not appear at all.
Xcp-ng 8.0 use. I think he sent the disk to eternity.

The message was relatively clear (for a XAPI error 😛 😞

This operation cannot be performed because the specified VDI could not be found on the storage substrate
sr: 28a8b360-7b1b-58ca-81b6-f907c164ec38 (XCP-ng Tools)
vdi: b1a7a49a-f17c-42ac-af73-4429eb57b07a (Old version of guest-tools.iso)

This means the VM can't boot with this current CD because it's not there anymore. I suppose you updated your host without ejecting all CDs before. So the old tools CD was removed for the new one, and your VM kept it. So when you tried to boot, it couldn't because it couldn't find the old ISO.