Trimming the TemplateVM root filesystem

[Matt McCutchen]

My dom0 is very tight on disk space; I should probably buy a larger disk but haven't done so yet.  Yesterday, my dom0 filled up and the TemplateVM crashed in the middle of a yum transaction, which was harder than expected to recover due to a yum bug (for the curious: https://bugzilla.redhat.com/show_bug.cgi?id=1164041).  Obviously I take responsibility for not watching more carefully, but one contributing factor I wasn't expecting is that discard isn't enabled on the TemplateVM root filesystem.  I was pleased to note several weeks ago that it is enabled on VM private filesystems, but I didn't think of the TemplateVM root filesystem.

Please consider documenting this more prominently, for example, by appending the following to https://qubes-os.org/wiki/SoftwareUpdateVM#HowTemplateVMworksinQubes (which I remember reading before):

"""
Unlike VM private filesystems, the template VM root filesystem does not support discard, so deleting files does not free the space in dom0.  See [FedoraTemplateUpgrade#Compactingtemplatesroot.img these instructions] to recover space in dom0.
"""

The problem with discard on the TemplateVM root filesystem is that dm-snapshot doesn't support it, right?  I see some discussion of adding such support at http://www.redhat.com/archives/dm-devel/2011-April/msg00113.html , but it looks like the effort was abandoned.

[cprise]

--

There is probably some way you could temporarily attach the template root image as a secondary drive to a standalone vm (or an appvm that depends on a different templatevm) and use the fstrim command there.

Also, I think(?) just creating a standalone vm from a template will create a trimmed version of the root image in the standalonevm's directory. If not, then you can boot the standalonevm and run 'fstrim /'. Then you could replace the template's root image with the one from the standalonevm. This requires creating a copy of an entire root filesystem, however.

[Marek Marczykowski-Górecki]

On Fri, Nov 14, 2014 at 05:02:37PM -0800, Matt McCutchen wrote:
> My dom0 is very tight on disk space; I should probably buy a larger disk
> but haven't done so yet. Yesterday, my dom0 filled up and the TemplateVM
> crashed in the middle of a yum transaction, which was harder than expected
> to recover due to a yum bug (for the curious:
> https://bugzilla.redhat.com/show_bug.cgi?id=1164041). Obviously I take
> responsibility for not watching more carefully, but one contributing factor
> I wasn't expecting is that discard isn't enabled on the TemplateVM root
> filesystem. I was pleased to note several weeks ago that it is enabled on
> VM private filesystems, but I didn't think of the TemplateVM root
> filesystem.
>
> Please consider documenting this more prominently, for example, by
> appending the following to
> https://qubes-os.org/wiki/SoftwareUpdateVM#HowTemplateVMworksinQubes (which
> I remember reading before):
>
> """
> Unlike VM private filesystems, the template VM root filesystem does not
> support discard, so deleting files does not free the space in dom0. See
> [FedoraTemplateUpgrade#Compactingtemplatesroot.img these instructions] to
> recover space in dom0.
> """

Thanks, added.

>
> The problem with discard on the TemplateVM root filesystem is that
> dm-snapshot doesn't support it, right?

Exactly.

> I see some discussion of adding
> such support at
> http://www.redhat.com/archives/dm-devel/2011-April/msg00113.html , but it
> looks like the effort was abandoned.
>

--
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?

[cprise]

I discovered this actually works without having to duplicate any root image files.

