• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Expanding local ESXi Datastore?

Zarathustra[H]

Zarathustra[H]

Extremely [H]
2FA
Joined
Oct 29, 2000
Messages
42,289
Hey all,

Unlike most of you who run all in one systems, my ESXi server boots off of an SSD which also serves as its datastore for guest drive files.

The 128GB Samsung 840 Pro has served admirably in this role for 2 years now, but it is starting to run out of space as I want to add my 13th and 14th guests.

I have ordered a 512GB Samsung 850 Pro to replace it, but it is not entirely clear to me how I'd go about growing the storage.


Would the following process work?

1.) Put host in maintenance mode, and shut down.
2.) Connect new drive
3.) Boot from Ubuntu USB stick.
4.) Use Gparted to duplicate the crazy ESXi partition layout to the beginning of the new drive.
5.) Shut down and disconnect old drive
6.) Boot server back up from new drive
7.) Use the config -> storage menu to grow my datastore to fill the new drive?

If not, any suggestions on how best to accomplish this?

Much obliged,
Matt
 
I can't speak to what the best practices etc. are, but if it was me, I'd hook up new drive, let ESXi format it and then move VMs over with both connected. I have done things along this line before.
 
Can you leave both drives in? Just add the new drive, set it up as another datastore, then you can add new VM's there or copy them to there from the old one. Leave the old one as boot. That way you don't need to worry about cloning and changing the partitions and stuff. I would highly suggest not trying to do that.
 
danswartz said:
Not to be a douche, but he *did* say that in his OP...
Click to expand...

He did. I read it too fast and missed that bit.

extide said:
Can you leave both drives in? Just add the new drive, set it up as another datastore, then you can add new VM's there or copy them to there from the old one. Leave the old one as boot. That way you don't need to worry about cloning and changing the partitions and stuff. I would highly suggest not trying to do that.
Click to expand...

Also this idea sounds good.
 
Last edited:
If I were on 5.5u2, I'd keep both SSDs & install 6u1 on the new drive. This should make testing & conversion a lot easier IMO.
 
I'd suggest: shutdown. pull the old drive. plug in the new one. install ESXi. plug in new drive, and copy the VMs from the old datastore to the new one. pull old one. doesn't take that long to install ESXi...
 
danswartz said:
I'd suggest: shutdown. pull the old drive. plug in the new one. install ESXi. plug in new drive, and copy the VMs from the old datastore to the new one. pull old one. doesn't take that long to install ESXi...
Click to expand...

Yeah if you must move entirely to the new drive, this is the best way. Don't go messing with the partitions and stuff.
 
I'm going to try to copy it over, but without erasing the old drive.

If it doesn't work, I'll still have the original install on the first drive.
 
Zarathustra[H];1042091400 said:
I'm going to try to copy it over, but without erasing the old drive.

If it doesn't work, I'll still have the original install on the first drive.
Click to expand...

Why? That's seriously the worst option.
 
extide said:
Why? That's seriously the worst option.
Click to expand...

Not really. Remove old drive, install ESXi on new drive, set boot order to new drive and plug old drive back in. Clone VM's to new datastore. Power down and remove old drive. Verify functionality with only new drive.

Presto. ESXi and VM's on new drive and old one is available as a backup.
 
REDYOUCH said:
Not really. Remove old drive, install ESXi on new drive, set boot order to new drive and plug old drive back in. Clone VM's to new datastore. Power down and remove old drive. Verify functionality with only new drive.

Presto. ESXi and VM's on new drive and old one is available as a backup.
Click to expand...

Ok if you're doing that then ok, I thought he meant that he was going to clone the drive and adjust the partitions.
 
REDYOUCH said:
Not really. Remove old drive, install ESXi on new drive, set boot order to new drive and plug old drive back in. Clone VM's to new datastore. Power down and remove old drive. Verify functionality with only new drive.

Presto. ESXi and VM's on new drive and old one is available as a backup.
Click to expand...

Actually not what I was planning on doing.

The reason is, I have a lot of interdependent custom configurations, passthroughs, etc. configured in ESXi which I would very strongly prefer to not have to reconfigure.

I do need to replace the small drive with the large drive too, so keeping the small one in there is not an option.

