@jessepeterson I did, using the disk mounting method, but the solution didn't really spark joy in me. For the last 18 months I've been on LXD and now Incus, which I found easier to use different distros on.

@olivierlambert said in How Citrix dropped the ball on Xen ... according to Citrix:

We are always transparent regarding Vates, but we can't do the same for a company which isn't ours

Yet. This whole Cloud.com experiment could go belly up.

@stormi said in How Citrix dropped the ball on Xen ... according to Citrix:

Regarding Xen, yes, their committment to the upstream Xen project has reduced in the past years but 1. it still significant (Today, they still have employees whose work is mainly upstream work in the Xen Project), 2. this is not what the article is about, at all.

I guess you've seen the cloud.com launch for the newly merged entity? I have referred to it elsewhere as "tying several bricks together to make a raft," and usually takeovers by PE firms do not go well in general. At work we have over a thousand Citrix ADCs so we're following this closely; meanwhile we are also dealing with the remains of McAfee (now Skyhigh) where the changes have been extremely negative; and before that the clamour of activist investors at Juniper wanting more money in their pockets basically killed that once-great company, and we have had to change the vendor for our entire global network (994 sites) in just two years.

So I would say - hope for the best, but plan for the worst.

The contents itself is interesting, but many people will just see the title.

Alas, welcome to 2022 where everything relies on eye-catching headlines to provoke controversy, and no one looks at issues in depth any more or from more than one side.

Yes, I am officially old and cranky now.

@stormi said in How Citrix dropped the ball on Xen ... according to Citrix:

It's already the case, isn't it? (I mean: on the get some love too part :))

Well, I can't speak on their behalf, but I hope so, certainly.

@MichaelCropper I think that (to be fair to Citrix, or Cloud as they seem to be called now) they do acknowledge that not engaging better with the "enthusiast" community did hurt them. I first met Sheng Liang when he was CTO there before he went off to found Rancher and now Acorn Labs; he was so developer focused and you see that in everything he did afterwards. Perhaps that was why he left Citrix, thinking about it?

I agree for the most part with what you say about homelab enthusiasts, with the caveat that if you go on r/homelab you'll find people running a rack full of servers for their Plex environment and suchlike silliness. But yeah, most of us are doing this for work reasons and to learn new things so I hope we continue to be indulged a bit by the xcp-ng team - even though we're not their main focus.

I do worry though that it seems like Xen needs a forklift upgrade in a number of areas - kernel, Linux distribution, the storage and networking subsystems, for starters - and that's a tough ask for a relatively small project that also needs to make money along the way. In that context the "professional homelabber" community helps less because typically we ask for more features and provide testing, rather than actually writing large pieces of code.

@daninmanchester Thanks so much - this is the exact same problem I had, which was further complicated by running XO in Docker running on the OMV host exporting the NFS shares.

So basically you just built a small XO VM instead of running it in Docker? I had originally been thinking of making a small VM to run XO in a container there - just because Docker containers are super easy to keep updated and I could run some other orchestration-y stuff there too, like Rancher - but if you're saying that's a non-starter I'll just bite the bullet and build a tiny VM dedicated to XO and be very grateful to you for having saved me a lot of frustration.

@ravenet Thanks very much for this and apologies for not replying sooner, I was on holiday with a blissful two weeks of no Internet.

I'll give this a go - so basically boot the iso in a VM with an Ignition file as you describe on a second iso attached to the VM?

Is it possible that a template file could be built which would perform this function for SUSE Linux variants? Otherwise I am not sure how to trigger the building of new VMs as loads scale, eg for when hopefully xcp-ng is supported as a provider for Rancher.

I will gently tease @olivierlambert by noting that the article says Citrix underestimated the importance of homelab users - as The Register paraphrases :

"However, this hit one particular sub-community of free users that one engineer Headland interviewed called the "weird systems users": hobbyists who offer virtualization to non-profit and charity users, using old, out-of-maintenance hardware that had been inherited or passed on to them. Enthusiast users, with no funds to buy licenses, but who had been among the most important finders and fixers of bugs. Unable to use the free version any more, they were forced to move to other products … or create them."

I know and accept that the priority must always be production-style hardware and the objective with xcp-ng will never be Proxmox-esque coverage of nearly all x86 hardware that runs Debian. But I do hope the homelabbers like @Andrew and @abufrejoval get some love too for helping xcp-ng keep up with emerging hardware (like the latest NUCs and similar Project TinyMiniMicro systems), and I for one am immensely grateful for that work - and by extension of course Vates for being willing and flexible to allow it to be added to xcp-ng. The product is all the richer for that.

@olivierlambert I don't have the technical know-how to understand at what point the Ignite file needs to be lit, or injected, or whatever term we want to use here I'm afraid. I do know how the dark side (qemu) wants it done though if that's a help?

--qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=/path/to/config.ign"

I'd not come across Ignite files before so this has been an interesting read. In order to make things "simple," however, it seems they must first be made much more complicated, because although the Ignite file is in JSON you're expected to write it in YAML and then run it through Butane (themed naming, deep sigh) :

https://docs.fedoraproject.org/en-US/fedora-coreos/producing-ign/

Or something like :

podman run -i --rm quay.io/coreos/fcct:release --pretty --strict < config.fcc > config.ign

In the medium term is there a way to use a Template file to feed in the .ign file? I see there is a Packer add-in for XCP that has been linked to before, but the kind xcp-ng forum member who advertised their example files to get people started has since closed their Github site.

Ignite seems to be the direction of travel for SUSE anyway, and there are relatively few immutable container-oriented OSes so hence me looking at MicroOS for Docker containers anyway. (Talos looks good for k8s.)

Hello fellow xcp-ng'ers,

Is it possible to specify the requisite Ignition file to set up and configure a SUSE MicroOS VM in Xen Orchestra?

I understand it's a lot of work to move from cloud-init to Ignition, so I'm not expecting that (however dreadful cloud-init is). I was just wondering if there was an easy workaround for now because there doesn't seem to be any other way to launch and configure MicroOS apart from using Ignition.

@olivierlambert Alright, but this is not immediately apparent to the befuddled newbie and it's not really necessary to make the distinction from a UX perspective. Just because it's that way under the hood doesn't mean it needs to be expressed that way to the user who is not as embedded in the history of the product.

I'm also not sure what to do with this information. The XO install is in a container running on the NFS host, so perhaps that causes it some distress?

I'm wondering if I have the same issue. I'm trying to add a backup remote connected via NFS to an OpenMediaVault server (ie Debian-based) with XO Source. I can add an ISO store from the OMV server via NFS "hard" no issues, but the (configured exactly the same) backup NFS mount fails with the same error message as @Kajetan321 gets. I'm using NFS 3, should I specify that somehow?

Or should I be less lazy and set up NFS4?

Either way it's very weird to have the same NFS server setup work in one instance (as an ISO store) and fail in another (as a backup remote). Also, is there a reason these have to be specified in different ways in different places, why isn't "Backup" just a form of storage like "ISO" and set up through the same method?

Sorry to be a little cranky but I've found this process quite unintuitive and I'm a little worried I can't back anything up easily in the meantime, particularly as the XO backup functionality looks great (once it works).