Marek Marczykowski-Górecki:
> On Mon, Jun 20, 2016 at 06:35:14PM +0000, entr0py wrote:
>> 3. add file as disk device to /var/lib/qubes/appvms/myappvm.conf:
>>    <disk type='block' device='disk'>
>>       <driver name='phy' />
>>       <source dev='/var/lib/qubes/storage/myfiles.img' />
>>       <target dev='xvde' bus='xen' />
>>    </disk>
> 
> 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.

Reply via email to