unreid is installed on the laptop. No need for UPS. But there is no battery charge level for a correct shutdown.

I think that given that Unraid is intended for servers, it's highly unlikely that a computer would normally have a battery installed.

This sounds more like a case for a custom plugin, then something you'd include in the base unraid distribution.

+1 for the feature request.

 

I use Unraid on a laptop as well.

 

Many people say Unraid is meant for stationary/traditional servers or desktop PC's, which surely is the common scenario for most users. But I find it very convenient to have virtualization with a nice and clean hypervisor (=Unraid) on my laptop that isn't running in it's own OS like Windows or full blown Linux which will need their own maintenance and updates. I can start Windows with office applications with GPU passthrough, and start Ubuntu and Fedora side by side in VNC full screen on my 3 monitor setup at work. After my office hours, I start Windows with gaming software installed, simply because my laptop contains a RTX3050ti. Separating these use cases in VM's makes sure that these OSes stay clean and dedicated for it's use. Also I can backup them easily. 

 

I've seen more forum topics about laptop users requesting a feature or change (most of them requesting Wifi drivers), to make their use of Unraid more useful and I find it regrettable that the largest group of users constantly react with: "that's not the type of device on how you should use Unraid". It simply doesn't help this group of users which is growing over time. 

 

 

I am surprised you do not simply run Windows natively as it has a built-in hypervisor (Hyper-V) as that by-passes the issue of requiring drivers that most users do not need.  You can then even run Unraid in a VM if you want it for its NAS capabilities or run docker containers under Docker Desktop.   

On 11/11/2023 at 1:55 PM, Cheater said:

+1 for the feature request.

 

I use Unraid on a laptop as well.

 

Many people say Unraid is meant for stationary/traditional servers or desktop PC's, which surely is the common scenario for most users. But I find it very convenient to have virtualization with a nice and clean hypervisor (=Unraid) on my laptop that isn't running in it's own OS like Windows or full blown Linux which will need their own maintenance and updates. I can start Windows with office applications with GPU passthrough, and start Ubuntu and Fedora side by side in VNC full screen on my 3 monitor setup at work. After my office hours, I start Windows with gaming software installed, simply because my laptop contains a RTX3050ti. Separating these use cases in VM's makes sure that these OSes stay clean and dedicated for it's use. Also I can backup them easily. 

 

I've seen more forum topics about laptop users requesting a feature or change (most of them requesting Wifi drivers), to make their use of Unraid more useful and I find it regrettable that the largest group of users constantly react with: "that's not the type of device on how you should use Unraid". It simply doesn't help this group of users which is growing over time. 

 

 

What are the results of?

 

ls -l /sys/class/power_supply/BAT0

On 11/11/2023 at 4:31 PM, itimpi said:

I am surprised you do not simply run Windows natively as it has a built-in hypervisor (Hyper-V) as that by-passes the issue of requiring drivers that most users do not need.  You can then even run Unraid in a VM if you want it for its NAS capabilities or run docker containers under Docker Desktop.   

 

I'm surprised that I didn't made some points clear

- I do not want a full blown OS (Windows), that eats up already a part of the system resources + needs to be maintained (updates+virusscanner+firewall) - just to run it as a bare hypervisor with a WIFI driver in it

- I want to backup each and every OS easily. Running a Windows natively, also needs to be backed up, but it doesn't backup so nicely (you need software for it) and if it breaks down (due to some crazy Windows update f*ck-ups) it's a pain to get back up

 

Also:

- I do not run NAS-like solution in Unraid, because I have a hardware NAS (Synology) for that.

- Running a hypervisor (Unraid) in a hypervisor (Windows with Hyper-V) .... can't take this serious, sorry  🤣

- Running Unraid in Windows, and running VM's in Unraid, still has no battery indicator in the VM's in Unraid

Edited December 1, 20232 yr by Cheater

On 11/12/2023 at 10:06 PM, SimonF said:

What are the results of?

 

ls -l /sys/class/power_supply/BAT0

 

Tnx for this.  I checked some of the properties that are available in BAT0 and this seems already half of the story to get to Battery-status in the VM's.

 

 

