@olivierlambert That is wonderful news. We actually will be closer to a 1.2:1 or 1.1:1 ratio of vCPU's per physical core - our hosts are old beasts, but we don't work them hard. We had some 10 or 12 VMs on one while it was running VMware (DURING our migration, so a it was running more than it normally did) and it was consuming maaaaaaybe 30% of the available CPU power. There really aren't that many of us.

We are probably not going to purchase XCP-ng Pro Support, but we absolutely WILL be purchasing a Xen Orchestra subscription at the Starter tier. I think it hits all the features we need, it gives us a real support contract for our virtualization solution, and it is our great honor to support an open-source project!

Thanks for answering my question. Hopefully it's helpful in answering someone else's out there on the internet.

@fohdeesha Okay, so I had a bit of an adventure there (oddly, setting my management interface to the VLAN interface did not seem to work - even after doing an xe pif-reconfigure-ip command to make sure I was set to the correct IP and all that jazz - but that may have been because I set the trunk port to natively carry that VLAN's traffic without tagging).

Still, now XOA seems to be unable to connect. I can GET to my XOA instance, but I cannot see my list of VMs or networks or anything - my XOA seems to be unable to connect to my host. It says, "Some XenServers have been registered but are not connected" and when I go in there, I SEE my host, but I cannot connect to it. There's a scary red triangle and it says "connect EHOSTUNREACH 192.168.1.100:443".

I almost wonder if XOA is sending tagged packets and the host isn't...

EDIT: wellp, nope. I have SSH access to the host, and I just checked to see if maybe I had the XOA VM hooked up to one of the VLAN-ish interfaces and the host hooked to the actual main interface... they are both connected to the same interface, yet they absolutely cannot ping each other. They're on the same subnet! I'm annoyed. More digging.

EDIT AGAIN: HMMM I just disabled switchport trunk native vlan x on the switch and replies started coming right back in once I had switched the node to the VLAN X PIF. I have rebooten it - presumably I need to put XOA on that PIF now! Will report back.

EDIT AGAIN AGAIN: omg you guys use the google blobs as emoji here... my whole heart

EDIT FINAL: yep, okay, I found some issues with my config but for some reason my XCP-ng host and Xen Orchestra simply refuse to talk to eachother. I know I'm getting the right IP address, and I know I'm getting the right username and password - and yet, I still get that "connect EHOSTUNREACH 192.168.1.100:443" error. I HAVE figured out how to get things to properly route while on VLAN PIFs now (static routes! hooray!) but the XCP-ng host and Xen Orchestra are both on the same network and everything, and I cannot get Xen Orchestra to connect to the XCP-ng host.

EDIT FOR REALSIES FINAL: ...

...and then I rebooted XOA and everything fixed itself. Neat.

@fohdeesha This is absolutely fantastic. Thank you.

@borzel Does this still work with current versions of the guest tools?

@olivierlambert I did check there... and... am apparently blind, and it is like the third option down. >_<

@olivierlambert wait, but doesn't that just change the number of vCPUs allocated to the host?

Pretty much as the title says - I have a couple VMs that I might like to prioritize CPU performance for, is there any way to change this post-creation in Xen Orchestra, or is this something I'd need to do in the xe CLI?

Hey all -

I'm trying to setup a UEFI-based Windows Server 2019 Standard x64 server to test Remote Desktop Services on a newer platform (then we needn't worry about the best Guest Tools for Windows Server 2008 R2!), but I get an error message, VDI_MISSING . I don't understand why, I've created VMs like this before, and it's worked fine. I even tried deleting the associated 80 GB disk and recreating it, but nope - same error. I don't get it.

Worth mentioning: I tried this with both the latest stable (5.64.0) and a recent... er, latest (5.65.1).

vm.start
{
 "id": "50516f0f-8459-8548-5ee3-42197e438f4d",
 "bypassMacAddressesCheck": false,
 "force": false
}
{
 "code": "VDI_MISSING",
 "params": [
   "OpaqueRef:4510e18f-14fb-4003-b4c7-4081bd6d1e6d",
   "OpaqueRef:8f2ea38e-6bef-41f4-9f85-73e02ee44ec6"
 ],
 "call": {
   "method": "VM.start",
   "params": [
     "OpaqueRef:b4f01459-4414-40ff-8f91-b742f3cfe4e9",
     false,
     false
   ]
 },
 "message": "VDI_MISSING(OpaqueRef:4510e18f-14fb-4003-b4c7-4081bd6d1e6d, OpaqueRef:8f2ea38e-6bef-41f4-9f85-73e02ee44ec6)",
 "name": "XapiError",
 "stack": "XapiError: VDI_MISSING(OpaqueRef:4510e18f-14fb-4003-b4c7-4081bd6d1e6d, OpaqueRef:8f2ea38e-6bef-41f4-9f85-73e02ee44ec6)
   at Function.wrap (/usr/local/lib/node_modules/xo-server/node_modules/xen-api/src/_XapiError.js:16:12)
   at /usr/local/lib/node_modules/xo-server/node_modules/xen-api/src/transports/json-rpc.js:41:27
   at AsyncResource.runInAsyncScope (async_hooks.js:197:9)
   at cb (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/util.js:355:42)
   at tryCatcher (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/util.js:16:23)
   at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:547:31)
   at Promise._settlePromise (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:604:18)
   at Promise._settlePromise0 (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:649:10)
   at Promise._settlePromises (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:729:18)
   at _drainQueueStep (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/async.js:93:12)
   at _drainQueue (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/async.js:86:9)
   at Async._drainQueues (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/async.js:102:5)
   at Immediate.Async.drainQueues [as _onImmediate] (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/async.js:15:14)
   at processImmediate (internal/timers.js:464:21)
   at process.topLevelDomainCallback (domain.js:147:15)
   at process.callbackTrampoline (internal/async_hooks.js:129:24)"
}