First shut down the target templatevm and create a new appvm (I'll call it 'fstrim-temp') using a trusted template (and without networking) and start it, then:

dom0$ qvm-block -A fstrim-temp dom0:/var/lib/qubes/vm-templates/fedora-20-x64/root.img

Next, in the appvm...

$ cd; mkdir rootimg; sudo mount /dev/xvdi rootimg
$ sudo fstrim -m 4096 /home/user/rootimg
$ sudo umount rootimg
$ sudo halt

This cut the size of 2 of my large templates nearly in half, recovering about 8GB. I also found out you can run this from an appvm that depends on the target template (though I'm not sure if that is really safe).

[Matt McCutchen]

On Sun, 2014-11-16 at 23:53 -0500, cprise wrote:
> I discovered this actually works without having to duplicate any root
> image files.
>
> First shut down the target templatevm and create a new appvm (I'll
> call it 'fstrim-temp') using a trusted template (and without
> networking) and start it, then:
> dom0$ qvm-block -A fstrim-temp
> dom0:/var/lib/qubes/vm-templates/fedora-20-x64/root.img
> Next, in the appvm...
> $ cd; mkdir rootimg; sudo mount /dev/xvdi rootimg
> $ sudo fstrim -m 4096 /home/user/rootimg
> $ sudo umount rootimg
> $ sudo halt

Nice. I wanted to learn how to do that and am glad it's so simple.

> I also found out you can run this from an appvm that depends on the
> target template (though I'm not sure if that is really safe).

I spent some time thinking about this because it made an interesting
puzzle. I imagine that it's safe as long as each running dependent
AppVM has booted from root.img and an empty root-cow.img file and
root.img hasn't changed since then. In that case, the AppVM's root
filesystem has evolved from root.img with blocks written by the AppVM
being written to /dev/xvdc2. So the discards that the AppVM will see
are of the blocks that were free at boot time and have never been
written by the AppVM since then. I'd think that a typical filesystem
implementation wouldn't rely on the contents of such blocks. The only
way a filesystem could break that wouldn't be totally gratuitous would
be to notice that a free block happens to contain the same data it wants
to store and reference the block without rewriting it, but my
understanding is filesystems don't do that because it's slower on
average than just writing.

If root-cow.img is nonempty when the AppVM boots, or root.img changes
later, then the AppVM's view of the filesystem may reference blocks of
root.img that are no longer referenced by the filesystem in root.img, so
trimming root.img could corrupt the AppVM's view.

If the TemplateVM is running and no dependent AppVMs are running,
trimming will cause no immediate problem but may break the invariant
that (root.img + root-cow.img) is a valid filesystem, so it will be
unsafe to start any dependent AppVMs until the TemplateVM stops and is
committed, so it's probably better not to do this.

I could imagine the Qubes VM Manager keeping track of which TemplateVMs
might need trimming, showing an icon like the "outdated" one for AppVMs,
and automatically trimming them when safe. It would be better if
dm-snapshot would just gain discard support, though there are design
issues there I haven't fully explored. I don't think either is worth
doing right now. :/

Matt

[cprise]

Actually it should be fine as long as 1) the filesystem instance used to
alter the root.img is single layer (no COWs), and 2) its also the only
one with write access (Templatevm not running).

I also tried it with 'mount -r' for read-only and that worked, too, so
the stored filesystem is safe... the only thing changing is the status
of some de-allocated blocks.

[cprise]

On 11/18/14 00:49, Matt McCutchen wrote:

[...]

You might also be interested in my post titled "HOWTO: Enable Cron and
Anacron in Fedora VMs". It uses daily fstrim commands for appVM /rw
images as an example. This results in TRIM commands being performed in a
daily batch operation instead of on-the-fly as is the Qubes default.

[Marek Marczykowski-Górecki]

Exactly - while TemplateVM isn't running, the fstrim operation should be
safe. You should not modify used data block in root.img though - running
AppVMs (including that one used to fstrim) can get confused. So mount -r
is a good idea.

[Matt McCutchen]

I'm not sure if this was clear from my previous message: in addition to
1) and 2) above and trimming via a read-only mount, there should be no
running AppVMs using the root.img with non-empty root-cow files.
Otherwise the following sequence can occur:

- Start the dependent AppVM.
- Start the TemplateVM, delete some file F (the original contents of
blocks affected by this deletion, such as the directory entry and inode,
get written to root-cow), and stop the TemplateVM.
- Trim root.img. The data blocks of file F are discarded.
- File F's directory entry and inode still exist in the AppVM's view.
The AppVM reads file F's data and gets garbage.

Matt

[cprise]

Might be useful to have a Qubes 'maintenance mode' where certain offline
tasks are run, such as trimming root filesystems (and eventually
scanning for malware). You could put it in the Manager's System menu
where the user can run it as a prelude to running backups.

[7v5w7go9ub0o]

On 11/18/14 14:08, cprise wrote:

[snip...]

>
>
> Might be useful to have a Qubes 'maintenance mode' where certain
> offline tasks are run, such as trimming root filesystems (and
> eventually scanning for malware). You could put it in the Manager's
> System menu where the user can run it as a prelude to running backups.
>

+1

(trimming would be a great initial entry!)

[Marek Marczykowski-Górecki]

