Re: [qubes-users] Adding New Disk Image to VM
Marek Marczykowski-Górecki: > On Mon, Jun 20, 2016 at 06:35:14PM +, entr0py wrote: >> 3. add file as disk device to /var/lib/qubes/appvms/myappvm.conf: >> >> >> >> >> > > This config file is regenerated each time the VM is started, so your > changes will have no effect... > > Recently I've posted an instruction about triggering qvm-block on VM > startup to achieve the same effect. Take a look here: > https://groups.google.com/d/topic/qubes-users/RogG5rXG_Pw/discussion > Thanks! Saw that but didn't realize it was relevant (and this would have been easier :/ ) Andrew David Wong: > On 2016-06-20 11:35, entr0py wrote: >> Would appreciate if someone could check that I'm not doing >> something stupid... (Don't see any docs regarding this.) > > I think the reason there are no docs for this is that this seems like > going out of your way to use Qubes in a way that it was not intended > to be used. (Of course, you're perfectly within your rights to do that.) > >> Use case: I want to store my Documents on a separate .img (on same >> Qubes SSD) so that only config files remain on my appVM. This >> should ease the upgrade process when I want to start with fresh >> appVMs and reduce chances of user error / corruption of frequently >> moving large existing files. > > So, as you probably know, Qubes is designed with the expectation that > users will store their data (and config files) in AppVMs. Normally, > there's not much reason to need to "start with fresh AppVMs" due to > the way TemplateVMs work. (You already "start fresh" with respect to > the root filesystem each time you restart an AppVM anyway.) > > I'm not saying any of this to try to dissuade you from doing what you > want to do. I'm just offering another perspective and suggesting that, > depending your goals, this might not be necessary. > Your input is always appreciated. I don't think what I'm trying to do is un-Qubes-like at all. After all, we are trying to isolate and compartmentalize independent aspects of our systems. (This benefits not just security but scalability as well). (Isn't StorageVM on the horizon?) My Documents (perhaps Archives would be a more contrastful term) should **never** need to be moved because of any change in the underlying Operating System - regardless of how rarely such events might occur. (Perhaps due to my ignorance, or unwillingness to research how config files function for each component of my Template,) I tend to perform fresh installs of my appVMs with any major change in the underlying Template. For example, moving from Debian Jessie to Stretch may involve any or all of the following: Whonix 13 -> 14, LibreOffice 4 -> 5, KDE 4 -> 5, etc. These are major upgrades and I don't want to assume that the devs have correctly anticipated all the prior configs that will work properly or optimally. In addition, appVMs can get polluted with scripts and bind-directories in /rw. I could just manually delete config directories but like I said, I can't anticipate what unintended consequences that might have unless I actually research it. > In the rare case where we actually need to migrate all the data from > one AppVM to a new one, and there's a large amount of that data, I > think it makes sense to use conventional data-integrity-verification > tools to do that (just as you would if migrating the data from one > conventional OS to another). > Could you suggest some tools? I've been using tar --verify, qvm-copy, shasum, then hoping! that tar -xf doesn't corrupt anything :( Also, since I want to re-use some of the same VM names, and since I've had mixed results with renaming VMs in the past (in R2.x, not all .xml files got updated properly), I usually have to copy twice: first copy to an intermediary VM, delete original VM, create new VM with same name, copy from temp to new VM. Again, this would be fine for several GBs but not something I should ever have to do for 100's of GBs. Even migrating to another OS should not require moving troves of data, since most data these days is OS-agnostic. - ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- 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/57685560.7070403%40vfemail.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Adding New Disk Image to VM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-06-20 11:35, entr0py wrote: > Would appreciate if someone could check that I'm not doing > something stupid... (Don't see any docs regarding this.) > I think the reason there are no docs for this is that this seems like going out of your way to use Qubes in a way that it was not intended to be used. (Of course, you're perfectly within your rights to do that.) > Use case: I want to store my Documents on a separate .img (on same > Qubes SSD) so that only config files remain on my appVM. This > should ease the upgrade process when I want to start with fresh > appVMs and reduce chances of user error / corruption of frequently > moving large existing files. > So, as you probably know, Qubes is designed with the expectation that users will store their data (and config files) in AppVMs. Normally, there's not much reason to need to "start with fresh AppVMs" due to the way TemplateVMs work. (You already "start fresh" with respect to the root filesystem each time you restart an AppVM anyway.) Of course, there might be some reason to roll back to the previous state of an AppVM, but that's what backups are for. In the rare case where we actually need to migrate all the data from one AppVM to a new one, and there's a large amount of that data, I think it makes sense to use conventional data-integrity-verification tools to do that (just as you would if migrating the data from one conventional OS to another). I'm not saying any of this to try to dissuade you from doing what you want to do. I'm just offering another perspective and suggesting that, depending your goals, this might not be necessary. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXaEAwAAoJENtN07w5UDAw5lcP/RMrkmQFcTKvo6HU4BnG2vmp V0hcScH3E6JkT7AmRns0YlS74bsngaLzRV3DNQVJGto/yuQ2YS2O7IUvWDd2IZLB bPvCCKOy2dmIxFcEE9GYNbJ2UD+PqR5JhbffgB8SHi8oBk2cGu0mT5yfdqp2NBq2 vzG7phFYoLLoBMQBepGKaxZGS0dmwhOvzY4YpafoykTy7ihxQgEOTYO/AA3QOFrq +qrpdehFleTBpvPsRb6Z+3SUO8eJgpmPGMEEIJmhDp2VIJU8bC7IjupK3LN7JaAQ rslyAH9xL55JwXhsghuM4HFa14lcrBR6EYCCdIHRBYg/rnQMkxdPWlPnsLSSK+ri muOOCWzRJz1oNFFSH1OwNBxLP534SofY6RgZZzC02HFHTuJzKsMkCcMb681pHQKk szy15Qcfvf2JLFxB+UjG9kls0qtv8eCeHMXIzeAgou05K5rf5tqKaNQKELO8YiM+ BSj0hMvVHykc1xoQxo0rZfHNDynyHCoYPB7mi0oe4bJ6iS0vj/3IaAcwEEjof8E3 JOqstIqrhFRLMv6IocXmQ6TOhhS5mDbvyY6fPZv7iWH1/mgyO9eNOaW3RmuCTIcu U/1ikefi6HoJ9C2fYSiEvcu6Y1D3yIsg+ysszu7eezYmBy4UOoNWASeb9qpelOQ1 wLdHy4bZcPqCVDXRcGEM =5UNE -END PGP SIGNATURE- -- 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/5dc5b829-b752-7c21-0914-3129a56a8873%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Adding New Disk Image to VM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jun 20, 2016 at 06:35:14PM +, entr0py wrote: > Would appreciate if someone could check that I'm not doing something > stupid... (Don't see any docs regarding this.) > > Use case: I want to store my Documents on a separate .img (on same Qubes SSD) > so that only config files remain on my appVM. This should ease the upgrade > process when I want to start with fresh appVMs and reduce chances of user > error / corruption of frequently moving large existing files. > > Steps: > > 1. create sparse file in dom0: >`dd if=/dev/zero of=/var/lib/qubes/storage/myfiles.img bs=1024k seek=1 > count=0` You can use sparse files to save some space: truncate -s 10G /var/lib/qubes/storage/myfiles.img > 2. create filesystem on sparse file: >`mkfs -t ext4 myfiles.img` > > 3. add file as disk device to /var/lib/qubes/appvms/myappvm.conf: > > > > > This config file is regenerated each time the VM is started, so your changes will have no effect... Recently I've posted an instruction about triggering qvm-block on VM startup to achieve the same effect. Take a look here: https://groups.google.com/d/topic/qubes-users/RogG5rXG_Pw/discussion > 4. add /dev/xvde to /etc/fstab in appVM: >/dev/xvde /home/user/storage ext4 defaults,noatime 0 0 > > 5. start appVM > > Any issues? TIA! - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXaD/GAAoJENuP0xzK19css1cIAJMLGDAF3OJMgoUAYfGy/8lG LKkeMKn7tCJ8beuQ0WO+mDz4C4O3Na1p3x3M9ItEpLz079JmLh3Etm5YaPcjWz4w qPst5QRwMVXxYt7MglDMJFriEO2/yJ662598QNk9RblxWxjZeBICNIjbqFf33k8Q Tg/CUAIS2FB6qoYXMg2Z6CLFNaa1FUjtR2RkVJ7OJVlraEt9nAUSdbbe6HOmSaJp 9xB88hk1LwDT2wQI9OQKKfYVTuhCecp5aiA0DaPBrH0pD9tz/7RipAlRucikdz+L iarLIF3J9ZClxFfhdkJaiTEKnVb5u/ViHyr29DfjTlwr7cU3gPF7WT0ZSUZRRBM= =r80r -END PGP SIGNATURE- -- 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/20160620191101.GU1593%40mail-itl. For more options, visit https://groups.google.com/d/optout.