@fohdeesha Okay, so I had a bit of an adventure there (oddly, setting my management interface to the VLAN interface did not seem to work - even after doing an xe pif-reconfigure-ip command to make sure I was set to the correct IP and all that jazz - but that may have been because I set the trunk port to natively carry that VLAN's traffic without tagging).

Still, now XOA seems to be unable to connect. I can GET to my XOA instance, but I cannot see my list of VMs or networks or anything - my XOA seems to be unable to connect to my host. It says, "Some XenServers have been registered but are not connected" and when I go in there, I SEE my host, but I cannot connect to it. There's a scary red triangle and it says "connect EHOSTUNREACH 192.168.1.100:443".

I almost wonder if XOA is sending tagged packets and the host isn't...

EDIT: wellp, nope. I have SSH access to the host, and I just checked to see if maybe I had the XOA VM hooked up to one of the VLAN-ish interfaces and the host hooked to the actual main interface... they are both connected to the same interface, yet they absolutely cannot ping each other. They're on the same subnet! I'm annoyed. More digging.

EDIT AGAIN: HMMM I just disabled switchport trunk native vlan x on the switch and replies started coming right back in once I had switched the node to the VLAN X PIF. I have rebooten it - presumably I need to put XOA on that PIF now! Will report back.

EDIT AGAIN AGAIN: omg you guys use the google blobs as emoji here... my whole heart

EDIT FINAL: yep, okay, I found some issues with my config but for some reason my XCP-ng host and Xen Orchestra simply refuse to talk to eachother. I know I'm getting the right IP address, and I know I'm getting the right username and password - and yet, I still get that "connect EHOSTUNREACH 192.168.1.100:443" error. I HAVE figured out how to get things to properly route while on VLAN PIFs now (static routes! hooray!) but the XCP-ng host and Xen Orchestra are both on the same network and everything, and I cannot get Xen Orchestra to connect to the XCP-ng host.

EDIT FOR REALSIES FINAL: ...

...and then I rebooted XOA and everything fixed itself. Neat.

@fohdeesha This is absolutely fantastic. Thank you.

Hey all -

First I thought I'd like to say that I'm loving Xen Orchestra, thanks for making such a wonderful product that competes so strongly with VCenter.

Secondly: My pool host (only one, at the moment) is connected to our network just fine, but I need to change the type of port that it's connected to from a basic "access" port (that lets it talk to just ONE VLAN) to a trunk port (that lets it communicate to many). In order to do this without breaking my connectivity to the host (and Xen Orchestra), I need to set the "management" network to the PIF which will tag the packets with the appropriate VLAN / subnet.

I don't see any obvious way to do this in Xen Orchestra... am I missing something? Do I need to do something via the xe command?

Hi all -

We're continuing our exploration and testing of XCP-ng and Xen-Orchestra, and we're so far really liking it. We are running into some difficulty moving away from VMware in that, namely, a LOT of backup solutions are:

1. VMware aware, and
2. Support tape backup.

These are by no means dealbreakers, we like Xen enough (and are saving sufficient money by migrating to it) that, if needbe, we can re-architect our backup system such that we work our way around it. One thing we considered was setting up an additional host with some NFS shares, and having Xen-Orchestra backup to that host, and then having our normal backup system suck up those backup images and plop them onto the tapes.

Still, IF there's a more elegant solution (we are currently using a sufficiently old version of Veritas NetBackup that yearns for the sweet kiss of death) that works for XCP-ng, as well as other servers and workstations, AND supports tape drives (specifically, a Dell PowerVault TL2000), I'd love to know!

What are you XCP-ng and Xen-Orchestra users using in your production environments for backup?

@olivierlambert That is wonderful news. We actually will be closer to a 1.2:1 or 1.1:1 ratio of vCPU's per physical core - our hosts are old beasts, but we don't work them hard. We had some 10 or 12 VMs on one while it was running VMware (DURING our migration, so a it was running more than it normally did) and it was consuming maaaaaaybe 30% of the available CPU power. There really aren't that many of us.

We are probably not going to purchase XCP-ng Pro Support, but we absolutely WILL be purchasing a Xen Orchestra subscription at the Starter tier. I think it hits all the features we need, it gives us a real support contract for our virtualization solution, and it is our great honor to support an open-source project!

Thanks for answering my question. Hopefully it's helpful in answering someone else's out there on the internet.