Indeed.
Anyway trimming root.img shouldn't be necessary too often. For example
on my system I trimmed the image right after Fedora 18->Fedora 20
upgrade (more than half a year ago) and for now fstrim would save about 2GB,
which is quite small compared to >150GB of real data in the VMs
(private.img).

[7v5w7go9ub0o]

On 11/18/14 14:22, Marek Marczykowski-Górecki wrote:

[snip]

> Indeed.
> Anyway trimming root.img shouldn't be necessary too often. For example
> on my system I trimmed the image right after Fedora 18->Fedora 20
> upgrade (more than half a year ago) and for now fstrim would save about 2GB,
> which is quite small compared to >150GB of real data in the VMs
> (private.img).
>

Not too often indeed!

"....Running fstrim frequently, or even using mount -o discard, might
negatively affect the lifetime of poor-quality SSD devices. For most
desktop and server systems the sufficient trimming frequency is once
a week. Note that not all devices support a queued trim, so each
trim command incurs a performance penalty on whatever else might be
trying to use the disk at the time........"

<http://man7.org/linux/man-pages/man8/fstrim.8.html>



But some argue that trim is less a space saver, and much more a
performance tool:



".......as time goes on the SSD performance degrades more and more,
because for every write it has to go through a cycle of
read-erase-modify-write. This is known as “write amplification”.

TRIM was invented for solving this problem, ........"

<http://fcns.eu/2013/09/12/improve-ssd-performance-with-fstrim/>



Either way, it would be nice to have Qubes 'maintenance mode' as
suggested by cprise.

[Marek Marczykowski-Górecki]

But, this requires that TRIM is passed through encryption layer (which
can be enabled, but isn't by default). Otherwise it is only dom0 space saver.

> Either way, it would be nice to have Qubes 'maintenance mode' as suggested
> by cprise.

Do you mean "qvm-shutdown --all --wait"? ;)

[cprise]

At the bare-metal level its mainly a performance issue. In disk images
it becomes about space.

As for the warning about lifetime, I'd expect TRIM to have the opposite
effect: The more the drive knows about unused space, the more
intellegenty it can distribute or avoid the effects of write-amplification.

> But, this requires that TRIM is passed through encryption layer (which
> can be enabled, but isn't by default). Otherwise it is only dom0 space saver.
>
>> Either way, it would be nice to have Qubes 'maintenance mode' as suggested
>> by cprise.
> Do you mean "qvm-shutdown --all --wait"? ;)
>

Well... could also be more selective than that :) BTW, that command
would be a great addition to the shutdown sequence (avoid the
busy-waiting)...

[Marek Marczykowski-Górecki]

It is already there... There was some timeout issue, but in most recent
packages it should be fixed. Have you checked the packages in
current-testing?

[cprise]

On 11/18/14 20:22, Marek Marczykowski-Górecki wrote:
> It is already there... There was some timeout issue, but in most
> recent packages it should be fixed. Have you checked the packages in
> current-testing?

Not since I reinstalled R2b3. I'll check it out.

Also, I noticed what may be an architectural issue with Qubes updates
when it comes to packages like Xen. When I had recently updated my
templateVMs but said 'No' to the dom0 update -- and both sides had Xen
updates -- I subsequently (without thinking) rebooted the system and
found that networking no longer worked; there was a breakdown in
communication between VMs. Luckily, the update packages were already
waiting in dom0 (downloaded but not installed) so I could quickly
resolve the problem.

It could have been a fluke, or it could have been another updated
package besides Xen... but my feeling is this is an actual pitfall when
updating certain components in Qubes. Tying updates of dom0 and the
default templateVM together might be a good idea so that at least one
set of VMs continues to function when a change in hypervisor/client code
must occur in unison.

[Marek Marczykowski-Górecki]

It shouldn't matter. The only case when you really need to update dom0
and VMs at the same time is major system upgrade (R1->R2, R2->R3 etc).
Besides that, VM-dom0 and VM-VM communication protocols stays the same.
Some new features could require you to upgrade both dom0 and VM to get
it working, but the already present functionality (especially such a
basic one like network connectivity) should not stop working.

[cprise]

On 11/18/14 20:22, Marek Marczykowski-Górecki wrote:

