Re: [Xen-users] Cheap IOMMU hardware and ECC support importance

[Gordan Bobic <gordan@xxxxxxxxxx>]

On 07/10/2014 03:25 AM, lee wrote:
> Gordan Bobic <gordan@xxxxxxxxxx> writes:
>
> > > On 2014-07-09 02:13, lee wrote:
> > > > For domU, you put it on whatever volume the rest of the domU
> > > > filesystems are on.
> > > Without swap partitions?
> > No, partition the domU virtual disk inside the domU in any
> > way you like, including swap partitions.
> How would I have a virtual disk?  Do you mean I should put the VM images
> into a file residing on a ZFS file system of dom0?
Something like that. Or you can create a zvol and use that (that's what 
I do). zvol is roughly like an LVM volume in zfs. It exposes a block 
device rather than a file system, but you can still do things like 
snapshotting and send/receive on it.
> > The entire premise is wrong - you cannnot meaningfully gain information
> > from a test without understanding the test.
> That's why I'm saying it's not such a great example.  You need to
> understand what it attempts to show to make you understand before it
> shows it.
Maybe it should have been explained more extensively.

> > Or you could encrypt your data before becking it up. If you use
> > something like encfs, you  can back up the underlying encrypted
> > data rather than the unencrypted data. That way it doesn't matter
> > how they store it.
> I'd have to make a huge tar archive or something of my data and encrypt
> that with gpg before uploading it.  That isn't really feasible.
No, encfs is a layer and stores each encrypted file and filename as 
normal, they are just encrypted. So when you mount the encrypted data to 
a mount point, it's available unencrypted. When you look at the 
encrypted directory tree, the file names and contents are scrambled.
So to back it up, you back up the encrypted subtree directly. No need 
for intermediate steps.



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users