So the remaining part, would be the question: how to get this "device" (not sure if you can call it that way) in a VM. I currently pass my keyboard and mousepad already to the VM with this:

  <qemu:commandline>
    <qemu:arg value='-object'/>
    <qemu:arg value='input-linux,id=kbd,evdev=/dev/input/by-path/platform-i8042-serio-0-event-kbd,grab_all=on,repeat=on'/>
    <qemu:arg value='-object'/>
    <qemu:arg value='input-linux,id=mouse,evdev=/dev/input/by-path/platform-i8042-serio-1-event-mouse'/>
  </qemu:commandline>

 

Would passing the BAT0 entity be possible in a same manner?

 

Are you able to assist to get the BAT0 into the VM with QEMU directives?

 

Edited December 1, 20232 yr by Cheater

22 hours ago, Cheater said:

 

Tnx for this.  I checked some of the properties that are available in BAT0 and this seems already half of the story to get to Battery-status in the VM's.

 

 

So the remaining part, would be the question: how to get this "device" (not sure if you can call it that way) in a VM. I currently pass my keyboard and mousepad to the VM with this:

  <qemu:commandline>
    <qemu:arg value='-object'/>
    <qemu:arg value='input-linux,id=kbd,evdev=/dev/input/by-path/platform-i8042-serio-0-event-kbd,grab_all=on,repeat=on'/>
    <qemu:arg value='-object'/>
    <qemu:arg value='input-linux,id=mouse,evdev=/dev/input/by-path/platform-i8042-serio-1-event-mouse'/>
  </qemu:commandline>

 

Are you able to assist to get the BAT0 into the VM with QEMU directives?

 

why are you using QEMU options to passthru KeyB and mouse?

 

Will look to see if there is a way to passthru.

On 12/1/2023 at 9:41 AM, Cheater said:

 

Tnx for this.  I checked some of the properties that are available in BAT0 and this seems already half of the story to get to Battery-status in the VM's.

 

 

So the remaining part, would be the question: how to get this "device" (not sure if you can call it that way) in a VM. I currently pass my keyboard and mousepad to the VM with this:

  <qemu:commandline>
    <qemu:arg value='-object'/>
    <qemu:arg value='input-linux,id=kbd,evdev=/dev/input/by-path/platform-i8042-serio-0-event-kbd,grab_all=on,repeat=on'/>
    <qemu:arg value='-object'/>
    <qemu:arg value='input-linux,id=mouse,evdev=/dev/input/by-path/platform-i8042-serio-1-event-mouse'/>
  </qemu:commandline>

 

Are you able to assist to get the BAT0 into the VM with QEMU directives?

 

From what I have found so far I dont think it is currently possible to pass battery info. https://gitlab.com/qemu-project/qemu/-/issues/242

On 12/2/2023 at 8:50 AM, SimonF said:

why are you using QEMU options to passthru KeyB and mouse?

 

The built-in keyboard and mouse from the laptop is not a USB device which I can pass via the Unraid form-based interface. So I have to pass it as an evdev device in the XML view, which I learned from the SpaceInvader video's.

Edited December 4, 20232 yr by Cheater

8 hours ago, Cheater said:

 

The built-in keyboard and mouse from the laptop is not a USB device which I can pass via the Unraid form-based interface. So I have to pass it as an evdev device in the XML view, which I learned from the SpaceInvader video's.

Ah ok understood.

On 12/2/2023 at 2:01 PM, SimonF said:

From what I have found so far I dont think it is currently possible to pass battery info. https://gitlab.com/qemu-project/qemu/-/issues/242

 

Tnx for bringing up this gitlab issue from Qemu as this is exactly what we (forum topic starter and I) need.

I'll monitor that issue for any updates.

On 12/4/2023 at 10:58 PM, Cheater said:

 

Tnx for bringing up this gitlab issue from Qemu as this is exactly what we (forum topic starter and I) need.

I'll monitor that issue for any updates.

Looks like there is no plans to continue based on his response on gitlab. 

 

Not sure if NUT may be an option. Server on the host and NUT client in the guest?