> On Tue, Nov 18, 2014 at 07:57:06PM -0500, cprise wrote:
>> On 11/18/14 15:10, Marek Marczykowski-Górecki wrote:
>>> Do you mean "qvm-shutdown --all --wait"? ;)
>>>
>> Well... could also be more selective than that :)
>> BTW, that command would
>> be a great addition to the shutdown sequence (avoid the busy-waiting)...
> It is already there... There was some timeout issue, but in most recent
> packages it should be fixed. Have you checked the packages in
> current-testing?
>

FYI, I'm on current-testing for dom0 and vms, and a simple
shutdown/reboot still has the same problem: About 40s of hot, high fan
speed busy waiting... every time.

If I first do "qvm-shutdown --all --wait" (but sometimes have to
manually kill a VM) it never goes to high fan and its at least 30s quicker.

[Axon]

I only understood about half of this thread, but the prospect of
recovering several GBs of expensive SSD space by trimming my TemplateVMs
sounds very appealing. Is there any *safe* way to do this at the moment?
(I read cprise's instructions, but some of the replies later in the
thread seemed to suggest that it was a risky procedure...)

[Matt McCutchen]

On Sun, 2014-12-07 at 04:50 +0000, Axon wrote:
> I only understood about half of this thread, but the prospect of
> recovering several GBs of expensive SSD space by trimming my TemplateVMs
> sounds very appealing. Is there any *safe* way to do this at the moment?
> (I read cprise's instructions, but some of the replies later in the
> thread seemed to suggest that it was a risky procedure...)

Fortuitous timing, as I was about to send the following but was sitting
on it while I finished some unrelated urgent work, lest I be distracted
from that work by further activity on this thread.

Looks like I'll be trimming my TemplateVM for at least a little while
longer, so I went ahead and wrote a script to automate the process we
discussed:

https://mattmccutchen.net/private/qvm-trim-template

I plan to update this copy with any future enhancements I make.

This has at least one major hack and so may not be ready to be
officially recommended by Qubes, but hopefully it will be useful to some
people. If someone is interested enough to find a way to remove the
hack (possibly involving refactoring to Qubes proper), that would be
great.

Matt

[cprise]

Sorry, I caused the thread to veer off to an unrelated topic....

As Marek said on Nov. 18, it should be quite safe if you use read-only
option for mount. Matt's use of a dispVM in his script is a good idea
(if your dispVM template is trusted) and you can either run his script,
or adapt my initial instructions like so:

First shut down the target templatevm then:

# Create a dispVM with a CLI. Using xterm since gnome-terminal doesn't
work with this command.
dom0$ echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0
DEFAULT red

# Attach img of template to the dispVM. Change the file path if your
target is a different template...
dom0$ qvm-block -A type-dispVM-name-here
dom0:/var/lib/qubes/vm-templates/fedora-20-x64/root.img

# Next, in the dispVM terminal...
$ cd; mkdir rootimg; sudo mount -r /dev/xvdi rootimg
$ sudo fstrim /home/user/rootimg

$ sudo umount rootimg
$ sudo halt

Note the '-r' option added to mount to make the filesystem read-only. I
also removed '-m 4096' from fstrim because it doesn't improve efficiency
like I thought it did.

[cprise]

Thanks for posting it. I like the idea of using a dispVM. You might want
to add a cautionary note that other dispVMs should not run when this
script is running (because of the way you use the dispVM.xid file). What
we need is proper support for launching dispVMs from dom0.

A nice bonus at the end would be to show the img file size before and after.

[cprise]

On 12/07/14 03:08, Matt McCutchen wrote:

# This seems to trigger regeneration of the target TemplateVM's DisposableVM.
# It would be nice to suppress that.

The mtime of the root.img file is what triggers regeneration. You could supress it by storing the mtime at the start of the process, then restoring it to root.img at the end.

[Matt McCutchen]

On Sun, 2014-12-07 at 05:13 -0500, cprise wrote:
> You might want
> to add a cautionary note that other dispVMs should not run when this
> script is running (because of the way you use the dispVM.xid file).

AFAICT this race already affects /usr/lib/qubes/qfile-daemon-dvm itself,
hence I don't see grounds to document it specifically for
qvm-trim-template.

> A nice bonus at the end would be to show the img file size before and after.

Sure, why not. Done.

On Sun, 2014-12-07 at 05:46 -0500, cprise wrote:
> # This seems to trigger regeneration of the target TemplateVM's
> DisposableVM.
> # It would be nice to suppress that.
>
> The mtime of the root.img file is what triggers regeneration. You
> could supress it by storing the mtime at the start of the process,
> then restoring it to root.img at the end.

