I cannot restore a snapshot of an instance with Windows Server 2019.
When restoring the snapshot generated with the machine turned on, I get a machine that does not start and always has a blue screen as a return.
When restoring a snapshot generated with the machine turned off, everything works normally, the restored machine boots normally.
Serial Port = inaccessible_boot_device 0xffff google cloud platform
There is a restriction in VSS enabled snapshot.
When a VSS snapshot is taken, Windows marks the volume as read-only.
The read-only flag must be cleared if a user want to create an instance from it.
To work around this, remove the read-only flag from any new disk that you create from a VSS snapshot.
Alternatively, you can create a new disk/compute instance using gcloud beta compute instances create --erase-windows-vss-signature
gcloud compute instances create instance-3 \
--source-snapshot=snapshot-1 \
--boot-disk-size=50 \
--boot-disk-type=pd-standard \
--boot-disk-device-name=instancedisk-3 \
--erase-windows-vss-signature
Related
I have created a VM with GPU and have been using it since then.
is it possible to make this VM preemptable by changing it configuration now?
In Edit config, I see preemptability as Off, but it is grayed out and not letting me change it.
Any suggestions?
According to the google documentation, these are the properties you can change after creating a VM. As you'll notice, you can not change the preemptive property of an instance.
However, a possibility would be to snapshot your current disk
gcloud compute disks snapshot DISK_NAME \
--snapshot-names=SNAPSHOT_NAME
--storage-location STORAGE_LOCATION
And spin up a new instance using the snapshot of the former
gcloud compute instances create VM_NAME \
--source-snapshot=BOOT_SNAPSHOT_NAME \
--boot-disk-size=BOOT_DISK_SIZE \
--boot-disk-type=BOOT_DISK_TYPE \
--boot-disk-device-name=BOOT_DISK_NAME
Full GCP Documentation:
https://cloud.google.com/compute/docs/disks/create-snapshots
https://cloud.google.com/compute/docs/instances/create-start-instance#restore_boot_snapshot
Hope all are safe and doing well.
I have few running servers on google cloud and for them, snapshots are scheduled on daily basis in an incremental way.
I am trying to create a new instance on a different VPC zone by using the same snapshots but it will be giving me an error.
For reference, I have added an attachment to this question.
Please help me to resolve this issue and thanks in advance.
Assuming that you have created a Snapshot with Application consistency(VSS) enabled:
When you create a VSS snapshot, Windows Server marks the volume in the
snapshot as read-only. Any disks that you create from the VSS
snapshot are also in read-only mode. So, the read-only flag on the new
boot disk prevents the VM instance from booting correctly.
You can follow this documentation to resolve your issue here.
If the disk you created from the VSS snapshot is a boot disk and you want to use it to boot a VM instance, you must temporarily attach the disk to a separate, existing VM instance. Once you complete the following steps, you can detach the disk from that existing VM instance and use it to boot a new VM instance.
I am breaking out in a sweat now.
I wanted to move a VM to a different zone within the same region. I run
gcloud compute instances move move-this-vm --zone xxxx --destination-zone xxxx
I checked on the VM after the command has run, it has disappeared!! I can't find it. I did
gcloud compute instances list
It is not listed. It is not shown on the web console either.
I have created a machine image of a VM before move so I am not worried about data lost. However, I am bizzared.
Is this a common glitch for moving VM using the CLI? In this scenario, what can I do to retrieve the VM? Why does it happen?
I accidentally deleted my ai notebook vm and I hadn't downloaded the notebooks connected to it. I still have the url. Does anybody know if there's a way for me to recover my work?
According to the documentation, there is a life cycle for the instances. Verify the state of your AI Notebook VM to make sure that it is deleted or just turned off.
Unfortunately, if an AI Notebook instance is deleted and there is no snapshot configured, there is no way to restore that instance neither recover the notebooks stored there. There are three ways to prevent this from happening in the future:
Create snapshots to periodically or schedule back up data from your zonal persistent disks (snapshot can be located in multiple zones) or regional persistent disks (You must indicate the region where the disk is located ).
Edit VM instance, go to the deletion protection checkbox to enable it as this option is disabled by default. This setup will avoid that your Notebook instance was deleted by accident.
In the VM instance, go to boot disk, in the drop down list under “When deleting instance” select “Keep Disk” (or you can use gcloud command to disable set-disk-auto-delete)
I have a scheduled daily snapshot in GCP for one of my instances. I have several snapshots now. The first one is the full snapshot and the rest of the snapshots only contain changed data.
I want to be able to restore and boot the instance but it fails to boot. Checking the serial console I see reference to a blue screen and then it reboots and shows the same errors again, repeating the reboot cycle.
I have followed the guide in GCP on how to restore an instance from a snapshot by creating a new instance, selecting the snapshot tab and then selecting my snapshot. After saving the instance and trying to boot it I get the blue screen message.
Also, if I create a new instance and use a Windows 2008 R2 Datacenter image the system obviously boots fine but if I try to attach the snapshot disk as a secondary disk (non-boot) then I get the error: Editing VM instance failed. Error: Supplied fingerprint does not match current metadata fingerprint. I'm not sure if this is related to my issue with unable to boot the OS from my snapshot.
I did find a workaround:
1) create an image of running instance (my instance is Win'2008 R2 Datacenter)
2) enable scheduled snapshots of this new instance (with VSS)
3) wait for a scheduled snapshot to get created (hourly so must wait 1 hr)
4) create new instance from the scheduled snapshot
After all this work the instance boots just fine with all my data. Obviously not a very good workaround as now I have two instances with the same data. So I have to schedule the production system for maintenance so that I can bring it down and use the new instance so that future scheduled snapshots work if I try to restore it again. A major paint in the butt.
Anyone have any ideas as to why none of my instances boot from scheduled snapshots without my workaround? Manual snapshots work fine. And new instances also work fine with the same snapshot schedule.
I had this exact same problem. I tried multiple scheduled snapshots with the same result UNTIL I made a change in the VM Instance when attaching the restored snapshot. Maybe it's just Windows but if you named the disk something different then it seems to fail.
My original disk was called disk-1 for example. When I restored the snapshot I did it to disk-1-a and attached it to my instance. It failed the same way yours did. When I attach it and under "Device name" for the boot disk, select Custom and entered my original disk name of disk-1, it booted and RDP worked.