[qubes-users] RAID6 as secondary storage and thin pool
I'm currently evaluating the possibility of moving my workstation to Qubes OS and ran into a problem. It's using an SSD for Qubes OS, but I want to use HDDs with RAID6 to hold qubes data. I've been using the secondary storage guide and slightly altered it for RAID6: I ran "sudo cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdx" for 5 test HDDs. Then I added their UUID to /etc/crypttab and rebooted. After than I ran "sudo pvcreate /dev/mapper/luks-[UUID]" for the 5 drives. I created a volume group with "sudo vgcreate qubeshd0 /dev/mapper/luks-UUID1 /dev/mapper/luks-UUID2 " Then I did this: sudo lvcreate -i 3 --type raid6 -L 10G -n poolhd0 qubeshd0 sudo lvconvert --thinpool qubeshd0/poolhd0 sudo lvextend -l +100%FREE qubeshd0/poolhd0 This seems to give me a RAID6 thin pool with the correct size. I created VMs and used this pool for data storage and everything seems to work fine. So far so good. After that I wanted to go through some other scenarios like adding HDDs to the RAID (growing it) or replacing faulty hdds. I was able to add a new HDD to the volume group but after that I got stuck, since I was unable to add the new free space to the RAID6. Everything I tried gave me an error. One of them was that thin pool did not support the operation. I also tried it without converting to thin pool but still was unable to extend the RAID6. Things like this are the reason why I wanted to simulate/evaluate everything first before actually moving everything. How can I extend the 5 hdd RAID6 to 6 hdds (and higher)? Over time the final target would be to grow the RAID to around 10-12 HDDs. Was that even correct how I implemented it? What would be the best way to accomplish it? -- 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/6d172d18-ac61-4ee7-aa6c-7a4219ff9d45n%40googlegroups.com.
Re: [qubes-users] EFI / UEFI guest
Hi, I stumbled upon https://wiki.xenproject.org/wiki/OVMF and wondered if this is already implemented into QubesOS. What's the current status here? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7d9bf987-55cd-4393-bc3a-1c74fafd5395%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4
> Could you try this: > qvm-prefs sys-firewall | grep netvm > it should say sys-net? Y/N yes, result is sys-net > Even if it states sys-net, let's try to force it again > qvm-prefs sys-firewall -s netvm sys-net that command did not work due to wrong syntax, so I did: qvm-prefs --set sys-firewall netvm sys-net If sys-firewall is shut down, the command works. If sys-firewall is running, the command fails with the error: "no such preoperty: 'netvm'", in addition if sys-firewall is running while I do this, the eth0 interface is removed from sys-firewall. > and try the arp -an in sys-firewall again Still the same result: ? (10.137.0.5) at on eth0 Maybe I should try to look into the script(s) that are running when using "qvm-prefs --set sys-firewall netvm sys-net"? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/72a9400d-c705-4360-b0c1-b55afe3a496d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4
A friend was using my PC and forgot to logout, so I accidently posted with his account. So here it goes again: > This is probably just because it tries to resolve the IPs and DNS times out. > if you use netstat -nr, it should be fast. Yes, using "netstat -nr" I get a result immediately in sys-firewall: Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.137.0.5 0.0.0.0 UG 0 0 0 eth0 10.137.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 > could you please do the arp -an after the ping 8.8.8.8 "arp -an" in sys-net displays: ? (192.168.0.2) at xx:xx:xx:xx:xx:xx [ether] on enp0s0 (xx:xx:xx:xx:xx:xx is a valid mac address, I just replaced the actual values with X's) "arp -an" in sys-firewall displays: ? (10.137.0.5) at on eth0 -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/837b117e-630b-46bf-9094-aff730d15a6b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4
> Can you also try doing this against the template you're using for your > sys-firewall? > > qvm-features fedora-26-minimal qubes-firewall 1 I did this and restarted everything, no difference. > Yes probably. For reference, to check (or enable): > - go to start menu/System Tools/Qube Manager > - right click sys-net/Qube Settings/Services tab > - clocksync should be in the list and ticked if not type clocksync and click > on + > - I think a full reboot is required. There are probably ways to avoid it... clocksync is checked. > I am confused, did you do this in sys-net or sys-firewall. Because sys-net > would have a default route and a route for your Lan. You may have tripped the > info which is fine. In fact I left the default routes away and just focused on the missing one. When I start sys-firewall a new network interface is added (vifx.0) where x is a number. "ifconfig -a" displays: vif3.0: flags=4098 mtu 1500 (and also 2 default interfaces: enp0s0 and lo, which are both UP and RUNNING) I noticed here that "UP" / "RUNNING" is missing for the vif, therefore I have to "up" it myself. This might be part of the problem, since it has to be running in order to add a new route (which should be done automatically). So "route" in sys-net displays only the default routes: Destination Gateway Genmask Flags Metric Ref Use Iface default gateway 0.0.0.0 UG 100 0 0 enp0s0 192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0enp0s0 So if I add the route myself it additionally displays: 10.137.0.6 0.0.0.0 255.255.255.255 U 100 0 0vif3.0 So far so good, the values in sys-net are looking "ok" to me now. Or am I missing something? > on sys-firewall, you are probably going to need to ifconfig eth0 up and you > should have something like this: > -bash-4.4# netstat -nr > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 0.0.0.0 10.137.0.14 0.0.0.0 UG0 0 0 eth0 > 10.137.0.14 0.0.0.0 255.255.255.255 UH0 0 0 > eth0 On sys-firewall eth0 and lo are UP and RUNNING, but "route" takes around 20 seconds to finish and displays: Destination Gateway Genmask Flags Metric Ref Use Iface default gateway 0.0.0.0 UG 0 0 0 eth0 gateway 0.0.0.0 255.255.255.255 UH 0 0 0eth0 The long waiting time before "route" finishes makes me wonder... I deleted the default routes and recreated them. I also restarted the eth0 interface. When I try to ping 8.8.8.8 from sys-firewall I get: >From 10.137.0.6 icmp_seq=1 Destination Host Unreachable >From 10.137.0.6 icmp_seq=2 Destination Host Unreachable ... I also switched the templates of sys-net and sys-firewall to debian-9, but the result is the same (vif down in sys-net, no route for vif). The more I try to fix this, I get a feeling that the root of the problem lies inside sys-net. It seems like the vif in sys-net does not get "up", which breaks the setup/initialization script (or maybe it breaks earlier, I don't know). If I knew, which steps have to be done to set up network between a VM, sys-firewall and sys-net correctly, I could try to pinpoint the problem better. What happens exactly behind the scenes when sys-firewall starts and uses sys-net as netVM? Also I was thinking if iptables might be involved here?! -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/785727e5-718e-4709-b395-3dd2ebfbc647%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4
Ok, I set up 2 new VMs (sys-net and sys-firewall) in case something went wrong during the setup, but the result was the same as before. Not sure how to enable the clocksync service in sys-net (fedora-26 template) but the date/time settings are correct, so I assume it already is syncing correctly. But I did some more research and this is what I found out so far is: sys-net itself has a working internet connection (I can do "ping www.google.com" in a terminal and everything is fine). Also other VMs that use sys-net directly as netVM can access the internet (i.e. ping a server etc.). The only exception is sys-firewall, in which a ping just fails due to no connection. When sys-firewall starts up, a new vif is created inside sys-net (which was expected), but there is no route created. When I tried to create a new route it said "Network is down". So it did "ifconfig vif8.0 up" and afterwards added a new route with: "sudo ip route add 10.137.0.15 dev vif8.0 metric 32752" "route -v" displays: 10.137.0.15 0.0.0.0 255.255.255.255 UH 32752 0 0 vif8.0 So at this point the ifconfig and route entries look exactly like on my other machine which is working fine out of the box. Unfortunately sys-firewall still does not have a working internet connection ("ping www.google.com" results in "Name or service not known" due to no DNS connectivity). So it seems like as soon as I create a new VM with "provides network" checked, it can not use the network connection of sys-net. Any other VM that does not provide network ifself can use sys-net directly and works fine. I think there is a problem with some kind of proxy setup in sys-firewall or something. Is there some documentation which steps are done regarding networking during the startup of sys-firewall, so I can try to do those steps manually one by one to see where the problem appears? 2018-02-26 22:38 GMT+01:00 Alex Dubois : > On Monday, 26 February 2018 03:48:29 UTC, thorsten...@gmail.com wrote: > > I installed Qubes 4.0-rc4 and have a problem with my internet connection. > > sys-net itself has a working internet connection but sys-firewall does > not. No need to mention that every other VM that uses sys-firewall as netVM > does also have no working internet connection. > > > > If I switch the default netVM from sys-firewall to sys-net (for > testing), dom0 can use it to update etc. Also any other VM gets internet > connection with sys-net as Networking VM. > > > > An update of dom0 from testing-repository did not fix the problem. > > Also switching the sys-firewall template from fedora-26 to debian-9 does > not help. > > > > I found a similar problem here: > > https://github.com/QubesOS/qubes-issues/issues/2141 > > > > So I checked the network interfaces and they are like this: > > > > sys-net: > > lo > > enp0s0 > > vif2.0 > > > > sys-firewall: > > eth0 > > lo > > > > Not sure, but I guess the vif interface is missing in sys-firewall? > > How do I fix this problem? > > vif interface will appear when a VM connects to it. > > Could you clarify the term no internet. > > I had a lot of problems solved once sys-net had the service clocksync > enabled (as it should). > > -- > You received this message because you are subscribed to a topic in the > Google Groups "qubes-users" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/qubes-users/oN204nGh63I/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > qubes-users+unsubscr...@googlegroups.com. > To post to this group, send email to qubes-users@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/qubes-users/46a6952f-6fd5-4aec-93ca-994937a24c5e%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAMtrDxQXO%3DHUyiimHZFx96meYT0oTJ-VxLq3DsbcquosRh7eFg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] firewall/proxy VM not working with Qubes 4.0-rc4
I installed Qubes 4.0-rc4 and have a problem with my internet connection. sys-net itself has a working internet connection but sys-firewall does not. No need to mention that every other VM that uses sys-firewall as netVM does also have no working internet connection. If I switch the default netVM from sys-firewall to sys-net (for testing), dom0 can use it to update etc. Also any other VM gets internet connection with sys-net as Networking VM. An update of dom0 from testing-repository did not fix the problem. Also switching the sys-firewall template from fedora-26 to debian-9 does not help. I found a similar problem here: https://github.com/QubesOS/qubes-issues/issues/2141 So I checked the network interfaces and they are like this: sys-net: lo enp0s0 vif2.0 sys-firewall: eth0 lo Not sure, but I guess the vif interface is missing in sys-firewall? How do I fix this problem? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a028078a-1514-4be8-bb00-134326f1fae1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Intel Core i7-920 - Qubes 4.0-rc4 problem ("no IOMMU?" in libxl-driver.log)
I'm currently running Qubes 3.2 on a Intel Core i7-920 processor just fine. Now I wanted to test the new Qubes 4.0-rc4 and ran into some issue. The installer tells me, there is no vt-d/.../... support available, although it should be fine. VT-d is enabled in bios and hyper-v or vmware are fully functional on that machine under Windows. So I thought it was a false warning and decided to continue the installation leading to another error message when the configuration tries to run sys-net. After Qubes OS was booted, the sys-net etc. were not started automatically, so I tried to run then manually which ended in the same error message. libxl-driver.log displays "PCI device cannot be assigned - no IOMMU?" Since my search for a solution to this problem led nowhere (entries on mailing lists and google) I wanted to ask here in this mailing list. I checked the minimum requirements on Qubes 4.0 to make sure the hardware meets them: 64-bit Intel or AMD processor (x86_64 aka x64 aka AMD64) ---> YES (Intel Core i7-920) Intel VT-x with EPT or AMD-V with RVI --->YES (ark.intel.com lists "VT-x with EPT") Intel VT-d or AMD-Vi --->YES (VT-d is enabled in BIOS) 4 GB RAM --->YES (16 GB RAM available) 32 GB disk space --->YES (256GB USB 3.0 Stick for testing) Also something weird to mention: After some reboots (while trying to fix the issue) the sys-net and sys-firewall were automatically started (displaying 2 console windows, showing the boot of these VMs, which is not the case in Qubes 3.2). This happened only once and I could not reproduce this anymore. So now I'm stuck with the "no IOMMU?" error in libxl-driver.log. Any idea what the problem is and how it can be solved? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAMtrDxRhEnJnO6jk7yBmp1ffROmR1TuJdrQ3D%3Dh%3DsUhfj0BJ1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.