This might be harmful inasmuch as trimming might be a meaningful change
from the point of view of some sysadmins or backup tools (I don't know
about the Qubes one specifically). Is there a way to instead mark the
DisposableVM as valid for the new mtime?

Matt

[saltyk...@gmail.com]

Just shared this on the devel mailing list, but thought I'd post it here too: http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html, a blog post from a cryptsetup dev..

[Marek Marczykowski-Górecki]

On Sun, Dec 07, 2014 at 06:40:54PM -0500, Matt McCutchen wrote:
> On Sun, 2014-12-07 at 05:13 -0500, cprise wrote:
> > You might want
> > to add a cautionary note that other dispVMs should not run when this
> > script is running (because of the way you use the dispVM.xid file).
>
> AFAICT this race already affects /usr/lib/qubes/qfile-daemon-dvm itself,
> hence I don't see grounds to document it specifically for
> qvm-trim-template.

/usr/lib/qubes/qfile-daemon-dvm uses lock (fcntl) on qubes.xml to prevent that
race.

> > A nice bonus at the end would be to show the img file size before and after.
>
> Sure, why not. Done.
>
> On Sun, 2014-12-07 at 05:46 -0500, cprise wrote:
> > # This seems to trigger regeneration of the target TemplateVM's
> > DisposableVM.
> > # It would be nice to suppress that.
> >
> > The mtime of the root.img file is what triggers regeneration. You
> > could supress it by storing the mtime at the start of the process,
> > then restoring it to root.img at the end.
>
> This might be harmful inasmuch as trimming might be a meaningful change
> from the point of view of some sysadmins or backup tools (I don't know
> about the Qubes one specifically). Is there a way to instead mark the
> DisposableVM as valid for the new mtime?

Yes, simply touch /var/lib/qubes/dvmdata/default-savefile.

[cprise]

FWIW, I'm assuming the trimmed filesystem is logically identical to the
pre-trimmed one (hence the precaution of mounting with read-only) and
that would be good enough for me at least to keep mtime the same.
Marek's solution is of course, better.

Qubes backup doesn't have differential features, although it does keep
track of each VM's last backup time in a separate file for display
purposes.

OTOH, all that becomes moot if you keep to a practice of only running
the fstrim script just after template updates, which seems like a good
idea from a maintenance perspective.

There is another possibility I discovered for performing the trim
operation: The e2fsck command can take '-E discard' as an option when
checking filesystem integrity, and this might make it convenient to trim
a volume without mounting it esp. if a filesystem check is also desired.

[cprise]

On 12/07/14 20:56, saltyk...@gmail.com wrote:
> Just shared this on the devel mailing list, but thought I'd post it here too:http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html, a blog post from a cryptsetup dev..

