Btrfs: Difference between revisions

From Xen
Jump to navigationJump to search
 
(5 intermediate revisions by the same user not shown)
Line 4: Line 4:


== HOWTO ==
== HOWTO ==
''Posted by Austin S Hemmelgarn to the xen-users mailing list on Oct 28, 2015:''
''Originally from a post by Austin S Hemmelgarn to the xen-users mailing list on Oct 28, 2015:''


This makes use of BTRFS's send/receive feature to preform a
This makes use of BTRFS's send/receive feature to perform a
safe online clone of an existing user domain with relatively minimal
safe online clone of an existing user domain with relatively minimal
service degradation for that existing domain. It goes as far as
service degradation for that existing domain. It goes as far as
Line 20: Line 20:
These steps assume you have a decent working knowledge of BTRFS and
These steps assume you have a decent working knowledge of BTRFS and
Linux in general, as well as access to both Domain-0 and the user domain
Linux in general, as well as access to both Domain-0 and the user domain
you are copying (refereed to below as the 'source domain'. I've only
you are copying (referred to below as the 'source domain'. I've only
used this myself with Gentoo, but it should work for almost any Linux
used this myself with Gentoo, but it should work for almost any Linux
distro. I've also only done this with full PV domains, it's a lot more
distribution. I've also only done this with full PV domains, it's a lot more
involved to do it with HVM domains the hotplug stuff for block devices
involved to do it with HVM domains the hotplug stuff for block devices
in HVM domains can be tricky), although PVH domains should work with
in HVM domains can be tricky), although PVH domains should work with
Line 30: Line 30:


* Create your backend storage devices for the new domain.
* Create your backend storage devices for the new domain.
* Attach the storage device (or devices) that will hold the root filesystem for the new domain to the source domain. Using xl, this translates to something similar to: 'xl block-attach source "/dev/vg/target-disk,raw,xvdz"'
* Attach the storage device (or devices) that will hold the root filesystem for the new domain to the source domain. Using '''xl''', this translates to something similar to '''xl block-attach source "/dev/vg/target-disk,raw,xvdz"'''
* From the source domain, use mkfs.btrfs to create a BTRFS filesystem on the target disk.
* From the source domain, use '''mkfs.btrfs''' to create a BTRFS filesystem on the target disk.
* On the source domain, mount both the root filesystem (don't bind mount it, and make sure that you are mounting the top-level, not a subvolume) and the target filesystem.
* On the source domain, mount both the root filesystem (don't bind mount it, and make sure that you are mounting the top-level, not a subvolume) and the target filesystem.
* Create a read-only snapshot of the root subvolume from the source filesystem.
* Create a read-only snapshot of the root subvolume from the source filesystem.
* Use btrfs send piped to btrfs receive to copy the snapshot from the source filesystem to the target filesystem. This will likely take quite some time (on the low-end server equivalent hardware I have, it takes about 2o-25 minutes for a somewhat minimalistic Gentoo installation).
* Use '''btrfs send''' piped to '''btrfs receive''' to copy the snapshot from the source filesystem to the target filesystem. This will likely take quite some time (on the low-end server equivalent hardware I have, it takes about 20-25 minutes for a somewhat minimalistic Gentoo installation).
* While btrfs send/receive is running, prepare the configuration file for the target domain (I usually just copy the config from the source domain, and then change only what I need to).
* While btrfs send/receive is running, prepare the configuration file for the target domain (I usually just copy the config from the source domain, and then change only what I need to).
* Once the send/receive operation is complete, use btrfs property set to change the snapshot on the target to be writable, then rename it to whatever you want the root subvolume to be called on the target system.
* Once the send/receive operation is complete, use '''btrfs property set''' to change the snapshot on the target to be writable, then rename it to whatever you want the root subvolume to be called on the target system.
* In the newly created root subvolume, change any system specific configuration to what is needed for the new system (at a bare minimum, you probably need to change the hostname and networking configuration, and should verify that /etc/fstab and /etc/localtime are correct for the target system).
* In the newly created root subvolume, change any system specific configuration to what is needed for the new system (at a bare minimum, you probably need to change the hostname and networking configuration, and should verify that /etc/fstab and /etc/localtime are correct for the target system).
* Unmount the target filesystem in the source domain.
* Unmount the target filesystem in the source domain.
* Use 'xl block-detach' to detach the target device from the source domain.
* Use '''xl block-detach''' to detach the target device from the source domain.
* Use your regular tools to start your new domain, log in, and preform any final configuration needed.
* Use your regular tools to start your new domain, log in, and preform any final configuration needed.



Latest revision as of 00:54, 3 November 2015

From the BTRFS Wiki:

"Btrfs is a new copy on write (CoW) filesystem for Linux aimed at implementing advanced features while focusing on fault tolerance, repair and easy administration."

HOWTO

Originally from a post by Austin S Hemmelgarn to the xen-users mailing list on Oct 28, 2015:

This makes use of BTRFS's send/receive feature to perform a safe online clone of an existing user domain with relatively minimal service degradation for that existing domain. It goes as far as replicating block layout and inode numbers without needing to do a full block level copy of the domain's storage devices (which isn't safe with BTRFS anyway).

Using this methodology, I can have a new Gentoo PV domain running in about half an hour with all of my custom local configuration, whereas it takes me at least two and a half hours (and often much longer than that) when using the regular install process for Gentoo.

These steps assume you have a decent working knowledge of BTRFS and Linux in general, as well as access to both Domain-0 and the user domain you are copying (referred to below as the 'source domain'. I've only used this myself with Gentoo, but it should work for almost any Linux distribution. I've also only done this with full PV domains, it's a lot more involved to do it with HVM domains the hotplug stuff for block devices in HVM domains can be tricky), although PVH domains should work with exactly the same steps as regular PV domains. Your source domain's root also needs to be in a subvolume on the root filesystem (and needs of course to be on a BTRFS filesystem), this won't work if it isn't.

  • Create your backend storage devices for the new domain.
  • Attach the storage device (or devices) that will hold the root filesystem for the new domain to the source domain. Using xl, this translates to something similar to xl block-attach source "/dev/vg/target-disk,raw,xvdz"
  • From the source domain, use mkfs.btrfs to create a BTRFS filesystem on the target disk.
  • On the source domain, mount both the root filesystem (don't bind mount it, and make sure that you are mounting the top-level, not a subvolume) and the target filesystem.
  • Create a read-only snapshot of the root subvolume from the source filesystem.
  • Use btrfs send piped to btrfs receive to copy the snapshot from the source filesystem to the target filesystem. This will likely take quite some time (on the low-end server equivalent hardware I have, it takes about 20-25 minutes for a somewhat minimalistic Gentoo installation).
  • While btrfs send/receive is running, prepare the configuration file for the target domain (I usually just copy the config from the source domain, and then change only what I need to).
  • Once the send/receive operation is complete, use btrfs property set to change the snapshot on the target to be writable, then rename it to whatever you want the root subvolume to be called on the target system.
  • In the newly created root subvolume, change any system specific configuration to what is needed for the new system (at a bare minimum, you probably need to change the hostname and networking configuration, and should verify that /etc/fstab and /etc/localtime are correct for the target system).
  • Unmount the target filesystem in the source domain.
  • Use xl block-detach to detach the target device from the source domain.
  • Use your regular tools to start your new domain, log in, and preform any final configuration needed.