Beiträge von bensisko

  • New openmediavault-kvm plugin

    Oh you can absolutely ignore the device id way of plugging in. I rather posted this with the thought of someone searching for a more sophisticated way of doing it. I'd be different if libvirt supported attaching devices in accordance with specific bus/port addresses, but they don't. A patch was posted their way around 2017 and they ignored it

  • New openmediavault-kvm plugin

    Zitat von ryecoaaron

    It needs the vendor and product IDs to be listed.

    Just to note, this is naive, as there are 2 ways of attaching usb via libvirt - product/vendor id and device id. I'm using the second one for special reasons (I wanted for a device to be hot-added only on a specific USB port in the system - very much an edge case, done with udev rules, so no need to worry about it)

  • New openmediavault-kvm plugin

    Zitat von ryecoaaron

    This seems like a rare situation to me (doesn't exist in the VMware world)

    This is because there are no services running on esxi, but this assumption is not true for omv. My usecase for example? Running kubernetes workers, with storage being shared out of OMV itself, either via nfs or iscsi. So not exactly that rare

    Also I'd say that it's macvtap that's confusing and not bridge. With bridge it's easy - you create a virtual network switch inside of your system, with infinite ports, and one of those ports is connected to your interface (or more if you so desire), acting like a trunk port. Super easy. Macvtap on the other hand doesn't behave like this, instead leeching off of the upstream interface. I understand that people that "just want my VM to have internet" prefer macvtap, but to go around to the vmware argument - VMware desktop/fusion works exactly like this, creating a bridge on the host OS, it's just that with linux you need to create that bridge by yourself beforehand, which tbh is about 4 clicks in OMV

    That said, about the new version:
    - The ZFS stuff is now working perfectly, thanks for that!
    - Much better UI design overall
    - While the bridge option is there, it is not functional, doesn't see my br0 device, even though br0 is very much there
    - USB is looking great, but seems confused when trying to remove a device - for the one VM that has a device connected, it's showing the root port instead of the actual device(?). It doesn't really match the actual state of the machine. Also a nitpick - the UI shows all usb devices, regardless if they're already connected to a VM or not, so it is possible to try to connect one USB device to two VMs at the same time, which will fail. Not sure if it's fesible to fix that, as it would require to read the state of all VMs, but I'm just pointing this out

  • New openmediavault-kvm plugin

    Also what's disappointing is that libvirt zfs drivers cannot use datasets as a root for a pool, it needs to be directly at the root. It will allow you to create one like that, but won't see any images under it. Seems it's a limitation of the libvirt driver, and not your plugin.

    ryecoaaron I took it for a spin. The one issue I have is that those fields are not required, and what's more they seem to need to be unique to each pool. I can put in garbage and it works, but every driver needs a different set of these it seems?

  • New openmediavault-kvm plugin

    ryecoaaron Haven't tested it out just yet, but there's one more change I'd like to request. For x86 - can we make q35 the default machine type, and ehci, or better yet, qemu-xhci the default usb controller? As it stands now, i440fx is the default machine type, and piix3-uhci the usb controller. The first one is usefull for people who want to dabble in pci-passthrough (a niche, i know), and the other one will prohibit usb2/3 passthrough from working. Both changes have no downsides as far as I know

  • New openmediavault-kvm plugin

    Zitat von ryecoaaron

    Not sure I know what you are referring to in order to add something

    So when attaching VMs to a macvtap, communication guest<->host is impossible. But you can get around that by just attaching your VM to a linux bridge directly, like so:


    <interface type='bridge'>

    <mac address='52:54:00:c8:11:0f'/>

    <source bridge='br0'/>

    <target dev='vnet0'/>

    <model type='virtio'/>

    <alias name='net0'/>

    <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>

    </interface>


    Of course one needs to create the bridge in the first place, but that's easily done through omv itself. Unfortunately it won't work for bare interfaces

  • New openmediavault-kvm plugin

    Thanks! That did it! And the optical drive error is gone! Now all I need it my zfs additions and the ability to attach a bridge interface (not macvtap, I need my VMs to be able to communicate with the host machine) and it'll be golden :D

  • New openmediavault-kvm plugin

    Zitat von ryecoaaron

    Interesting. I was actually going to look at pinning libvirt from backports since qemu* already is.

    Unfortunately there's no libvirt* in buster-backports :(

    Zitat von ryecoaaron

    I don't use zfs

    I could swear you're the author of the zfs plugin :

    Zitat von ryecoaaron

    I just dread zfs and the whole startup order problem

    Huh? What startup problem?

    Zitat von ryecoaaron

    I can add features to the pool creation process

    Ok, so obviously I can't create a ZFS backed pool right now. But then when initially tested it, it would get very confused about trying to mount a qcow2 file. Since then you've added in raw disk support, and this works with the little nitpick that zvols get created with a .raw name ;) I think it'd be best if you could check what type the given pool is and if it's a zfs pool allow only raw, and allow a zfs type pool. That would make me happy. Being able to convert from qcow2 to a zfs-backed volume would be a pretty cherry on top

    Zitat von ryecoaaron

    What I don't want to do is automatically install the zfs driver

    Absolutely fine by me

  • New openmediavault-kvm plugin

    For those of you who updated systemd from backports, you'll need to add

    systemd.unified_cgroup_hierarchy=false to your kernel command line, as the buster libvirt doesn't play nice with cgroups v2

    ryecoaaron and chance for that zfs backend support? libvirt-daemon-driver-storage-zfs is present in buster

  • ZFS or BTRFS

    You don't need the proxmox kernel, in fact the module provided from debian-backports is newer and has more features - OpenZFS 2.0. There's also a ZFS plugin for omv

  • New openmediavault-kvm plugin

    This is absolutely great! Much better than cockpit (which i promptly got rid of). The only thing I'm having problems is interfacing with a ZFS based storage pool. Any possibility for support here?

    Edit: Also being able to use <interface type="bridge"> instead of network would be great (for those of us who already run a bridge). This can already be done through editing xml which is a great feature!

  • Stable device names

    The WWID is an ID of a particular drive, not it's port. Even the description mentions - "independent of the path that is used". I am not quite sure how host controller order is established, but it seems that for my case they seem to be stable


    And yeah, I intend to write this myself. I'll ask for inclusion into omv-extras if I deem it worth it to anyone else, and you'll be free to reject it if it'll be too much of a burden :)

  • Stable device names

    Zitat von ryecoaaron

    Your rules assume the scsi id will always be the same. My QNAP is using different IDs and if you change a drive, they will change.

    From what I see those actually stay the same, I tried to trip it up. I'd love to know the mechanism of HOW they get those IDs. And yeah, I know there doesn't seem to be a way to automagically know which bay is which scsi id. But I don't think I'd be too much of a pain to ask the user that.


    As for the LEDs, I actually found a guy who wrote a small driver for his 451. We're already talking about how to extend it :) You can take a peek here https://github.com/vpelletier/debian-qnap-tsx51


    The biggest problem is that QNAP decided NOT to fill out the DMI properly, so the driver has no way of identifying what it's running on..
    But as of now I think it's realistic to have the following functionality
    #1 Map a drive to a bay (by way of the user pointing of the relation between drive and bay)
    #2 Map an LED to a bay (by way of user pointing an LED to a bay)
    #3 Mark the LED red if a drive fails (if #2 is configured)


    This is somewhat how openwrt does it as well


    Edit: I am only taking scsi drives into account here. I don't care about nvme and/or USB

  • Stable device names

    Well, I kinda figured it out. Unfortunately udev is unable to rename devices in the /dev folder (with the exception of interface names), it can only do symlinks. However, it can do symlinks. And that's kinda enough.


    /etc/udev/rules.d/65-bays.rules:


    Code
    KERNEL=="sd*", SUBSYSTEM=="block", SUBSYSTEMS=="scsi", KERNELS=="3:0:0:0", SYMLINK+="bay0"
KERNEL=="sd*", SUBSYSTEM=="block", SUBSYSTEMS=="scsi", KERNELS=="2:0:0:0", SYMLINK+="bay1"
KERNEL=="sd*", SUBSYSTEM=="block", SUBSYSTEMS=="scsi", KERNELS=="7:0:0:0", SYMLINK+="bay2"
KERNEL=="sd*", SUBSYSTEM=="block", SUBSYSTEMS=="scsi", KERNELS=="6:0:0:0", SYMLINK+="bay3"

    Now with that, one could create some kind of panel in OMV. Maybe I'll actually write one as a plugin. I'd be cool to integrate LEDs into this as well, but the standard debian kernel doesn't provide the gpio driver for my controller (even though it is present in the linux kernel. Debian just doesn't ship it for some reason)