[ale] Xen Server adding a virtual disk to a VM

[Phil Turmel]

On 10/14/2016 05:13 PM, DJ-Pfulio wrote:
> Ok, so fdisk was patched, but I'm still waiting for that patch to
> actually make it into every distro I see. I keep seeing fdisk complain
> about GPT disks - easier to just use parted, IMHO. Parted also aligns
> partitions correctly, as does gparted.  fdisk does not. If you use only
> SSDs, don't think that it matters, but on spinning disks, there can be a
> real, noticeable, performance hit.

Interesting.  I've been using 'gdisk' for quite some time now.  Same
style of interface but supports GPT, plus conversions to/from MBR and
BSD.  I thought is was packaged with util-linux, but I just found out
otherwise.

It is part of the base install of Ubuntu Server at least since 14.04.
It came in as a default dependency of udisks on my gentoo systems, which
is pulled in by a variety of things.  So I assumed it was part of the
system set.

I like gdisk *way* more than parted.

> GPT has many upgrades over MBR, like duplication at the front/end of the
> storage, not only at the beginning. Plus not having to deal with
> "logical/extended" partitions ever again is nice. Wikipdeia has more.
> 
> Inside a VM, I don't don't use LVM.  Only outside on the hostOS. There
> are multiple pros/cons to either method. I can understand if folks want
> LVM inside a VM and why they wouldn't. Do some research.

I do the same.  LVM on bare metal, not in VMs.  All of my VM disks are
LVs, not files.  Virt-manager makes that easy, btw -- you can make any
volume group in a host a "pool" for VM allocations.  It was one of the
final straws that got me off of virtualbox.

> Haven't touched btrfs. Seems there is always some "issue" that is
> important to me with it. Whether that is true or not is completely
> irrelevant. It is a hassle that I don't need. Understand many people
> love btrfs, which is great. More users will eventually fix the issues I
> have! Thanks!

Yup.  I played with it once.  Haven't touched it since.

> lsblk is nice. Plus, it doesn't need sudo to work (at least not on any
> systems I manage).

I wrote lsdrv[1] because I didn't like the way lsblk repeated trees when
raid arrays were present, and I wanted something that would document
controller ports, device SNs, and UUIDs for later recovery tasks.
Basically lsblk + blkid + lspci + lsusb in one report.

Phil

[1] https://github.com/pturmel/lsblk