On Sunday, May 04, 2014 09:03:08 PM Stefan G. Weichinger wrote: > Am 04.05.2014 20:40, schrieb J. Roeleveld: > > On Sunday, May 04, 2014 03:07:28 PM Stefan G. Weichinger wrote: > >> Oh, yes, I like ZFS and its features and used it in some cases already. > >> But I didn't yet take the step to set up ZFS-root on my work machines. > > > > I haven't yet, but it's on the list of items to look into at some point. > > I'd like to know if, with ZFS, it is possible to create block-devices like > > LVs which I can then attach to VMs. Or if I have to use files instead. > I think you would have to use files on top of ZFS ... but I am not > up-to-date in that area. > > People run KVM-hosts with storage on ZFS ... nice with the snapshots etc ...
Does KVM support running snapshots? Eg. also storing the memory and registers? I have not found any indication that KVM supports that. Without that, KVM is useless to me. > > That's a hardware raid device with 4 * 3TB disks with raid-6. > > I don't like the fact that a 2nd disk-failure can kill a raid-10 when both > > disks are in the same mirror-set. > > > > gdisk automatically aligns on 2048 sector boundaries, that is more then > > enough for the 4k-sectors and the block/stripe sizes employed by the > > raid-controller. > Yes, this is for UEFI booting, thanks. > > I tried to migrate to GPT/BIOS-booting today but failed. It seems my > mainboard/BIOS has problems detecting that ... I vaguely remember this > from trying it back then. I thought the MBR info that's possible with GPT would make it possible with any BIOS? Provided the /boot partition is early enough on the disk. > So I am back on a freshly partitioned and formatted SSD with plain old > MBR now. > > I also wanted to partition the SSD according to the Erase Block Size of > 6144 kB by this way ... dunno if this is still needed or has any real > speed benefits. Again, I would expect current tools should do that automagically? > Maybe I take another approach to migrate to UEFI/GPT in the next days, > now that I have my rsynced filesystems at hand (I got rid of more LVs > and stuff so it gets pretty slim now). Less LVs is simpler. More is more flexible. > > UUIDs, I believe, do work natively. And those are stored inside the > > partition itself. Which means they should also work. But are not as easy > > to locate. (eg. you don't specify them yourself) > > Yep. LABELs are human readable ... big advantage. I would like LABELs to be supported directly by the kernel. > > See the partitioning on my server above. > > It boots using BIOS as I haven't been able to boot Xen using UEFI yet. > > So then the EFI partition is useless ... True, but I leave it there as repartitioning requires extended downtime. And I do occasionally test new versions to see if I can get it to work. > > Support should be there now, but not been able to test that yet. > > GPT is supported by grub-1 (and grub2) and with the MBR-support inside > > GPT, > > booting works from BIOS/MBR. > > ... if your BIOS isn't crappy ;-) Try updating? :) Seriously, do you have the following: *** # man gdisk artemis ~ # gdisk -l /dev/sda GPT fdisk (gdisk) version 0.8.8 Partition table scan: MBR: protective *** That last line of what I copied is the bit that should make it possible. Also, the /boot partition needs to have the mbr-boot flag (or whatever it's called) enabled. -- Joost
