Hardware migration questions

[egarcia]

Hello,

I'm running a system with 2 datasets, one for backups and one for VMs. The one for VMs runs as "3xDISK 1 wide, 1.82Tib" (i.e. no RAID).

I've bought 2 bigger disks (16Tib) to increase capacity on this dataset, and I have some questions:

1. Will there be a problem to run 2 disks at 16Tib and 1 at 1.82Tib?
2. Could I migrate the VMs to my other dataset somehow temporarily to avoid recreating everything from scratch? They were done as no-RAID consciously, so I'm prepared to do so if necessary, but obviously will prefer if there is a way to avoid the work, specially them being VMs they should really be portable :).

Thanks in advance.

 

[Arwen]

Some answers:

1. No
2. Yes

But it would be simpler if you had a free SATA port and simply replaced an existing 1.82Tib with a 16Tib. Then physically remove the old disk, to install a new disk and repeat the process.

ZFS includes the ability to replace in place. Meaning ZFS makes a temporary Mirror of the old and new disks. Then, when the Mirror resync is complete, the old disk is removed from the pool. Works on Striped pools like yours, as well as RAID-Zx vDevs.

 

[egarcia]

Thanks for your answers.

I sadly don't have a SATA port available, although I could remove one of the backups disks temporarily to use it. However, I assume ZFS will try to fix the RAID on the backup dataset if I try to use that port.

Because I probably cannot do that, how can I move the VMs to the other dataset? I've tried looking for some "move" command somewhere, but I'm failing at it.

 

[Arwen]

The steps are like this;

1. Shutdown your VMs
2. Recursively snapshot the affected dataset
3. ZFS Send from the recursive snapshot to the temporary location
4. Destroy your VM pool
5. Remove 2 of the smaller disks
6. Install the 2 new larger disks
7. Create a new pool with 1 smaller disk and 2 larger disks
8. Perform a ZFS send from the temporary location to the new pool
9. Bring up your VMs
10. And if VMs are good, proceed with cleanup:
    1. Destroy the snapshots on both sides, temporary and new pool, used for the migration
    2. Destroy the temporary location's datasets

Please note that when you say "the other dataset", I am assuming "the other dataset, on a different pool".

I can't give you exact steps because it is specific to your dataset names, pool names and such. Plus, this migration has the chance of data loss, (very low, if you understand ZFS well), so I hope you have a backup.

Further, if the disks are not hot swap, then you need to shutdown before step 5 and power up after step 6.

 

[egarcia]

Thank you very much for the detailed steps, this is great.

Please note that when you say "the other dataset", I am assuming "the other dataset, on a different pool".

Yeah, I have 2 pools, I forgot Dataset & Pool were not the same thing (and when editing a dataset I see no mention of the parent pool, at least not with the word "pool" anywhere, and because they're named in the same way, it gets confusing ).

I can't give you exact steps because it is specific to your dataset names, pool names and such. Plus, this migration has the chance of data loss, (very low, if you understand ZFS well), so I hope you have a backup.

The instructions are pretty clear, thank you. And no, as you can see from the above I'm far from understanding ZFS well .

I just have one additional question. When creating the VM snapshots & doing a "ZFS Send" (I'm assuming there is a UI action with this somewhere), how will the VM know that its data has moved? Is this part of the "ZFS send"? I'm just assuming the VM config is separate from the volume itself, but I might be wrong.

Thanks again for all your help, I feel much more confident about this now than before, I was expecting this to take days, but it can probably take a few hours instead.

 

[Arwen]

Thank you very much for the detailed steps, this is great.

Yeah, I have 2 pools, I forgot Dataset & Pool were not the same thing (and when editing a dataset I see no mention of the parent pool, at least not with the word "pool" anywhere, and because they're named in the same way, it gets confusing ).
...

Yes, it is somewhat confusing about pool and dataset naming. Basically the pool would the first "word" of a ZFS path;
my_pool/my_dataset/my_child_dataset
Of course, I don't know if all the GUI references do this properly. Or if they have the pool name in the header a sub-window, and dataset below that.

...
I just have one additional question. When creating the VM snapshots & doing a "ZFS Send" (I'm assuming there is a UI action with this somewhere), how will the VM know that its data has moved? Is this part of the "ZFS send"? I'm just assuming the VM config is separate from the volume itself, but I might be wrong.

Thanks again for all your help, I feel much more confident about this now than before, I was expecting this to take days, but it can probably take a few hours instead.

I learned ZFS Snapshots, Send & Receive via command line, so I can't point you to the GUI actions.

The goal is to put back the VM storage to exactly where it was before, path wise. So no changes to the VM configuration. At least until you add new VM storage, or grow existing VM storage.

The one comment is understand how things work, before you do them.

 

[egarcia]

I learned ZFS Snapshots, Send & Receive via command line, so I can't point you to the GUI actions.

Ah, I'll use the command line then, no problem.

The goal is to put back the VM storage to exactly where it was before, path wise. So no changes to the VM configuration. At least until you add new VM storage, or grow existing VM storage.

Oh, so this will "pull the rug under" the VM, so to speak, so it won't work on that temporary state. That's what I was expecting, I couldn't figure out how the magic worked otherwise, but this makes sense now, thanks.

Wish me luck :).