Re: [qubes-users] Custom LAN Network with dhcpd
On 3/29/21 10:36 AM, Frédéric Pierret wrote: Hi, Le 3/15/21 à 12:40 PM, 'Nyx' via qubes-users a écrit : Hello, I am trying to implement an internal Qubes LAN with HVMs that receive dhcp from a netvm using dhcpd. A classical network layout sort of speak. Reading Xen Networking makes it look possible but Qubes auto configuring the VM networking is being a bit troublesome for what I am trying to setup. Note that the entire network will be on Qubes only with no internet access. The reason I am trying to set this up is I have some HVMs that are not getting an ip through dhcp and I cannot access them to set ip manually (they are vulnhub vms). I was thinking of just running an hvm with virtualbox but the limits of emulation only wont work. I read that qubes can be recompiled to enable nested virtualization to get that working but if there is a way to create a custom network that would be preferred. Is there a way to allow a set of HVMs to get ip from a netvm running dhcp and communicate like a classic network? -- You might be interested in such thing: https://github.com/fepitre/qubes-mgmt-salt-qubes-server/blob/devel-140320/qubes-server.png I'm currently working on several adjustment recently (not pushed) but for you case, you might want to start by using usual "bridge" for which we have support of this in QubesOS-contrib: dom0 component: https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device vm component: https://github.com/QubesOS-contrib/qubes-core-agent-linux-addon-bridge-device When this installed, in a given AppVM named for example "lan-net", with NetworkManager you can create a bridge interface named for example "br0" that will be made available as bridge device to be attached. Then, in dom0, running "qvm-device bridge" will show you the bridge created in "lan-net". At this point, this is exactly like USB, BLOCK or MIC devices. You can attach an AppVM named for example "personal" to this bridge (meaning it will have an interface that is linked into the bridge): "qvm-device bridge attach personal lan-net:br0". You can do that for multiple VMs, and then, you would have local classical network between several VMs. Even more, you can attach a physical interface into "br0" and link external network with other machines. Notes: - It supports options like: "qvm-device bridge attach personal lan-net:br0 --option=ip=192.168.0.1 --option=netmask=255.255.255.0 --option=gateway=192.168.0.254" - Be careful that using standard bridge network model is NOT the Qubes model using NAT and based on isolation of each component. - You would need to probably adjust iptables if your "lan-net" has a NetVM. I plan to make proper README and documentation describing this and also related Qubes-server formula soon. In the mean time I can help here or on discourse. This also looks interesting. An alternative that I learned about recently: https://github.com/Rudd-O/qubes-arbitrary-network-topology -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f52b46c4-89af-8bf5-fb32-6bf27e0491ef%40hackingthe.net. smime.p7s Description: S/MIME Cryptographic Signature
[qubes-users] Poor battery life running Qubes
Hi there I've been using Qubes for about 18 months now, and it's great. My only complaint is the poor battery life I get. I've followed various recommendations within qubes-users about using powertop and tlp, but nothing seems to address the rapid decline in power I experience when running on battery. Some system information: Kernel Version Linux version 5.4.88-1.qubes.x86_64 System Name PurismLibrem 15 v44.0 (Pureboot) CPU Information 2 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz OS Information Qubes release 4.0 (R4.0) Probably the biggest clue I have received was from running tlp stat, which suggests: "Reconfigure your Linux kernel with PM_RUNTIME=y to reduce your laptop's power consumption." This seems to be reinforced by the following output from powertop: Untunable Software Issues Description I2C Adapter i2c-3 has no runtime power management I2C Adapter i2c-4 has no runtime power management Optimal Tuned Software Settings Description NMI watchdog should be turned off Enable SATA link power management for host0 Enable SATA link power management for host1 Enable Audio codec power management Runtime PM for I2C Adapter i2c-1 (i915 gmbus dpb) Runtime PM for I2C Adapter i2c-2 (i915 gmbus dpd) Runtime PM for I2C Adapter i2c-0 (i915 gmbus dpc) Runtime PM for I2C Adapter i2c-5 (SMBus I801 adapter at efa0) Runtime PM for PCI Device Samsung Electronics Co Ltd Device a808 Runtime PM for PCI Device Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem Runtime PM for PCI Device Qualcomm Atheros AR9462 Wireless Network Adapter Runtime PM for PCI Device Intel Corporation Device 9d24 Runtime PM for PCI Device Intel Corporation Device 9d30 Runtime PM for PCI Device Intel Corporation Sunrise Point-LP HD Audio Runtime PM for PCI Device Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers Runtime PM for PCI Device Intel Corporation Device 9d4e Runtime PM for PCI Device Intel Corporation Sunrise Point-LP Thermal subsystem Runtime PM for PCI Device Intel Corporation HD Graphics 620 Runtime PM for PCI Device Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller Runtime PM for PCI Device Intel Corporation Sunrise Point-LP SMBus Runtime PM for PCI Device Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model Runtime PM for PCI Device Intel Corporation Sunrise Point-LP PCI Express Root Port #5 Runtime PM for PCI Device Intel Corporation Sunrise Point-LP PMC Runtime PM for PCI Device Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] Runtime PM for PCI Device Intel Corporation Sunrise Point-LP PCI Express Root Port #9 Looking at https://github.com/QubesOS/qubes-linux-kernel/blob/master/config-base, I can see CONFIG_PM_RUNTIME is absent from the config. I'm willing to try recompiling the Linux kernel for Qubes with PM_RUNTIME=y, but my understanding is that I would need to set up a VM running Fedora 25. Before I head down that rabbit hole, I wanted to ask if anyone had experienced similar problems and tried this solution. Further, is there a reason that flag is not currently included in the base config? Thanks in advance, Jonathan -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c9f32b26-92c2-43e9-8063-551b348ecbb5n%40googlegroups.com.
Re: [qubes-users] Custom LAN Network with dhcpd
Hi, Le 3/15/21 à 12:40 PM, 'Nyx' via qubes-users a écrit : Hello, I am trying to implement an internal Qubes LAN with HVMs that receive dhcp from a netvm using dhcpd. A classical network layout sort of speak. Reading Xen Networking makes it look possible but Qubes auto configuring the VM networking is being a bit troublesome for what I am trying to setup. Note that the entire network will be on Qubes only with no internet access. The reason I am trying to set this up is I have some HVMs that are not getting an ip through dhcp and I cannot access them to set ip manually (they are vulnhub vms). I was thinking of just running an hvm with virtualbox but the limits of emulation only wont work. I read that qubes can be recompiled to enable nested virtualization to get that working but if there is a way to create a custom network that would be preferred. Is there a way to allow a set of HVMs to get ip from a netvm running dhcp and communicate like a classic network? -- You might be interested in such thing: https://github.com/fepitre/qubes-mgmt-salt-qubes-server/blob/devel-140320/qubes-server.png I'm currently working on several adjustment recently (not pushed) but for you case, you might want to start by using usual "bridge" for which we have support of this in QubesOS-contrib: dom0 component: https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device vm component: https://github.com/QubesOS-contrib/qubes-core-agent-linux-addon-bridge-device When this installed, in a given AppVM named for example "lan-net", with NetworkManager you can create a bridge interface named for example "br0" that will be made available as bridge device to be attached. Then, in dom0, running "qvm-device bridge" will show you the bridge created in "lan-net". At this point, this is exactly like USB, BLOCK or MIC devices. You can attach an AppVM named for example "personal" to this bridge (meaning it will have an interface that is linked into the bridge): "qvm-device bridge attach personal lan-net:br0". You can do that for multiple VMs, and then, you would have local classical network between several VMs. Even more, you can attach a physical interface into "br0" and link external network with other machines. Notes: - It supports options like: "qvm-device bridge attach personal lan-net:br0 --option=ip=192.168.0.1 --option=netmask=255.255.255.0 --option=gateway=192.168.0.254" - Be careful that using standard bridge network model is NOT the Qubes model using NAT and based on isolation of each component. - You would need to probably adjust iptables if your "lan-net" has a NetVM. I plan to make proper README and documentation describing this and also related Qubes-server formula soon. In the mean time I can help here or on discourse. Best, Frédéric -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/187fb4d0-a475-0a95-8c9f-a9b9ce3aa441%40qubes-os.org. OpenPGP_signature Description: OpenPGP digital signature