I'm thinking that typical partition copying tools are not a good match for this job, as they only copy the partition, and not VMWares custom boot sector stuff, so I'll need something that bit-for-bit clones the drive.

I'm thinking I can probably do this by booting from a Ubuntu USB stick, and doing a DD of the old drive in its entirety to the new drive. This should capture everything, including the boot sector.

I'm just not sure how ESXi will react to the change, since it uses the drive descriptor as part of its device name, rather than a more universal approach like BSD or Linux, with it's /dev/dax or /dev/sdx type naming conventions.

The good thing here - however - is that if I try it, and it doesn't work, I can just plug the old drive back in again and try another method.


Just going to have to temporarily unplug my drives from my SAS controllers. I don't want to accidentally get the device names wrong and overwrite one of the drives in my ZFS pool :p


extide said:
Why? That's seriously the worst option.
Click to expand...

Why do you think it is so bad?

I'll try it, and if it doesn't work, I'll still have the original drive to try another method.
 
On a side note.

I'm still on ESXi 6.0.0, I know there have been two updates (Update 1, and update 1a) since then.

Maybe I'll do the updates at the same time. If I dd the old drive to the new, and it still won't boot properly, it's possible doing the update on top of it will make it boot, while still retaining my rather complicated host configuration.
 
Why? Because you are going to run into a lot of issues, and from a best practices standpoint it is definitely not a best practice to do thing that way. Maybe you can hack it together to work, and for a home setup, that may be fine.
 
extide said:
Why? Because you are going to run into a lot of issues, and from a best practices standpoint it is definitely not a best practice to do thing that way. Maybe you can hack it together to work, and for a home setup, that may be fine.
Click to expand...

Yeah, it didn't wind up working.

ESXi booted just fine, but when booted it didn't find any of the guests, because it had lost the datastore.

Instead of being on:
Code: 
/dev/t10.ATA_____Samsung_SSD_840_PRO_Series______________
it was now on:
Code: 
/dev/t10.ATA_____Samsung_SSD_850_PRO_512GB_______________

Really kind of stupid when if it had been /dev/sda like linux or /dev/da0 like BSD, it would have stayed in the same place and presumably everything would have worked.

