@olivierlambert I was able to sort out the issue, it has to do with licensing and the fact that we aren't licensed to with "Live Migration" for this ESXi host.
Essentially this inquiry is solved.
@olivierlambert I was able to sort out the issue, it has to do with licensing and the fact that we aren't licensed to with "Live Migration" for this ESXi host.
Essentially this inquiry is solved.
@TechGrips While I can understand the desire to use removable USB as a Backup Repo, I would highly discourage it.
Managing and rotating USB drives is a pain, if they go to sleep, it's a pain, if they fail it's a pain, if you forget to rotate your drives, it's a pain.
I personally can understand the desire to do so, it's cheap and relatively affective if you can deal with these risks, however so is just using any NFS or SMB share and then having a replication script that could write to your USB, which you could then rotate. Separating your XCP-ng hosts, XO, and your backups is of critical importance because if you have any sort of server room environmental issues or failure, you're risking loosing everything.
XCP-ng and Xen Orchestra, while they do offer a ton of flexibility, there is obviously trades-offs to using less than ideal components, such as external USB drives as your primary backup repository.
If you really want to insist on using USB drives, you'll have to attach the drives to your host and then pass them through to your XO installation, which when you want to rotate those drives you'll have to update your Backup jobs within XO and confirm that your XO VM has the proper access to the drives. This seems like a lot of complexity for very little financial benefit.
Separately I think you're taking your own frustrations out on the community, because of a lack of understanding in the tooling that you testing in comparison to ESXi where you'd attach a USB drive directly, perform your backup, remove the disk and attach another.
I get that ESXi can make things "simple" but simple isn't always better.
HTH
The reason you wouldn't want to look at XO for this from a technical standpoint is because XO works at the hardware level of the hypervisor, dolling out resources to different VMs and creating backups.
You need to look at the content within a given VM and compare the file system difference from points A and B.
Only something that is operating within the file system would be able to readily tell you "Something has changed".
Odds are you have a user or several who are dumping files onto a share that they shouldn't be, or are replicating some cloud service to keep a copy on your server etc.
If I had my choice, Prevent Migration is more understandable.
Disable Migration, while it means the same thing, doesn't naturally come out of the English language.
@flakpyro said in How to migrate XOA itself?:
@DustinB Are the any downsides to having two XOA instances pointing at the same pool? Since the config itself is stored at the pool level im guessing theres no downside?
IE: Priimary XOA running in core DC and secondary XOA running at your DR site. Is it just a matter of adding the pool on the secondary XOA and it downloads the existing config or did you need to do a full export / import?
If you import your configuration, each XO instance will think they should be running the backups as far as I've noticed. If I have two instances running with the same configuration, I simply disable the backup jobs on one of them.
The config file is just an XML that contains your existing instance. You can import it to any new XO instance and have the same exact configuration.
@olivierlambert I agree wholeheartedly with you on that. Keeping the system stock is best for support.
Separately, is there any planned work on officially integrating support for Uninterruptable Power Supplies and XCP-ng 8.3?
A question
You can disable all of the boot devices in the Advanced section of the VM, try disabling the HDD
Disable the Boot options if your system is making it past POST to quickly so you can get into the Guests BIOS.
@jasonnix said in A question for the creators of XO:
Hi @olivierlambert,
No, I'm not a bot. I asked it because I need your experiences. I want to make a panel for Xen.
So you know how to program with PHP and Ruby and not with Javascript, so the question is really "Why can't this be rewritten so I can help?"
For laughs I am testing with a VM that is powered off and its going, albeit slowly (likely due to a 10FDx port on the ESXi host).
This topic wasn't meant to focus on XCP-ng or XOA, but an entire ecosystem that is your network. While I routinely check my network for vulnerabilities and often am squashing said vulnerability XCP-ng is a different system entirely since it shouldn't be hardened by hand but by the developers through routine patching.
The question that I'm asking here is how does the Vates Team evaluate these vulnerabilities, Qualys, Greenbone, something else?
Is the Vates team open to the community reporting these vulnerabilities openly or would a ticket be best?
@kagbasi-ngc I think you'd have to configure some kind of log shipping ahead of time, I don't know that you'll be able to migrate the logs from one XO to another to keep things consistent.
@davx8342 That's a ton of storage, holy cow!
So two pools currently, 6 Servers 31TB Shared, and then 16 servers and 400TB Shared. I honestly don't know if there is an upper or lower limit to the amount of storage supported with XOStor, I'd imagine it would work but someone else would have to confirm.
@davx8342 All servers are Hyperconverged, every server for the entire history of servers.
To ask, how much storage is on your VXRail system today that is shared?
Could this not be better managed using your standard NAS/SAN providers like Synology, 3PAR etc?
I've not used XOStor, but since it's not fully supported on 8.3 yet I don't know that I would consider it feasible until it's fully supported.
Do you have a lot of VMs with more than 2TB of disk attached to each (just curious). I too would love for this to be gone lol.
@nim81 said in Support licensing structure update:
but there's no way I can possibly justify the levels of increase being asked here.
As Olivier has said, your comparing paying for XOA with no support, to XOA and XCP-ng supported in a package deal. I don't know that the Vates team has specifically cancelled the XOA only package, but that is a bit germane to the conversation.
Just use XO from Source, or one of the scripts and move on with your day. If your business grows you can always sign up for support again.
@nim81 said in Support licensing structure update:
to my mind I don't think I've ever even put a single support ticket in
Then you're a perfect candidate for the source edition, no?
@kagbasi-ngc said in How Best to Achieve Higher Transfer Speeds for Backup Jobs:
@lawrencesystems Yes sir I agree, as that is my experience with XOCE. But with XOA (Airgapped), in my PoC Lab, I've received my first upgrade and it was a completely new appliance. So I'm now figuring out how to handle that. I did reach out to Vates support about this and got a response that they are looking into perhaps doing the XO updates kinda like how they handle it now for XCP-ng (i.e., allow us to download the entire repo offline and then do the upgrade that way).
I'm sure you've dealt with many customers who are in my kind of environment, where security/compliance requirements are strict.
Wouldn't you export the configuration from your existing XOA and import it into the new one before it's finalized and "onsite"? That would get you a full working config, from which you may only have to adjust the cpu/ram.
@nim81 said in Price Increases:
I'm out, I'm afraid. With the new pricing structure we're looking at a 550% price increase over last year. I understand that everything's going up in price but there is no possible way I can justify that level.
Just use XO from Source, or https://github.com/Jarli01/xenorchestra_installer or ronivoy's script.
Obviously you're not able to afford the product and support, yet you feel as if you should be given the product for free. Which in that case, build it yourself or use a community provided solution to getting the solution for free.
@ItsAlwaysDNS said in Migrated Linux machine won't start:
I can try to give that a go. Is there any particular reason as to why we think this will work? I'm totally fine with the thought of "its worth a try". I'm just curious if there is some known compatibility issue that is leading you to suggest trying this as a solution.
Normally these older systems were required to use the ESXI drivers, these drivers are also normally very out of date and cause issues.
Most of the time, when these issues occur, it's because of incompatible drivers. Cloning the VM and removing the drivers from the clone and then trying to migrate the VM is the safest way to confirm the issue is with the drivers without impacting your production system.
@ItsAlwaysDNS said in Migrated Linux machine won't start:
When the VM is running on the Vmware host, it reports the tools are running. Looks like its running CentOS 6 (32bit).
CentOS 6 is very out of date, but I can relate to keeping something around longer than it really should be.
Can you make a copy of the VM on your ESXi host, remove the guest tools from the VM and try to migrate the VM without the guest tools?
@KPS this would be for the session, the question I have is what issues are you experiencing?