That applies to the devel thread, but not this one (this is the 'thin
provisioning' use case).

[Matt McCutchen]

On Mon, 2014-12-08 at 09:55 +0100, Marek Marczykowski-Górecki wrote:
> On Sun, Dec 07, 2014 at 06:40:54PM -0500, Matt McCutchen wrote:
> > On Sun, 2014-12-07 at 05:13 -0500, cprise wrote:
> > > You might want
> > > to add a cautionary note that other dispVMs should not run when this
> > > script is running (because of the way you use the dispVM.xid file).
> >
> > AFAICT this race already affects /usr/lib/qubes/qfile-daemon-dvm itself,
> > hence I don't see grounds to document it specifically for
> > qvm-trim-template.
>
> /usr/lib/qubes/qfile-daemon-dvm uses lock (fcntl) on qubes.xml to prevent that
> race.

Ah, you're right, so the original point is valid. I realized the race
in qvm-trim-template is a security problem: under the default policy, a
malicious AppVM could run a command in its own DispVM that would get
root.img attached instead of the DispVM started by qvm-trim-template.
I've changed qvm-trim-template to detect this race and exit with an
error.

Qubes maintainers, would you accept a patch to have qfile-daemon-dvm
print the name of the DispVM so qvm-trim-template can parse this output
via a pipe, or do you not want to condone this usage? I tried this and
got a deadlock because Python buffers outputs to pipes by default.
qvm-trim-template could pass the -u option or PYTHONUNBUFFERED
environment variable, but to avoid making assumptions about how
qfile-daemon-dvm is implemented, it's probably better to disable
buffering within qfile-daemon-dvm itself.

> > This might be harmful inasmuch as trimming might be a meaningful change
> > from the point of view of some sysadmins or backup tools (I don't know
> > about the Qubes one specifically). Is there a way to instead mark the
> > DisposableVM as valid for the new mtime?
>
> Yes, simply touch /var/lib/qubes/dvmdata/default-savefile.

And /var/run/qubes/current-savefile. I believe I have this working now.

Matt

[Matt McCutchen]

On Mon, 2014-12-08 at 07:23 -0500, cprise wrote:
> There is another possibility I discovered for performing the trim
> operation: The e2fsck command can take '-E discard' as an option when
> checking filesystem integrity, and this might make it convenient to trim
> a volume without mounting it esp. if a filesystem check is also desired.

I don't think the Qubes security model would consider this low enough in
attack surface to run in dom0, and I'm not interested in a filesystem
check per se, so I'll keep the current approach.

Matt

[Marek Marczykowski-Górecki]

On Thu, Dec 11, 2014 at 09:08:48PM -0500, Matt McCutchen wrote:
> On Mon, 2014-12-08 at 09:55 +0100, Marek Marczykowski-Górecki wrote:
> > On Sun, Dec 07, 2014 at 06:40:54PM -0500, Matt McCutchen wrote:
> > > On Sun, 2014-12-07 at 05:13 -0500, cprise wrote:
> > > > You might want
> > > > to add a cautionary note that other dispVMs should not run when this
> > > > script is running (because of the way you use the dispVM.xid file).
> > >
> > > AFAICT this race already affects /usr/lib/qubes/qfile-daemon-dvm itself,
> > > hence I don't see grounds to document it specifically for
> > > qvm-trim-template.
> >
> > /usr/lib/qubes/qfile-daemon-dvm uses lock (fcntl) on qubes.xml to prevent that
> > race.
>
> Ah, you're right, so the original point is valid. I realized the race
> in qvm-trim-template is a security problem: under the default policy, a
> malicious AppVM could run a command in its own DispVM that would get
> root.img attached instead of the DispVM started by qvm-trim-template.
> I've changed qvm-trim-template to detect this race and exit with an
> error.
>
> Qubes maintainers, would you accept a patch to have qfile-daemon-dvm
> print the name of the DispVM so qvm-trim-template can parse this output
> via a pipe, or do you not want to condone this usage?

I think it is ok, but only when explicitly requested by some command
line switch. In "normal" DispVM use case stdin/stdout of qfile-daemon-dvm
is used to transfer the file to open in DispVM, so no qfile-daemon-dvm
must not mess the output.
Implementing that switch, do not mess already existing options - there
are 3 mandatory options and 2 optional (we should finally implement
there proper cmdline parsing...). Perhaps the better option would be to
use some environment variable.

BTW We have some major rework of this code in our R3 roadmap, so there
will be possible to start new DispVM with simple qvm-start/qvm-run. But
there is long way to that state.

> I tried this and
> got a deadlock because Python buffers outputs to pipes by default.
> qvm-trim-template could pass the -u option or PYTHONUNBUFFERED
> environment variable, but to avoid making assumptions about how
> qfile-daemon-dvm is implemented, it's probably better to disable
> buffering within qfile-daemon-dvm itself.

Or simply call fflush.

[cprise]

What might be more interesting is a way to put a temporary lock on dvms
from dom0 so that only one instance can be run for such a maintenance
function.

Alternative is to create a 'Qubes-Maint-DoNotUse' appvm for performing a
function and then destroy it. This way you get control over the template
being used and other vms can't interfere.

[cprise]

No, I wasn't clear on that -- was definitely thinking using appvm /
dispvm for the fsck (just as they can be used for the fstrim).

[Matt McCutchen]

I meant stderr, like the other progress messages, so this should not
interfere with stdin/stdout usage.

The patch is attached. Once this is pushed as an update, I'll update
the published version of qvm-trim-template to use the new functionality.

> > I tried this and
> > got a deadlock because Python buffers outputs to pipes by default.
> > qvm-trim-template could pass the -u option or PYTHONUNBUFFERED
> > environment variable, but to avoid making assumptions about how
> > qfile-daemon-dvm is implemented, it's probably better to disable
> > buffering within qfile-daemon-dvm itself.
>
> Or simply call fflush.

I was mistaken: output to stderr is always unbuffered, and the problem
was with how qvm-trim-template was reading it. So never mind.

Matt

[Marek Marczykowski-Górecki]

I've included your tool in qubes-core-dom0 package. Most likely it will
be in 2.1.68 version of said package. Take a look here:
http://git.qubes-os.org/?p=marmarek/core-admin.git;a=commit;h=72e10fd06ba028a267db66f719e384d65db7c87a

The main idea is the same, some details differs:
- instead of DispVM, normal AppVM is created, started, then destroyed -
no problem with getting its name, also running commands is simpler
- added code to prevent DispVM regeneration

I hope I haven't missed any corner case...

[Matt McCutchen]

On Fri, 2015-01-16 at 04:40 +0100, Marek Marczykowski-Górecki wrote:
> I've included your tool in qubes-core-dom0 package. Most likely it will
> be in 2.1.68 version of said package. Take a look here:
> http://git.qubes-os.org/?p=marmarek/core-admin.git;a=commit;h=72e10fd06ba028a267db66f719e384d65db7c87a
>
> The main idea is the same, some details differs:
> - instead of DispVM, normal AppVM is created, started, then destroyed -
> no problem with getting its name, also running commands is simpler
> - added code to prevent DispVM regeneration

Great! I hope this ends up being useful to people besides me. I trust
you'll update the documentation at
https://qubes-os.org/wiki/FedoraTemplateUpgrade#Compactingtemplatesroot.img when this is released. Or if it isn't done a few days after the release and I remember, I'll remind you. :)

> I hope I haven't missed any corner case...

The code looks reasonable to me, except I noticed the -v option to
fstrim is pointless since you don't read the output (perhaps you
realized that displaying it would be unsafe without filtering and
coloring it like qvm-run does). And the tool seems to work for me.

