alexskysilk's latest activity

  • A
    alexskysilk replied to the thread Virtual IP.
    VRRP is a router protocol. If you run your routers on your cluster already, you already have a single IP that you can use for reverse proxy. the rest of the software doesnt serve any actual purpose.
  • A
    Understand that H264/265 codecs are NOT FREE PRODUCTS, and they require a license. see https://accessadvance.com/ for more information.
  • A
    alexskysilk reacted to louie1961's post in the thread PVE edge use case with Like Like.
    If you really want to remove all of the virtualization services and software, why not just use Debian with the Proxmox kernel? Seems safer and less "kludgy" to me. Does it make sense? No, for a number of reasons. First, why start with Proxmox...
  • A
    alexskysilk replied to the thread PVE edge use case.
    You can. its not ideal but it would work. THIS.
  • A
    While I can agree with your assessment for FC, what brings you to the conclusion that the "industry" moved away from iscsi? in favor of what? dont confuse the limitations of PVE with limitations of iscsi as a storage transport- which...
  • A
    alexskysilk replied to the thread Virtual IP.
    OK, so you have a router controlling NAT between your outside and inside traffic, right? start by looking at that documentation for a reverse proxy feature (might be called virtual server or similar) since, by definition, you can only reach your...
  • A
    alexskysilk replied to the thread Virtual IP.
    Context matters. What are you trying to keep alive?
  • A
    alexskysilk replied to the thread Virtual IP.
    Since in a pve environment any node can serve as api head, the simplest approach is to use a reverse proxy, typically run on your router but you can use a vm for this too. ngnix or haproxy work fine for this, you can use any of the million...
  • A
    There is no rational reason to run a cluster with different version nodes. There is RARELY a reason to run a cluster without being fully updated- and even then, fully updated with an older kernel pinned.
  • A
    alexskysilk replied to the thread Proxmox ZFS Migration.
    this is fairly straightforward. step 1: ensure autoexpand is enabled: zpool set autoexpand=on rpool step 2: use the instructions here to replace the first disk: https://pve.proxmox.com/wiki/ZFS_on_Linux#_zfs_administration step 3: either wait...
  • A
    Yes. Stop doing that. Neither the storage nor your hypervisor are designed for use with constantly changing disk presentation, so there is no tooling for it. If you REALLY want to do this you'll need to develop your own tooling.
  • A
    Ah understood. So as @bbgeek17 mentioned this functionality is not present in PVE (at least not yet.) HOWEVER since PVE sits atop of debian its possible to home cook solutions for this using the API; there are a number of projects and discussions...
  • A
    WD_480 is of type lvm. as mentioned above, qcow is only an option for fileshare types. see https://pve.proxmox.com/wiki/Storage for more information.
  • A
    I see this constantly. "speed" is NOT the only metric by which a storage solution is measured. In truth, you RARELY use whatever "speed" a subsystem is capable of, but you depend on features regularly. If you can get by without integrated...
  • A
    Why in god's name are you allowing multipathd trap your SATA DISKS? dont do that. there's literally zero benefit and added failure domain.
  • A
    the "format" your vm's will be written as is a consequence of the store type. Post the content of /etc/pve/storage.cfg to get specific feedback.
  • A
    You have two options. option 1: https://wiki.debian.org/NetworkConfiguration option 2: reinstall and this time DONT do whatever you did before that lead to your network configuration.
  • A
    I have no idea what I'm looking at- and even with that I can search for eno3 or 7df06 and get no hits.
  • A
    unless your interfaces changed names, they would be brought up during boot. check your interface names and look through your dmesg/journal to see whats going on.
  • A
    Thats not particularly actionable ;) smarctl --test=long /dev/sdc