> > > If, as I suspect, the root cause of your problem is a lack of metadata
> > > space on pool00; you can confirm this by typing "sudo lvs" into a
> > > console. You will then need to figure out a way to enlarge that metadata
> > > volume.
> >
> > Yes, you are right, the `pool00` volume metadata was >96% when this
> > happened. The thing is that the volume metadata was set to a quite small
> > size after install (96mb on a 46gb pool) and after install was on ~20%
> > usage. I started to use the system, testing stuff with DispVMs, restoring
> > my debian templates and some work VMs. After a couple of days of usage the
> > metadata climbed very little, to 27-28%.
> >
> > I tried to have a second pool to hold my machines, precisely to avoid
> > issues with thin provisioning on the pool holding `root` and `swap` and
> > services vms. But the lack of support for cloning/moving between pools made
> > that effort moot.
> >
> > So I `lvextend`ed `pool00` and forgot to properly enlarge it's
> > `pool00_tmeta` counterpart.
>
> What sizes you have there?
> For me tmeta is 118MB for a ~450GB pool00. And after few months of usage
> it's still at 33%...
An install on a 60G disk partition had a pool00 of 43G created with a
pool00_tmeta of 44M (11 extents). Later, the pool00 was extended to 147.7G and
the pool00_tmeta left as is by mistake.
The metadata became full, and after that the pool00_tmeta was extended to 300M
by adding 256M.
> > When doing some more customization, including restoring more larger sized
> > qubes and cloning/renaming qubes it seems the metadata usage climbed really
> > fast and hit this bug.
> >
> > Unfortunately, could not recover from that.
> >
> > It looks like qubes lvm actions while metadata was full may have corrupted
> > the metadata somehow, since I could enlarge and repair the thin metadata
> > from a live cd, but many of the volumes that where in use where never
> > available again. The -private and -snap for the qubes that were running
> > (not sure how to discard them) and also all the volumes of the qubes being
> > restored and services vms are lost ("NOT available" as lvm status)
>
> You could also try to revert to earlier revision using "qvm-volume
> revert sys-net:private" for example.
Will try that tonight.
> > I remember there was some Saltstack magic to recreate the services vms, but
> > could not find anything for R4.0... So I had to revert to R3.2 for the time
> > being.
>
> https://www.qubes-os.org/doc/salt/
> Especially links at the bottom:
> https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/README.rst
Thanks. Will also try that tonight.
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/cd525562-ead8-4559-9326-c31787b438dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