Matt

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Wow, thank you, Marek and Matt! I hope this will make
template-trimming more accessible to mere mortals (read: users) like
me. Will we be able to just run a command in dom0?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUusveAAoJEJh4Btx1RPV84ZMP/A27WMrCPvuzRymVfPz0QOWG
h/6QEGmRAguar0XmnMf2JBYU8KPeC/b8nWMQMgOED2XpiGgQkrypYp7/YioJxGEQ
lvCFNmTdOpkeKBnqKsO+yFn43qzM6+y5NWqXVfyXi9vFN55D/3ihcGPfHp5hmdth
JbZFVNRt+76SImjRwSvdQFTX64A6gHgsogQ/Atwv/h6Qmfo42Y5lwd6A2QRMjLKN
NRiJMmzOkC7OInNuAnXasJlygWg5IQF/kf/Vuua0lXVTeGxo4odg5gSYlW0OrgFd
Vg5SsSunot3+8iuGJyyFBXhUtgmIKRKiLqCqMIqoROpvwJpDa/nTKAk4oKB46dGE
Hmwv/e7wp4fLd5iRQIZgE3cNi2cAklaxNc60R85/EKTOJ2p044LU6Oo1Nar6vCIx
/OEy8R3bKUIF7rPmKPoTpebyySzfRi3kf9BPVWFdr0bv6lfpzJ/4ewhEom5rwX5e
84m9vbUOvFXeX//irhHvgXfo1jEDlWjkSEAjyVeE5XqARhTtPPoXHJWbfCB/mCJP
TIoUk6lrie3E1/9QRGaAkvlGlZE6SZjquEqfoQ7uecenYnJzHDC2OGaN/6TsBefK
XH2tPXx38UMLVkmPRbMcq3jvqK9Mee6IB5fR5nATug5cf2fwQK/Ro5szICiixwqP
MH6uxN7MWgHUhXDMRr8t
=TCjc
-----END PGP SIGNATURE-----

[7v5w7go9ub0o]

On 01/17/15 15:53, Axon wrote:

<snip>

> Wow, thank you, Marek and Matt! I hope this will make
> template-trimming more accessible to mere mortals (read: users) like
> me. Will we be able to just run a command in dom0?
>

Ditto what he said!

[Matt McCutchen]

On Sat, 2015-01-17 at 20:53 +0000, Axon wrote:
> Wow, thank you, Marek and Matt! I hope this will make
> template-trimming more accessible to mere mortals (read: users) like
> me. Will we be able to just run a command in dom0?

Yes:

qvm-trim-template <templatevm-name>

Matt