XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. fohdeesha
    3. Best
    Offline
    • Profile
    • Following 0
    • Followers 4
    • Topics 0
    • Posts 102
    • Groups 4

    Posts

    Recent Best Controversial
    • RE: Any updated tutorial on how to create new cloud images?

      @encryptblockr The issue is the cloud-init project is so disorganized and is constantly introducing more and more OS-dependent workarounds, bugs, and oddities that any documentation will become useless in a few months. I maintain our XOA Hub cloud-init builds, and I have to personally rewrite my own documentation every single time we push out a new image because cloud-init has broken something new, changed or removed config options without documenting it, or the underlying OS has changed how it deals with networking files etc and cloud-init has not been updated to deal with that. For example: I don't think the below will work any longer networking wise with netplan based distros, like newer ubuntus.

      For debian/ubuntu, this is my rough process currently, but it's not worth putting in an official blog or document guide because it will be rendered useless and just cause people frustration the next release cloud-init puts out, the next debian or ubuntu version change, etc. You'll note none of this is related to XCP-ng at all (except for xen tools obviously), so the below is documentation cloud-init should really be publishing themselves - I have a feeling they also know it would quickly be rendered useless as well so they don't bother. Anyway:

      #create a new debian or ubuntu VM in XCP-ng with a ~10gb disk. During the install ISO process, you'll have to choose manual partitioning, and either remove the swap partition completely from the partition layout, or move it to the beginning of the disk. If you choose auto partitioning, it will put a swap partition after the data partition, so the data partition won't be able to be expanded on your template. Once it's installed and running, install xcp-ng guest utilities. To get the latest version, use our guest-utilities ISO. Once all that xen-specific stuff is done, you can start the cloud-init setup: Start with installing cloud-init in the first place:

      apt-get install -y cloud-init cloud-utils cloud-initramfs-growroot
      

      Set the root and default user to random passwords, then disable password logins (this is done on our templates so only pubkey based logins are accepted, skip this optionally):

      echo 'root:dfgdfgdfg' | chpasswd
      echo 'ubuntu:dfgdfg' | chpasswd
      passwd -l root
      passwd -l ubuntu
      nano /etc/ssh/sshd_config #set permitrootlogin to "no"
      

      Clean networking stuff that the VM picked up via dhcp from your current network, they will be re-populated with current info whenever the template is deployed:

      nano /etc/resolv.conf #remove all
      nano /etc/hosts # remove everything but localhost
      

      Now the important part, set the main cloud init config. Edit /etc/cloud/cloud.cfg - What exactly you need to edit here is impossible to document, as the default values in this file change across every OS, and are changed across every cloud-init version, with no documentation indicating they have done so. The actual behavior of a given option has also been changed out of nowhere. So I'll try to summarize. You want to remove any datasource_list or datasource blocks, and replace them with these values:

      datasource_list: [ NoCloud, ConfigDrive ]
      datasource:
          ConfigDrive:
              dsmode: local
          NoCloud:
              fs_label: cidata
      

      You'll need to find and change (or add) these vars as well so networking is properly handled:

      manage_resolv_conf: true
      manage_etc_hosts: true
      preserve_hostname: false
      

      Also find the default_user block, and change it to whatever username you set up during the install ISO (the user aside from root). On our templates we name this user after the OS, so the non-root user on the ubuntu template is "ubuntu", so that part of the cloud-init config looks like this:

         default_user:
           name: ubuntu
      

      If your file doesn't have the following somewhere in it, add it (I've had to add it on some builds, on other builds it was magically there already):

      users:
         - default
      disable_root: true
      

      On some older cloud-init versions, I had to manually re-order the module init staging order, because cloud-init could not be bothered to get this right themselves. I think (???) this has been resolved in later builds, but again it changes constantly so there's no way to know. Basically, ensure these three modules are under the first "cloud_init_modules" that run during the init stage, not under the later config or final stage:

       - set_hostname
       - update_hostname
       - update_etc_hosts
      

      Save the config file, and hopefully you're done with that. I can't outline just how unreliable documenting this file is - the defaults, the behavior of certain options, or even the presence of certain options changes entirely across OS's and cloud-init versions, so I can't just keep a "master copy" of the config file and expect it to work. You have to examine the default file you get line by line and work towards the values above until the template works properly. When it stops working properly 3 months later, browse the cloud-init mailing lists and github issues to figure out which option's behavior they changed without any warning, and repeat.

      Now remove all the random config files that cloud-init occasionally decides to install that will override your own config and render it useless. This list of files changes whenever cloud-init builds feel like it, so just look in the parent directory to see what's there on your specific cloud-init version:

      rm -rf /etc/cloud/cloud.cfg.d/99-installer.cfg /etc/cloud/cloud.cfg.d/90_dpkg.cfg /etc/cloud/cloud.cfg.d/subiquity-disable-cloudinit-networking.cfg
      

      Remove any stuff the VM picked up that you don't want in all your templates. This also cleans any cloud-init runs that might have occurred if you rebooted the VM, so the template you end up with will be "fresh". We also remove the command history for the root user and default user

      rm -rf /etc/ssh/ssh_host_*
      cloud-init clean --logs
      su - ubuntu
      cat /dev/null > ~/.bash_history && history -c && exit
      cat /dev/null > ~/.bash_history && history -c && exit
      

      Now you can shut the VM down and convert it into a template. Whenever deploying, it will already have xen guest tools, and a disk that will automatically be expanded to whatever you set the disk size to when deploying

      NOTE: If you plan on using the "network config" cloud-init box during VM creation in XOA, note that whatever you put in that box is ADDED to the VM's default network config. It does not REPLACE it. That means when you follow the directions above, almost all OS's will have a default config of DHCP on eth0 in /etc/network/interfaces - so if you fill out the cloud-init network box during VM creation to set a static IP, the VM will still read the DHCP config, get a DHCP address, then read the cloud-init created network config files under /etc/network/interfaces.d/* and add that static IP as well. If you want to configure VMs with only static IPs you configure during VM deployment with cloud-init for example, you would have to remove the dhcp config stuff out of /etc/network/interfaces on your template VM when creating it

      posted in Xen Orchestra
      fohdeeshaF
      fohdeesha
    • RE: XO debian 10 cloud ready VM template (cloud-init)

      @mietek I can assure you there's no malicious intent to mislead you, why we would do that to our users is beyond me. Olivier is simply one of the most busy people I've worked with, and he still takes the time to come here and answer free users when he can. He might not have the time to scour the internet and github for the relevant patches and news for niche threads like this. We were not made aware of the cloud-init fix until just a few days ago when a patch was submitted. Cloud-init has been notoriously hard to support and document because the upstream project is constantly doing things like this, and as you noticed it can affect how it works on one OS version versus another very differently. If it were up to me we would drop built-in support for it because of this mess (and a lot of large projects have dropped it entirely and moved to Ignition, like CoreOS) but a lot of users still find it very useful so we continue to support it as best we can, baring with the mess going on upstream.

      I'm not sure if you're aware, but Olivier is the founder and CEO of Vates, who is behind both XCP-ng and XOA. I welcome you to go to the ESXI forum and try and get the CEO of VMware to personally answer your questions, as a free user to top it off.

      posted in Xen Orchestra
      fohdeeshaF
      fohdeesha
    • RE: Assign second ipadres to network card

      @rtjdamen Copying my reply to your official support ticket (any reason for duplicating support tickets on the forum as well?):

      given XOA is built on standard debian, you can assign multiple IPs to the same interface quite easily by just duplicating another "iface eth1 inet static" line. Also keep in mind XOA does not add extra interfaces under the main /etc/network/interfaces file, but in files under the /etc/network/interfaces.d/ directory. So in your case given it was eth1 you wanted a second IP on, you can add your required second IP in this file like so:

      [09:43 12] xoa:~$ cat /etc/network/interfaces.d/eth1
      allow-hotplug eth1
      iface eth1 inet static
       address 192.168.1.80
       netmask 255.255.255.0
      
      #second IP
      iface eth1 inet static
       address 172.16.100.5
       netmask 255.255.255.0
      
      posted in Management
      fohdeeshaF
      fohdeesha
    • RE: French government initiative to support

      Why is it these people can never spell?

      posted in News
      fohdeeshaF
      fohdeesha
    • RE: Realtek 8187 (RTL8187) driver

      @jivanpal I think trying to get OpenVswitch (our underlying network layer) managing and using a wifi dongle for core hypervisor networking would be a nightmare, and you'd probably need to install some extra packages to handle the authentication / WPA management etc - then of course there's zero guarantee OVS wouldn't overwrite or revert any of this custom stuff for said interface (OVS was not designed to work with wifi)

      Not to mention you'd have to have a relatively hackable AP, one that will allow the dongle to source a lot of different MAC addresses, which is pretty rare. From OVS's own docu:

      e55b26f6-b82c-4461-a0a3-e725d3dea4f0-image.png

      posted in Development
      fohdeeshaF
      fohdeesha
    • RE: XCP-NG vm's extremly slow

      @Andi79 https://www.youtube.com/watch?v=tDacjrSCeq4

      posted in Compute
      fohdeeshaF
      fohdeesha
    • RE: XCP-NG Slow VM vs Bare Metal

      @zxcp Something is very broken - with customers and most users we typically see around ~90% of bare metal perfs (in things like passmark and real use). This is with modern virtualization using PVHVM - which is what most of the templates should default to if your hardware supports it. What hardware is this exactly? is it running the latest bios/firmware and you've ensured it has VT-D / IOMMU / etc enabled? In simple cases of poor virtualization overhead we may expect to see something like ~30% worse performance compared to bare metal, so maybe an 8 minute ubuntu install instead of 5. Three hours means something is very broken somewhere - could be storage related as well as installs are usually very write heavy. If you attach a dmesg from XCP-ng it should make it clear what your hardware supports virt wise

      posted in Compute
      fohdeeshaF
      fohdeesha
    • RE: Weird issue with PCIe passthrough and XCP-NG/Xenserver

      @alexanderk Heh yes, and a few other Brocade/Quanta/Dell guides

      posted in Compute
      fohdeeshaF
      fohdeesha
    • RE: XO from sources

      +1 for avoiding 3rd party install scripts, the official install doc is like, 10 commands? I think it takes maybe 10 minutes or less the last time I did it on a fresh debian system, and you know it's always the correct instructions (which is NOT the case with 3rd party scripts, as you'll see in this forum when even the slightest architectural change is made to the XO sources). You also get to learn at least a little bit about the architecture of what you're installing and running instead of pressing go on a script you grabbed from some guy's github and hoping the XO web interface appears. I thought the whole point of "homelab" (for which sources are intended and primarily used) was learning and developing skills in the first place?

      No disrespect intended to the people that create and maintain said scripts, it just seems to me like it bypasses the point of sources a little bit 🙂

      posted in Xen Orchestra
      fohdeeshaF
      fohdeesha
    • RE: Still no new templates

      @maxcerny Indeed, the Ubuntu cloud-init template should be up by the end of this week (cloud-init has so many fun bugs to work around for these applications)

      posted in News
      fohdeeshaF
      fohdeesha
    • RE: Windows Server 2022 Essentials

      @olivierlambert never done it myself, but this is indeed exactly what the feature "Copy host BIOS strings to VM" was intended for as @Andrew mentioned. Hopefully the BIOS strings this feature copies are enough for the ROK installer to recognize the "authorized" dell hardware

      posted in Development
      fohdeeshaF
      fohdeesha
    • RE: Great projects have great documentation. Is XCP-ng a great project?

      I can start adding to this this weekend probably - would a "guide to installing pfsense" be useful? I know there's many guides out there already, but more than half of them have useless (or worse than useless) steps telling people to turn off things that don't need to be turned off

      posted in Development
      fohdeeshaF
      fohdeesha
    • RE: When attempting to create a OPNsense VM via XO stack becomes unresponsive.

      @MrXeon So, the actual root issue here I believe, is opnsense installs come with an IP and dhcp server already assigned and enabled on the lan interface (I believe it's 192.168.1.1, but don't quote me). If your existing home network already uses 192.168.1.x/24 and already has a dhcp server, booting an opnsense install with it's virtual lan nic set to your existing home lan, there will be a lot of conflicts. Virtual nic order can be whatever you'd like (you can change and move around assignments in opnsense), but if it's preconfigured lan interface gets set to your preexisting lan network, there will be conflicts 🙂

      posted in Compute
      fohdeeshaF
      fohdeesha
    • RE: Epyc Boost... not boosting?

      @tekwendell xen carefully manages CPU power management to match VM load and vCPU count, I would not manually try to adjust things with xenpm in the meantime as it's likely you'll make things worse (don't try to outsmart xen power management unless you have a VERY specific use case). Xen is designed for paralleled workloads (more than a single VM), so there's many tunables for VMs that are set with this in mind (like CPU affinity). So by default I'm sure the CPU affinity for your single windows VM is still set somewhere in the "middle", so it's not going to be allowed to schedule the full CPU time versus what dom0 is also using.

      I'm not an expert in AMD/Epyc power management, but I believe it's pretty typical that CPU power/clock management boosts based on overall CPU load, and running a benchmark on only a single VM using something like 8 cores on a 64 core processor is not going to demand a lot CPU time, so I'm not surprised to see it's not boosting very far. Spin up 6 more of those VMs and benchmark them all at the same time, I wouldn't be surprised if you see it start boosting higher

      475 cpu-z versus 501 bare metal is very good and indicates pretty clearly there's no issue here, you're getting 94% bare metal performance on windows under a large virtualization stack (historically the OS with the most overhead to virtualize). I would be very happy about this

      If you really want to dig further, ensure your bios power management is set to "OS-controlled", this will hand more control over turbo and c-states to the xen power manager and is what is recommended on AMD processors, and then you can use some commands listed here to check actual turbo status. But again, note that I won't be surprised if you can't get a 64-core processor to enter its highest turbo states when only stressing 1/10th of its cores: https://support.citrix.com/article/CTX200390/power-settings-in-citrix-hypervisor-cstates-turbo-and-cpu-frequency-scaling

      posted in Compute
      fohdeeshaF
      fohdeesha
    • RE: XCP-NG Slow VM vs Bare Metal

      @zxcp PowerEdge 1950 and R900 are far too old for virtualization with xen. This era of Xeons (more than 12 years old) are missing a ton of extensions that help with virtualization, with no IOMMU subsystem to be used by xen etc as you noticed in dmesg (I'm honestly surprised our installer even worked on these). The bare minimum I would consider for virtualization would be 11th gen dell stuff (R610, R710, etc)

      posted in Compute
      fohdeeshaF
      fohdeesha
    • RE: Best CPU performance settings for HP DL325/AMD EPYC servers?

      @s-pam If you don't mind about power usage, high performance (that you've already selected) is the way to go. It will avoid entering C states as often and leave the CPU clocked high among other things so there is no latency for workloads waiting on the CPU existing C states etc.

      Leave x2APIC enabled, it helps to distribute interrupts between multiple cores/CPUs. There's no downside to having it enabled unless the hypervisor doesn't support it (and you would know immediately by having errors).

      Regarding your last setting, also referred to as CCX as NUMA, this changes how the CPU cores are presented to the hypervisor (either as one NUMDA domain, or multiple, one for each set of cores that share cache). From the benchmarks I can find, leaving this on gains maybe 3 to 4 percent improvement https://blogs.vmware.com/performance/2020/05/app-perf-vmware-vsphere-amd-epyc-rome.html

      posted in Compute
      fohdeeshaF
      fohdeesha
    • RE: Second ip for hosts interface

      @SNSNSN Indeed, these would typically at least be isolated via vlans at least (one vlan for iscsi traffic, one for iscsi). There's no point in having them in two different subnets if they're in the same network and vlan, the traffic isn't isolated at all. You might as well have them in the same subnet if you're doing that, in which case you only need 1 IP on the XCP-ng management NIC.

      posted in Xen Orchestra
      fohdeeshaF
      fohdeesha
    • RE: Network pool + Cloud Init

      @brm Hmm, I actually am not sure if we ever added support for this specifically (specifying an IP from IP pools in a cloud-init configuration). I've never seen IP variables used or referenced so I don't think it's currently possible. @olivierlambert who was it on the team that implemented the IP Pools feature?

      posted in Xen Orchestra
      fohdeeshaF
      fohdeesha
    • RE: Netbox Plugin: IP-address created always uses the "largest prefix" in Netbox

      @olivierlambert I vaguely remember @pdonias and I discussing which of these behaviors would be best and we decided on adding it to the smallest matching prefix, I'm not sure why the behavior is the opposite

      posted in Xen Orchestra
      fohdeeshaF
      fohdeesha
    • RE: info Xen Orchestra cli cmd

      @Gheppy I'm not sure if xo-cli supports job interactions, @olivierlambert may have to inquire with the xo-cli dev @julien-f . For your niche use case, you could solve it in the meantime by running your XO instance from your house (or wherever this CR destination and DB test server are). Then, you can set the CR job to replicate to two remotes, your main CR destination, and then your test pool you've been manually copying to. Since these are now both local to XOA, it won't use up extra internet bandwidth, XOA will still only be pulling one stream from the production server out on the internet, then once it's inside your network on XO, it duplicates and writes to both local CR destinations

      posted in Xen Orchestra
      fohdeeshaF
      fohdeesha