@stormi said in XCP-ng 8.2.0 RC now available!:

yum update uefistored

I could only get it (uefistored-0.2.6-1.xcpng8.2.x86_64) to update by yum update uefistored --enablerepo=xcp-ng-testing

But it has done the trick. No toolstak restart or reboot needed either.

@stormi Nice to do something useful and give a little back, other than buying a XCP-ng cushion for my office!

@r1 Is this still in development; would like to get it working with 8.1?

Manually mounting the CephFS works, but the patch fails, probably not surprisingly; or is a GlusterFS approach a better option?

With Ceph Octopus and the cephadm approach setting Ceph up is really easy, so maybe this will become a more popular feature....?

Windows Home is 1 socket, Pro is 2 and Workstation / Enterprise is 4 apparently......

Windows Server is many more 64 apparently, currently I have 12 dual core sockets on my VM.

@wsciaroni just double checked, I see that too very early on and not for long, but then it boots.

Just downloaded this iso - http://releases.ubuntu.com/18.04.4/ubuntu-18.04.4-live-server-amd64.iso

Works on my E5-2697v3 and E5-2620 v4 both on a Supermicro X10DRi-T, (only one CPU in exch).

So after parking CoreOS for nearly a year, and after noticing some edits and commits had been made I decided to give it another go; this time with success…. Yipppeee

• XCP-ng 8.0.0 with latest patches
• CoreOS version is Container Linux 2303.3.0
• XO from sources - xo-server 5.54.0

There are a few buts and pointers though!!

Deploying the VM did not work from XO (from sources, just a homelabber here); the config disc was not created.

So reverting to XCP-ng Centre…….

Following https://github.com/xcp-ng/xcp/wiki/Docker-in-XCP-ng for general guidance – BUT I was unable to log in with my SSH key.

This is fixed by enclosing the key in “ “ thus, my cloud-config was

#cloud-config

hostname: %VMNAMETOHOSTNAME%
ssh_authorized_keys:
  - “ssh-rsa AAAAB3NzaC……………………..syQ4cJYnG70BqQJZVqo5fGcIQP9j5UY1 user@host"
  # - ssh-rsa <Your public key>
  # The following entry will automatically be replaced with a public key
  # generated by container management plugin. The key-entry must exist,
  # in order to enable container management for this VM.
  - ssh-rsa %CONTAINERRSAPUB%
coreos:
  units:
    - name: etcd-member.service
      command: start

    # Hypervisor Linux Guest Agent
    - name: xe-linux-distribution.service
      command: start
      content: |
        [Unit]
        Description=Hypervisor Linux Guest Agent
        After=docker.service

        [Service]
        ExecStartPre=/media/configdrive/agent/xe-linux-distribution /var/cache/xe-linux-distribution
        ExecStart=/media/configdrive/agent/xe-daemon
  etcd:
    name: %VMNAMETOHOSTNAME%
    # generate a new token for each unique cluster from https://discovery.etcd.io/new?size=3
    # specify the initial cluster size using ?size=X
    # discovery: "https://discovery.etcd.io/<token>"
write_files:
  # Enable ARP notifications for smooth network recovery after migrations
  - path: /etc/sysctl.d/10-enable-arp-notify.conf
    permissions: 0644
    owner: root
    content: |
      net.ipv4.conf.all.arp_notify = 1


# Template loaded from /usr/lib/python2.7/site-packages/xscontainer/data/cloud-config.template

Following the rest of the guide everything appeared to go well.

Launching a container and then the next issue, it doesnt show in XO or XCP-ng Centre. Following this post https://xcp-ng.org/forum/topic/1679/how-to-fix-coreos-docker-container-tree-view-in-xcp-ng-center/2 and vola, all working.

Now I have a working mater a fast clone avoids any of these issues for additioanl hosts.

Creating a container without –restart always does not allow me to start / restart / stop it from XO, not the end of the world, looks like this has been found https://xcp-ng.org/forum/topic/2148/can-t-start-docker-container-from-xoa

