-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Oct 14, 2017 at 04:29:30PM +0100, Andrew Clausen wrote: > Hi Marek, > > On 14 October 2017 at 15:45, Marek Marczykowski-Górecki < > marma...@invisiblethingslab.com> wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > On Sat, Oct 14, 2017 at 04:01:11PM +0200, Wojtek Porczyk wrote: > > > On Sat, Oct 14, 2017 at 03:36:05PM +0200, Marek Marczykowski-Górecki > > wrote: > > > > Thanks for the explanation. > > > > This should be enough for the online resize part. Now, back to the main > > > > issue here: partition to resize isn't the last one, one need to move > > two > > > > other partitions first. Hmm, maybe parted can do that too? > > > > It used to be able to. However, when I retired from maintaining Parted, > the new maintainers removed support for resizing file systems. (It's > fairly complicated code, and much less socially important now than when I > wrote it in the late 90s.) After some protest, they added it back into > libparted, but it's still not available in the parted command-line tool. > There is another tool, fatresize, but this isn't very helpful because it > doesn't allow you to move the start of the partition. I believe other > front-ends such as Parted Magic and GParted maintain the full > functionality, but probably not in a scriptable fashion.
It's not about resizing those other partitions, it's about moving them. For resizing main filesystem resize2fs is enough. > I could write a small tool especially for Qubes, if you think this is the > best solution. But see below... > > > Can't we change the partition order and add some compatibility to initrd? > > We > > > could support resizing only for "new" templates and leave the > > instruction to > > > resize older ones in documentation, with a big scary warning that it's > > better > > > to reinstall template than attempt manual resizing. > > > > This is exactly what this thread is about. The question is what would be > > more stable/less fragile - supporting two partition layouts, or resizing > > of the current layout. This question is especially tricky, because there > > are multiple ways how initrd is distributed: > > - kernel provided by dom0 (so, dom0 package) > > - kernel privided by VM (so, VM package) > > > > Those packages may be updated independently, and in case of kernel from > > dom0, may exists in multiple versions simultaneously. This may lead to > > "funny" effect that some templates will work only with some kernel > > versions. This may, or may not be a problem. > > > > I'm surprised there isn't a generic initrd standard to avoid this problem. > How disappointing! For example, initrd could identify the system partition > by its name, not its location. There are few issues with using filesystem label there. The primary one is: it is ambiguous, because there are two things in AppVM: - read-only base image, from VM template - read-write copy-on-write image, assembled from the one above Granted, that before assembling the second one (which is done by initrd), there is only one. I haven't investigated _partition_ names available in GPT (as opposed to filesystem labels). Maybe that would be the way to go? > Some other options: > > (1) Delete the old system partition, and create a new one by copying the > files across. This should be fairly quick, because the system partition > shouldn't have much stuff on it, right? (I doubt it would be slower than > libparted's resizer.) Up to 10GB, in default setup. resize2fs is sufficiently fast, no need to copy files. But to do that, you need to resize the partition. And to resize it, you need to move other two partitions further to the disk end (in the current partition layout). Let me remind that current layout: 1. xvda1: root filesystem (almost all available space) 2. xvda2: EFI system partition (empty, prepared for PVHv2 boot with VM-provided kernel) 3. xvda3: BIOS boot (grub2 installed, used when `kernel=''`) You don't need to move xvda1. Only xvda2 and xvda3, which are small (about 200M total). Changing it to have root filesystem at the end would ease resizing, but may introduce compatibility issues explained before. > (2) Make the virtual hard disk very large (e.g. 100TB) but store it in a > sparse format. Put the system partition at the very end, so you never have > to move it around. Well, in dom0 it is stored as such (or on LVM thin volume - depending on configuration). But the volume size is limited on purpose - otherwise _any_ VM could easily fill the whole disk. > (3) Use LVM. > > I find option (2) most elegant. The main difficulty would be: how do you > enforce space limits? I worry that an AppVM would have a copy-on-write > view of the massive template image, and would be able to fill in the sparse > holes to do a denial-of-service attack on the whole system. Exactly. This is the reason why it is limited. Unfortunately most (all?) copy-on-write schemes and sparse volumes (either files, or LVM) react badly when you run out of disk space. If you're very unlucky, even fsck will not help you to cleanup all that mess (after providing more space...). On the other hand, if you have filesystem size same as volume size limit, you get "No space left on device" error, instead of various I/O errors and filesystem corruption. Bonus: you don't break free space reporting. This is does not exclude storing such VM disk image as sparse thing in dom0, so you use even less disk (than that 10GB). > Option (1) is probably quite easy to implement and most robust. > > Cheers, > Andrew - -- 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 iQEcBAEBCAAGBQJZ4KTPAAoJENuP0xzK19csncwH/jbqDqQFN/htk25gPKIg7N9d x6LOgTIdGoUuyXOdnw6nxKYEBxmQgl0pCnUEldP3dlI2FpXX8ZnRPydoV0k9tM3+ JzDwscNwnr6FZwvgZzlDm8/8dx7LTzAsISkLatXnJ2C48mZMi7ff7mQ7GvGkDa2Y QeMPi5ZfywVZx50ziSBcAMKYjQJ2KJhiFcEvk675j48k2xkC/xXUn4Md6yBMABo2 9uvIvaZhzhs19IPIrQzdtqyiUspTGoPcqbkGaY4QTtFu23+DrRAMuHlJUvHR0q2I j/0bHM79Ht32iROEULmJZhvzkiMmzaHzrd7aLFGU9FW9eNDg/Q8D6REkN3hDDzU= =YqZb -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20171014160656.GW1059%40mail-itl. For more options, visit https://groups.google.com/d/optout.
