Cloning XenServer on USB or SD
-
@Danp said in Cloning XenServer on USB or SD:
Just guessing, but
if= input file andof= output fileYup, that's what they mean.
-
How does dd (and CloneZilla too, I presume) work if the drive you are cloning to is larger.
Say I have a 32GB and clone to a 64GB. Can you do that? Does it just leave empty space on the larger drive?
I was wondering if you could clone to a larger drive, that I could clone my 32GB boot USB to a 64GB USB, THEN run the upgrade so it will use the larger partition sizes.
-
@BRRABill said in Cloning XenServer on USB or SD:
How does dd (and CloneZilla too, I presume) work if the drive you are cloning to is larger.
Say I have a 32GB and clone to a 64GB. Can you do that? Does it just leave empty space on the larger drive?
It's a straight copy, block by block. It doesn't care what size the drive is. It just writes to it identically. It ignores that the device might be larger. It will clone to smaller too and just fails when it fills up too quickly.
-
@scottalanmiller said
It's a straight copy, block by block. It doesn't care what size the drive is. It just writes to it identically. It ignores that the device might be larger. It will clone to smaller too and just fails when it fills up too quickly.
So what I want to do should theoretically work?
-
@BRRABill said in Cloning XenServer on USB or SD:
@scottalanmiller said
It's a straight copy, block by block. It doesn't care what size the drive is. It just writes to it identically. It ignores that the device might be larger. It will clone to smaller too and just fails when it fills up too quickly.
So what I want to do should theoretically work?
You'd be able to write to a larger device, but trying to change the partitions by hand seems like a bad idea.
-
@DustinB3403 said
You'd be able to write to a larger device, but trying to change the partitions by hand seems like a bad idea.
I wouldn't do it by hand. I am ASSUMING (lol) that the XS upgrade would do that for me, as I think it says it does.
-
Clonezilla has and expert option that allows you to set additional settings to grow the partitions proportionally to fill the larger disk.
You can also restore to a smaller disk, as long as your data portion is smaller than the actual amount of space on the new drive, but it's much more difficult to get to work.
-
@Dashrender said
You can also restore to a smaller disk, as long as your data portion is smaller than the actual amount of space on the new drive, but it's much more difficult to get to work.
And requires a degree in wizardry! LOL.
-
@BRRABill said in Cloning XenServer on USB or SD:
@Dashrender said
You can also restore to a smaller disk, as long as your data portion is smaller than the actual amount of space on the new drive, but it's much more difficult to get to work.
And requires a degree in wizardry! LOL.
Where's my Wizard Hat?
-
@scottalanmiller said
It's a straight copy, block by block. It doesn't care what size the drive is. It just writes to it identically. It ignores that the device might be larger. It will clone to smaller too and just fails when it fills up too quickly.
So I did this today, but ran into a problem.
The 64GB USB stick is reporting as a 32GB stick, just like the original 32GB.
Like there isn't even 30GB of unused partitions, it thinks the 64GB stick is only 32GB.
I also tried the program @DustinB3403 mentioned in his writeup, but that program even warns this is going to be a problem.
"Warning: Due to the forensic nature of image duplication by ImageUSB, please ensure that you select UFDs with a storage size similar to the image you wish to duplicate. For example, if a 2GB image is copied to an 8GB USB Flash Drive, the drive will only be able to use two out of the eight gigabytes of storage space. In this scenario, users will need to reformat the UFD in order to access the rest of the storage space."So is there really any way to do what I am trying to do?
-
This will allow you to extend partitions.
-
You would still be able to make changes to the FS on the USB once its completed, but as I said, changing a live partition isn't a trivial task.
With XenServer the installation creates two partitions, of which you should be able to easily adjust the size of the non-active partition. But the boot partition, that is a whole other issue.
It's possible, but likely not worth the effort.
-
@DustinB3403 said
You would still be able to make changes to the FS on the USB once its completed, but as I said, changing a live partition isn't a trivial task.
With XenServer the installation creates two partitions, of which you should be able to easily adjust the size of the non-active partition. But the boot partition, that is a whole other issue.
It's possible, but likely not worth the effort.
So really the only way to go from the "old" partitioning scheme of 6.5 on my 32GB drive to the "new" scheme on a 64GB drive would be to move off all the VMs, and reinstall XS7 from scratch, then move them back. Is that what I am picking up here?
-
You could do an inline upgrade, but the upgrade doesn't even change the partition sizes. Because it's far easier to break the system trying to resize partitions than it is to just reinstall.
So yes, a clean install is recommended.
-
@DustinB3403 said
So yes, a clean install is recommended.
Hear ya loud and clear.
Hopefully XS will allow me to transfer both directions for migrations, then none of this will be an issue.
Or, I'll maybe just buy a refurb server from xByte for this purpose.
-
This is the command I usually use to clone one drive to another identical drive.
dd if=/dev/sdX of=/dev/sdY bs=512 conv=noerror,syncIt uses the default block size to make a direct copy and keeps any errors from interrupting the process.
I've had problems come from changing to a larger blocksize before, so I usually just stick with the default of 512. If you are going to be moving between disks/partitions of different sizes you'll just need to start with a smaller image and make sure you resize your partitions and fix the filesystems after cloning. If you have a standard image you are working from you can test this out and find the largest block size that is stable and works for your specific task.
I wrote a small program in BASH that did a quick disk test/verification and automated the process of writing a standard image onto sd-cards of varying sizes (2GB up to 32GB) using dd and fdisk. It ended up replacing some old piece of software that ran on Windows and could not properly detect the newer larger capacity sd cards that our client wanted to start using.
-
Strangely enough ImageUSB did it properly.
But I'm not sure it's worth the risk of trying what I want to do.
I'll get everything upgraded to XS7 and then start clean installing.
-
@scottalanmiller said
Assuming the devices refer to the two USB devices:
dd if=dev/sda1 of=/dev/sdb1If you are doing the entire disk (such as with XS which creates multiple partitions) why wouldn't it be...
dd if=/dev/sda of=/dev/sdb -
@BRRABill said in Cloning XenServer on USB or SD:
@scottalanmiller said
Assuming the devices refer to the two USB devices:
dd if=dev/sda1 of=/dev/sdb1If you are doing the entire disk (such as with XS which creates multiple partitions) why wouldn't it be...
dd if=/dev/sda of=/dev/sdbYou have to copy what there is to where you want it. If the filesystem is on /dev/sda1 you don't want /dev/sda or you are copying the partitioning layer with it.
-
@scottalanmiller said
You have to copy what there is to where you want it. If the filesystem is on /dev/sda1 you don't want /dev/sda or you are copying the partitioning layer with it.
But if I want to make an exact clone of the USB for DR purposes, I'd want the partitioning layer, no?