Happy to try and help resolve any of these 'issues', test and provide logs etc. etc.

@johnkrips

Have a read of this thread (found by googling the generic part of your error message).

@johnkrips I would edit the grub file in /boot and remove the line that gets added or you can just run the command that you used to hide it but without the device address. So if you want to hide no devices it will just end in =

@l1c I did passthough my RX580 a while ago (I was trying to virtualise my desktop but had USB issues and parked the idea), either in 8.0 or 8.1 I can't remember and it did work.

Yes I did install the driver, but only the drive (via Device Manager if in Windows), and not to whole AMD control panel. I think the file is around 80MB rather than 300+MB.

@l1c @Johnkrips

Hi, I can pass through a Radeon Pro WX 4100 Graphics in 8.2 to a Windows VM with no issue. It is basically the same as the RX550 just aimed at a different application.

I do not need to hide it. It appears as a GPU available for passthough in the VM's Advanced options in XO. Its also shows up as a GPU available for passthrough in XCP-ng Centre.

If you have hidden it (it shouldn't be necessary for supported GPUs - I did initially and had issues), then try unhiding it and see if you have any better luck!

I'm not so sure if its is the same for 'consumer / gamer' GPUs.

@hoerup Hi, I can't remember too much to be honest.

I created a Debian 10 VM with 20GB disk, set up all the stuff that needed to be common for the Ceph pool pretty much following the Ceph documentation using the cephadm method - so Docker etc. This would be my 'Ceph admin VM'

Once that was all sorted I cloned the VM 3 times, for my actual Ceph pool and changed the hostname and static IP etc. I've got 3 hosts with Supermicro boards that have two SATA controllers on board, so on each one I passed though one of the controllers to the Ceph VM and then just deployed Ceph and followed the documentation. The only issues I ran into and any other tips are in the other post I linked to. Now Ceph is all containerised it all seams a bit too easy! Hope they're not my famous last words!! It does like a lot of RAM, so I've reduced the OSD limits down a bit and its fine for me.

Cheers.

@r1 said in XCP-ng 8.2.0 RC now available!:

@jmccoy555 said in XCP-ng 8.2.0 RC now available!:

CephFS is working nicely, but the update deleted my previous secret in /etc and I had to reinstall the extra packages and recreate the SR and then obviously move the virtual disks back across and refresh

Were you not able to attach the pre-existing SR on CephFS? Accordingly, I'll take a look in the documentation or the driver.

No look. I ended up with a load of orphaned discs with no name or description, just a uuid so it was easier to restore the backups.

I guess this is because the test driver had the CephFS storage as a NFS type, so I have to forget and then re attached as a CephFS type which I guess it didn't like! But its all correct now so I guess this was just a one off moving from the test driver.

Anyway all sorted now and back up and running with no CephFS issues!

@julien-f @olivierlambert thanks for replying.

So proxies are a XOA paid only feature (even without support), and its not possible to manually build, or understand the magic that is going on within the proxy VM ; at least thats something else less to play with and break!

Looks like Plan B then!

@olivierlambert Hi, did this ever get documented? I've got a bit of a Christmas project in the pipeline setting up a XCP-ng host at my parents and would want it to back up the VMs locally, but ideally without running another local XO; so basically the exact problem a proxy would resolve.

I guess registering it, in Redis I presume, would be easy enough, but what about the proxy VM itself?

Thanks.

@harajukakei I dont use it but it does work for me (XO build from Source), although not from my android phone (the hosts don't move across to the Available list), so could it be browser related?

@stormi said in XCP-ng 8.2.0 RC now available!:

yum update uefistored

I could only get it (uefistored-0.2.6-1.xcpng8.2.x86_64) to update by yum update uefistored --enablerepo=xcp-ng-testing

But it has done the trick. No toolstak restart or reboot needed either.