@Honold This may not be a "you" issue. Obviously you're using EID and not Google, but the behavior appears to be the same.
I'll set this up in my own environment when I have time and try it out.
@Honold This may not be a "you" issue. Obviously you're using EID and not Google, but the behavior appears to be the same.
I'll set this up in my own environment when I have time and try it out.
Howdy!!
I figured I'd drop this here for anyone who is looking for a VDI (Virtual Desktop Infrastructure, not the disk one, stupid acronyms) solution that isn't cloud-based or costs an absurd amount. I know that there is a small interest from posts like this, and maybe other victims of Broadcom's (and Omnissa's by extension) pricing will stumble here as well .
I am labeling XBroker as "Virtual Desktop Session (VDS)" as to not collide with Xen's "VDI". Please be gentle with the feedback! This is only my second Python "program" I've ever written, so I'm sure best practice has not been followed .
@nathanael-h Dang, do any of you sleep?! This is pretty much what I need, and would actually significantly improve what I'm building! Will wait_for_ip
be included? As well as the rest of the Terraform logic?
But as you're building a Python script you could implements there the same logic: define a variable for your expected cidr, and poll the IP of the VM until it matches.
Duhh, Why didn't I think of that . Thanks for the help!!
Is there anything similar to this in the xo-cli or API? I don't want to use Terraform or OpenTofu for this, as it significantly complicates the system I'm building.
Right now, I have a Python script that just waits 120 seconds before continuing to make sure the VM gets an IP address via DHCP and is reported properly. My only concern (even with Terraform/OpenTofu) is that Windows returns a 169.254.x.x address to XCP-ng tools almost immediately after fully booting. Is there a way to get around this?
@bleader If we don't have support, what's the best place to report security issues? I submitted one in GitHub about 8 months ago, but I'm guessing it got lost
@raider600 To piggyback off of DanP, they've been very good about extending our trial while we were evaluating our options to migrate off of VMware!
I asked about this in the Discord server a little while ago. To be honest, one of my employers would love Flex vGPU support. We've been needing to update both our general compute and engineering VDIs so we've been looking at some solutions.
While NVIDIA vGPU pricing isn't horrible, it requires us to have VMware infrastructure which is significantly more expensive (obviously). So we'd really like NVIDIA and/or Intel vGPU support, but understand that it isn't just a few lines of code that needs written and is a very small subset of XCP-ng users. Especially with the alleged uncertainty of Intel right now, it may not even be worth developing anything for their cards, but that's personal conjecture.
I've been building my own VDI solution for XO(A), but that's been stalled for a little bit due to burnout, but I plan on finishing a prototype solution and writing a setup guide in a few weeks. So if you want something for just general compute, keep an eye out!
@hansve Since you have shared storage, you should be able to use the "Start on..." feature under the Advanced tab of the VM. That should let you start it on any of the hosts. I'm curious if it will work though because your NIC isn't being detected. You may have to get a USB Ethernet adapter to try and get it to move.
The other option would be to forget the VMs if you can (similar to VMware's "remove from inventory" option). Then create a VM without any disks attached to it, then add the already existing disk to the VM and start it.
I suppose you could do both of them as well. You'd get a USB NIC so you can have networking to the pool (as not to screw with the XAPI DB), then unregister the VMs, create shell VMs, attach disks, then start.
If none of these work, let me know!
@johnd Can you make sure the networks show as "Connected" on the host you're trying to migrate to? I've run into a few issues where I can't migrate VMs after a host reboot because the networks aren't connected
@SudoOracle Can you try recreating the backup job? It won't clean up the previous backups, but it may kick off a new process. Also, (I'm sure you are, but just double checking) are you on the latest XO(A)?
@itnok I'm sure you already have, but have you ensured that everything in this guide was done?
The file is getting removed every time, that's why I was questioning the behavior of the command (whether it is grabbing all records or cached records).
We can do that, but if the user is deleted, that user entry would be gone.
@gtuminauskas Hello! You can edit the template settings by hovering over Home -> Templates -> Find the template you want to change -> click on the 3 lines (menu) button all the way to the right of the template -> click on the field you want to change (in your case RAM), and change the value!
@McHenry If I'm understanding this correctly, Client Site A, B, n... will each have a server and all share multiple instances at OVH for DR. First off, I hope you give the person that's doing the networking for this a raise .
Second, are you and/or a team the sole manager of the infrastructure? If clients have their own IT team that assists/uses XO(A), this will be more difficult. For the sake of this solution, I'm going to assume that the client can use XO(A) to start VMs in case of a DR scenario.
If I were to build it out, I would build an XO host in OVH and utilize the XO-proxy and the Self Service feature. This way, you can register the XO Proxy to all of the client sites, and manage who can see what VMs, networking/VLANS, and storage.
If I'm wrong about an assumption or solution, let me know!
@Danp To execute the command, it's almost instant. To download the file, the same 4ish minutes. I'd also like to note that despite holding a similar 10,000 records, the file becomes significantly longer each run when running the unfiltered command (about 5-10 MiB larger, currently at 610 MiB).
I guess I have three questions now:
xo-cli list-objects type=VM-snapshot
in order to get username of the person who did the snapshot.Before last week, xo-cli audit.getRecords --json
took maybe 30-60 seconds to run. It's weird that it just started in the middle of the week unprovoked.
@julien-f Thank you for the info! After some playing around and some outside help, this is what worked: xo-cli rest --json get -o records.json plugins/audit/records fields=data,event,subject,time,id filter=data:method:vm.snapshot
. However, anytime I run it, it takes about 4 minutes for that command to run (albeit now only downloading about 20 KiB). And with this python, it's going to loop through each XO(A) instance, so some guidance on how to lower this time (or troubleshoot) would be appreciated!
EDIT: The downloading part only takes a second or two, but waiting for the command to execute takes 3-4 minutes
After some playing around, xo-cli rest --json get -o records.json plugins/audit/records fields=data,event,subject,time,id
actually got the records and put them in JSON format. However, I don't need all the records, is there a way to match the 'method' to 'vm.snapshot'? That way I'm not downloading and parsing a 500ish MiB file every time ? I've tried adding
method=vm.snapshot
and event=vm.snapshot
, but neither worked (I'm probably putting it in the wrong spot)
@julien-f It finished with a records.ndjson file of 510.31 MiB. There's been the max 10,000 audit records since I've started, so I can't imagine the size is part of the issue. And yes, the REST API would work, but it was a bit more elegant to have the json loaded in memory rather than get the file first, then load it. Not that it makes a huge difference.
However, now that I'm taking a look at it, all of the "method" fields show "host.isPubKeyTooShort". I'll have to sift through the data to see if everything I need from the records are there.
@olivierlambert That is the output, it times out after a few minutes then spits that out