Since I REALLY don't want to have to reconfigure the host, I installed the new SSD as an extra drive. Stinks, because I don't have any good mounting slots for another SSD, so I had to ghetto double-sided-tape it in :(
 
Zarathustra[H];1042097016 said:
Yeah, it didn't wind up working.

ESXi booted just fine, but when booted it didn't find any of the guests, because it had lost the datastore.

Instead of being on:
Code: 
/dev/t10.ATA_____Samsung_SSD_840_PRO_Series______________
it was now on:
Code: 
/dev/t10.ATA_____Samsung_SSD_850_PRO_512GB_______________

Really kind of stupid when if it had been /dev/sda like linux or /dev/da0 like BSD, it would have stayed in the same place and presumably everything would have worked.

Since I REALLY don't want to have to reconfigure the host, I installed the new SSD as an extra drive. Stinks, because I don't have any good mounting slots for another SSD, so I had to ghetto double-sided-tape it in :(
Click to expand...

That sucks. When you are ready to update to latest ESXi maybe install to USB key (makes it easy to have a clone up on hand) and keep VMs separate in future.

Also here are some posts about ESXi config backup/restore so you don't need to re-do all your passthroughs.

http://www.vladan.fr/free-esxi-configuration-backup-tool/
http://www.vladan.fr/backup-restore-esxi-configuration-powercli/

Haven't tried these personally myself ( I keep a clone of my ESXi boot USBs) but looks simple enough.
 
Zarathustra[H];1042097016 said:
Yeah, it didn't wind up working.

ESXi booted just fine, but when booted it didn't find any of the guests, because it had lost the datastore.

Instead of being on:
Code: 
/dev/t10.ATA_____Samsung_SSD_840_PRO_Series______________
it was now on:
Code: 
/dev/t10.ATA_____Samsung_SSD_850_PRO_512GB_______________

Really kind of stupid when if it had been /dev/sda like linux or /dev/da0 like BSD, it would have stayed in the same place and presumably everything would have worked.

Since I REALLY don't want to have to reconfigure the host, I installed the new SSD as an extra drive. Stinks, because I don't have any good mounting slots for another SSD, so I had to ghetto double-sided-tape it in :(
Click to expand...

It's odd that it "lost" the datastore, as a foreign VMFS filesystem can be mounted successfully to a host as long as there isn't a disk signature collision.

Another reason to keep boot disk and VM storage separate on ESX platforms. A 8 GB USB drive would do the trick!
 
First off, boot ESXi off a USB stick. It makes everything you are wanting to do so much simpler. Its VMware best practice anyway. I'd bite the bullet and do this now so you don't have to mess with it in the future. It's not like there is a lot to configure anyway. Some networking, datastore, and time configuration and ESXi is pretty happy

VCenter? If so then add new disk, create new datastore, and just migrate the VMs from the old to new datastore.

No Vcenter? Are you backing up VMs? You could simply install the new disk, create a new datastore, and then restore your VMs to this new datastore.

Or, install the new disk along side the old disk, create the new datastore, remove the VMs from inventory, and use the datastore browser to manually copy each full VM directory from the old datastore to the new one. You will then just add the the VMs back into your inventory on the new drive/datastore.
 
Zarathustra[H];1042097016 said:
Yeah, it didn't wind up working.

ESXi booted just fine, but when booted it didn't find any of the guests, because it had lost the datastore.

Instead of being on:
Code: 
/dev/t10.ATA_____Samsung_SSD_840_PRO_Series______________
it was now on:
Code: 
/dev/t10.ATA_____Samsung_SSD_850_PRO_512GB_______________

Really kind of stupid when if it had been /dev/sda like linux or /dev/da0 like BSD, it would have stayed in the same place and presumably everything would have worked.

Since I REALLY don't want to have to reconfigure the host, I installed the new SSD as an extra drive. Stinks, because I don't have any good mounting slots for another SSD, so I had to ghetto double-sided-tape it in :(
Click to expand...

So, I revisited this yesterday, and I was able to get it to work, and here's how I did it.

I shut down the server, removed the old drive from it, and put it in a linux test box. I imaged the drive using dd, and restored this image to the new larger 512GB drive.

After this, I put it back in the ESXi box and booted it up. Just like last time, all the guest names on the left were replaced by questionmarks.

I noticed this was because the datastore partition wasn't mounted.

So, I went to ->configuration->storage->add storage, and clicked on the samsung drive, and ESXi offered to import it using the existing ID (GUID). I did this, and it instantly found all my guests again and everything worked.

Then I went to datastore properties and tried to expand it into the empty space, and the button was greyed out. Confused I did some googling and found this KB.

It turns out when you adopt the existing GUID (or as VMWare calls it "signature") it is considered "force mounted". When force mounted you can not grow the datastore. So, I unmounted it again, and remounted it with the "assign new signature" option, where it creates a new GUID for the partition.

This worked great, all my data was still on the partition, and the "increase size" button worked exactly as it was supposed to, expanding the datastore to the end of the drive.

The only problem now was that since the "signature" of the datastore changed, it was no longer finding my guests on it. I was back to my questionmarks.

What I had to do, was remove all of my guests from inventory, and then go in to each guest folder on the datastore, and right click on each .vmx file and re-import them on to the host. On first run, the guest will ask if it was copied or moved (I answered moved) and then everything worked again just like it had before. All the configuration was restored, including all passthroughs.

Sometimes the dialogue asking if I had copied or moved the guest failed to display, and it would just get stuck in a neither powered on nor powered off state, with a questionmark icon. This had me bashing my head against a wall for a while, until I figured out you can go into the "guest" menu and click the "answer question" selection, in order to force the dialogue to display.

System configuration was entirely saved, except for auto-start/shutdown of guests, which I had to reconfigure.

So, long story short, I'm up and running the way I wanted to begin with. Old boot drive and datastore is gone, new one is in there, and there is no more ghetto tape mounting of drives :p
 
Last edited:
God damn that's a lot of work. At least you got it working though. Now you know why everyone else boots from USB and stores VMs elsewhere ;) :D
 
You must log in or register to reply here.
Back
Top