Be able to add additional disk space to the VMs
Can you please elaborate on this scenario? If we provide an option to change the sku size (ex. change small to medium/large or vice versa), would that suffice?
Please add the option to add more disk space for the VMs. This would greatly expand what one can do in AzureLabs, particularly for more technical software training. We are getting by using the max RAM allowed, but our application on our VMs is running very slowly.
I'm fighting the whole time with a lack of disk space in my Azure Lab. I'm using a lab environment based of nested virtualization with several VMs, and I'm often running out of disk space on the host.
My savior is deduplication, but it's only an interim solution.
Anders Sekkelund commented
I'm running a class about Windows Server administration and need 2xwindows 10 and 4 xserver 2019, which requires more than the maximum disk size possible, i would have to be able to expand to at least 256 GB or even better 512 GB disk in the Large VM that im using.
Hi Pedro, I'm trying to deploy the image that you suggested, but I'm not able to do it. Can you help me? How do you add the shared image in the Lab?
Hi, I've the same requirement about increase OS disk size; but I found an alternative:
- Create a new Win10 VM (for example) in Azure
- Stop & Deallocate VM
- Increase OS disk size to desiderable size (512GB for example)
- Start VM and increase os disk size for OS.
- Run sysprep for generalize
- Run Capture VM option from Azure portal and select one Shared Imaged Gallery.
- Deploy new Lab from this custom template
New VMs in this lab maintain new OS disk size!
This works but I've a big doubt... what happen about costs for new disk size?!
Marc-Andre Moreau commented
I have used every trick in the book to reduce disk usage for a lab of nested VMs and 128GB is simply not enough. Can I talk to someone about this? I like everything else about the product, it's just a shame that the storage page is so limited with no way to pay for more.
I responded on the blog post with tips for nested virtualization and added the ones I had to use to successfully create a lab of 5 nested VMs, but then I'm quickly running out of space, with less than 5GB left.
One cannot realistically build a full VM lab with a domain controller and a few domain-joined VMs without having to seriously compromise on just about everything due to the low disk space. 256GB instead of 128GB would make a world of difference, and 512GB would be very comfortable. I am more than willing to pay extra, the issue is there is no option offered right now for extra storage.
Marc-Andre Moreau commented
I've been experimenting with Azure Lab Services for over a week now, trying to build a full lab of nested VMs on the large instances (8 cores, 32GB of RAM, nested virt) and now I am faced with the reality that a 128GB hard drive is going to be particularly difficult to work with. I'll have to optimize everything for size, disable checkpoints and anything that generates large files.
Is there no way around this? I found ways to do everything I need, but that could easily be a show-stopper :'(
Drew Darrow commented
With the ongoing pandemic, a major aerospace firm I contract to has had to end its in person training of field users on the installation and use of an in-house built application that runs within Windows 10. The laptops used for in person sessions had 512GB OS Drives, more than enough installation space for the application, which when fully installed, uses 150GB of disk space.
The idea was to move this to a virtual environment using Azure Lab Services, enabling the instructors to spin up and spin down classes at will. A major roadblock we've run into is the Azure Lab instances only have 108GB Free on the OS drive, and the temp drive is not usable as its limited to 38GB and temporary storage only. Please add a feature to either attach a disk to each instance with enough storage space for these types of activities, or increase the OS disk size to accommodate such tasks. This service is more than ideal in its self service nature. The cost for us to spin up something remotely similar in WVD is not cost effective.
Jim Ratsch commented
No, although it would be nice to be able to change the SKU size, it would not address this problem. The whole premise for running nested virtualization is to run VMs on the virtual host. Many different types of labs will require more than 4 or so VMs, which is about the limit considering the footprint of fresh installed Windows on those VMs. My customer wants to set up a generic lab for testing, that will have AD and other roles in it. This will take at least a dozen VMs, but conceptually would really be great because they could issue copies of it to different admins on the team to do independent testing without interfering with other admins' (students :-)) work. I would suggest adding the capability to either have a nested template with an additional drive, along with the expected cost, OR add an option to add additional space to any SKU, along with an estimated cost.
Tyler Dickieson commented
+1 We have some large software packages that need some extra C: drive space.
@azuresupport recommended adding feedback to this.
My class doesn't fit in to the <98GB of free space on the hard drive, because we have a few virtual machines. It would be nice to have the option to increase the hard disk space available for use, especially for instances recommended for nested virtualization.
I have had a scenario where I had enough RAM and CPU-cycles, but did not have enough disk-space to support the set of nested vm's I needed to run. Expanding the disk space only (maybe already on lab creation) will fix this, but I see challenges when it comes to the billing scenario that is easy to understand and based on pre-defined SKU sizes.
Robin Admin commented
No. I don't need lots of CPU power, but I do need bigger than a 120GB C drive.
I need to either be able to increase the C drive size, or add additional data disks.
Otherwise the storage is too small to run multiple VMs from. I've got plenty of CPU and RAM but insufficient storage.