This operation cannot be performed because this VDI is in use by some other operation

[Jason Newsted]

Hello.

I used " xe vm-copy" for copy my storage to another Storage but I canceled it. I have three storage with the names "Storage1" , "Storage2" and "Storage3". My VMs used "Storage1" and "Storage2" and I wanted to copy Storage1 data to Storage3. When I want to Destroy Storage3 it show me :

 

[root@xenserver ~]# xe pbd-unplug uuid=1ef458b5-af53-c796-aab4-c308adbade91

This operation cannot be performed because this VDI is in use by some other operation

vdi: 6418cbc3-495e-442c-ad0e-40c06bd180f8 (HDD1)

operation: <unknown>

 

Details are :

 

[root@xenserver ~]# xe sr-list 

uuid ( RO)                : 36f77f69-1bfa-aae0-9cff-e6f7baf0537e

          name-label ( RW): storage1

    name-description ( RW): 

                host ( RO): xenserver

                type ( RO): lvm

        content-type ( RO): user

 

 

uuid ( RO)                : d97bbb57-f8b6-076f-1a76-020ffe45c18c

          name-label ( RW): Local storage

    name-description ( RW): 

                host ( RO): xenserver

                type ( RO): ext

        content-type ( RO): user

 

 

uuid ( RO)                : 8e4aa9c7-f558-9164-46cd-6c5df455ef11

          name-label ( RW): storage3

    name-description ( RW): 

                host ( RO): xenserver

                type ( RO): lvm

        content-type ( RO): user

 

 

uuid ( RO)                : 1db65f3d-6612-014f-a09c-35895fc4d0f5

          name-label ( RW): DVD drives

    name-description ( RW): Physical DVD drives

                host ( RO): xenserver

                type ( RO): udev

        content-type ( RO): iso

 

 

uuid ( RO)                : 13be5b92-5c2f-a5ce-5b99-db6e7163e699

          name-label ( RW): XenServer Tools

    name-description ( RW): XenServer Tools ISOs

                host ( RO): xenserver

                type ( RO): iso

        content-type ( RO): iso

 

 

uuid ( RO)                : 1727281b-a3b2-dafd-b610-7da444542ae5

          name-label ( RW): Removable storage

    name-description ( RW): 

                host ( RO): xenserver

                type ( RO): udev

        content-type ( RO): disk

 

 

uuid ( RO)                : 2f8052e1-2acc-d8c2-28bc-9e72aa6ffbf3

          name-label ( RW): storage2

    name-description ( RW): 

                host ( RO): xenserver

                type ( RO): lvm

        content-type ( RO): user

 

 

In your opinion my VMs used Storage3 because of copy? I want to destroy Storage3 but don't like to lost my data on Storage1 and Storage2.

 

I used below command with Storage3 UUID :

 

[root@xenserver ~]# xe vm-list uuid=8e4aa9c7-f558-9164-46cd-6c5df455ef11

[root@xenserver ~]# 

 

As you see no VM on Storage3.

 

I attached a photo too.

 

Thanks.

[Christoph Wegener]

It seems that you somehow managed to attach a 1TB VDI to your dom0.

[Jason Newsted]

Oh, I didn't know it and it was not my Goal. How can I solve it? Is it a Bug?

[Jason Newsted]

Dear Members. I know that you have not any promise to help but I'm thankful if you advice me about this problem. It is very Vital.

 

Thank you.

[Tobias Kreidl]

You should be able to go into XenCEnter with the VM shut down and click on the VM on the left, then on the "storage" tab anbd either remove the old drive and/or attach the correct drive. If you then click on the line with the dive itself, you can select "properties" from the tab below and click then on the device filed on the left. There, you will see a device position. CHange your root partition back to "0", click OK, and you should be good to boot back up.

-=Tobias

[Jason Newsted]

Thank you Tobias.

I want to know can it destroy my real Data on Storage1? As I said, I copy VM from Storage1 to Storage3 but I guess two storage are Linked :(. I don't like to lost my Data on Storage1 because of destroy Storage3.

​I want to know the situation that you recommended doing it?

[Jason Newsted]

I want to know can it destroy my real Data on Storage1? As I said, I copy VM from Storage1 to Storage3 but I guess two storage are Linked :(. I don't like to lost my Data on Storage1.

​I want to know the situation that you recommended doing it?

[Alan Lantz]

You probably have a stale lock if its not an actual task. Cycling through all of your XenServers will clear that out. Its a pain, but its a good reminder that hitting cancel on a process is a bad idea.

 

--Alan--

[Jason Newsted]

Thank you.

I want to know with "Tobias Kreidl" idea, can I fix it? I don't like to lost Data on Storage1. As I said, I wanted copy Storage1 to Storage3 and canceled it but I guess Storage3 linked to Storage1. If I destroy Storage3, Can it destroy Storage1 too?

[Jason Newsted]

Any idea?

[Tobias Kreidl]

Detaching a storage drive will not destroy it. You have to be careful to not "forget", "delete" or "destroy" it.

[Jason Newsted]

Thank you.

Can you tell me what happened? I just copy Storage 1 to Storage 3 and cancel it and I don't know why this problem rise!

 

[root@xenserver ~]# xe vm-list uuid=8e4aa9c7-f558-9164-46cd-6c5df455ef11

[root@xenserver ~]# 

 

As you see, not any VM exist on Storage3.

[Tobias Kreidl]

Something clearly went awry.  I'd list all the VDIs associated with SRs using "xe sr-list uuid=(UUID-of-SR) params=all"
as well as listing the PBDs and seeing which VM they are associated with using "xe pbd-list ...". You may be able to match things up.

Also, check if there isn't a stuck process with "xe task-list" and if so, use "xe task-cancel uuid=(UUID-of-process" to try to stop it.

Finally, a reboot may clear things up, but I understand your concern with not wanting to lose your data.

-=Tobias

[horizon limit]

Just a brief info : using a vm-copy command copies vm-metadata and the vdi the  will ask xapi to create a vbd between the dom0 and the vdi, that is whay in the Storage tab, you would be able to see something like "control domain on <hostname of the xenserver>" listed under the virtual machine  against the vdi.

 

there are three methods to resolve this ;

 

- identify the vbd between the vdi and the control domain and destroy it.

- forget the vdi  in question and scan the SR again to the see the vdi again .  Make sure the sr-scan works  before forgetting the vdi.

- reboot the xenserver. 

 

HTH !.

[Jason Newsted]

Something clearly went awry.  I'd list all the VDIs associated with SRs using "xe sr-list uuid=(UUID-of-SR) params=all"

as well as listing the PBDs and seeing which VM they are associated with using "xe pbd-list ...". You may be able to match things up.

Also, check if there isn't a stuck process with "xe task-list" and if so, use "xe task-cancel uuid=(UUID-of-process" to try to stop it.

Finally, a reboot may clear things up, but I understand your concern with not wanting to lose your data.

-=Tobias

 

Thank you.

The information that you need are :

 

 

uuid ( RO)                : 8e4aa9c7-f558-9164-46cd-6c5df455ef11

          name-label ( RW): storage3

    name-description ( RW): 

                host ( RO): xenserver

                type ( RO): lvm

        content-type ( RO): user

 

 

 

 

[root@xenserver ~]# xe sr-list uuid=8e4aa9c7-f558-9164-46cd-6c5df455ef11 params=all

uuid ( RO)                    : 8e4aa9c7-f558-9164-46cd-6c5df455ef11

              name-label ( RW): storage3

        name-description ( RW): 

                    host ( RO): xenserver

      allowed-operations (SRO): VDI.create; VDI.snapshot; PBD.create; PBD.destroy; plug; update; VDI.destroy; scan; VDI.clone; VDI.resize; unplug

      current-operations (SRO): 

                    VDIs (SRO): 6418cbc3-495e-442c-ad0e-40c06bd180f8

                    PBDs (SRO): 1ef458b5-af53-c796-aab4-c308adbade91

      virtual-allocation ( RO): 1075847364608

    physical-utilisation ( RO): 1075851558912

           physical-size ( RO): 2560702283776

                    type ( RO): lvm

            content-type ( RO): user

                  shared ( RW): false

           introduced-by ( RO): <not in database>

            other-config (MRW): 

               sm-config (MRO): allocation: thick; use_vhd: true; devserial: scsi-3600508b1001c763784ff63e50a417e09

                   blobs ( RO): 

     local-cache-enabled ( RO): false

                    tags (SRW): 

 

 

 

 

[root@xenserver ~]# xe pbd-list 

uuid ( RO)                  : 1ef458b5-af53-c796-aab4-c308adbade91

             host-uuid ( RO): b28ef29a-1d10-4f47-adf2-470c21255eb2

               sr-uuid ( RO): 8e4aa9c7-f558-9164-46cd-6c5df455ef11

         device-config (MRO): device: /dev/sdd

    currently-attached ( RO): true

 

 

uuid ( RO)                  : c1d09975-89f6-c182-929e-5b9c38a7721b

             host-uuid ( RO): b28ef29a-1d10-4f47-adf2-470c21255eb2

               sr-uuid ( RO): d97bbb57-f8b6-076f-1a76-020ffe45c18c

         device-config (MRO): device: /dev/disk/by-id/cciss-3600508b1001c63d9da693b4ac0442191-part3

    currently-attached ( RO): true

 

 

uuid ( RO)                  : ad60fac5-f4a3-116e-5cf5-0665f5f00e2c

             host-uuid ( RO): b28ef29a-1d10-4f47-adf2-470c21255eb2

               sr-uuid ( RO): 1db65f3d-6612-014f-a09c-35895fc4d0f5

         device-config (MRO): location: /dev/xapi/cd

    currently-attached ( RO): true

 

 

uuid ( RO)                  : c2ac413b-d37c-3022-7b3e-a548f82bcabd

             host-uuid ( RO): b28ef29a-1d10-4f47-adf2-470c21255eb2

               sr-uuid ( RO): 2f8052e1-2acc-d8c2-28bc-9e72aa6ffbf3

         device-config (MRO): device: /dev/sdc

    currently-attached ( RO): true

 

 

uuid ( RO)                  : 1a7b91e1-29ea-bf2f-bd88-d9fad3060edc

             host-uuid ( RO): b28ef29a-1d10-4f47-adf2-470c21255eb2

               sr-uuid ( RO): 1727281b-a3b2-dafd-b610-7da444542ae5

         device-config (MRO): location: /dev/xapi/block

    currently-attached ( RO): true

 

 

uuid ( RO)                  : b17e436b-95bb-bb9c-06af-2fe8f5dd9c86

             host-uuid ( RO): b28ef29a-1d10-4f47-adf2-470c21255eb2

               sr-uuid ( RO): 13be5b92-5c2f-a5ce-5b99-db6e7163e699

         device-config (MRO): location: /opt/xensource/packages/iso; legacy_mode: true

    currently-attached ( RO): true

 

 

uuid ( RO)                  : 9d4e8610-2d1c-cdec-8951-349d2241cd3e

             host-uuid ( RO): b28ef29a-1d10-4f47-adf2-470c21255eb2

               sr-uuid ( RO): 36f77f69-1bfa-aae0-9cff-e6f7baf0537e

         device-config (MRO): device: /dev/sdb

    currently-attached ( RO): true

 

 

 

[root@xenserver ~]# xe pbd-list uuid=8e4aa9c7-f558-9164-46cd-6c5df455ef11

[root@xenserver ~]# 

 

 

[root@xenserver ~]# xe task-list 

[root@xenserver ~]# 

 

 

I also attach some Screenshots too.

[Jason Newsted]

Just a brief info : using a vm-copy command copies vm-metadata and the vdi the  will ask xapi to create a vbd between the dom0 and the vdi, that is whay in the Storage tab, you would be able to see something like "control domain on <hostname of the xenserver>" listed under the virtual machine  against the vdi.

 

there are three methods to resolve this ;

 

- identify the vbd between the vdi and the control domain and destroy it.

- forget the vdi  in question and scan the SR again to the see the vdi again .  Make sure the sr-scan works  before forgetting the vdi.

- reboot the xenserver. 

 

HTH !.

 

Thank you.

Please see the information that I provided.

[Jason Newsted]

These are the information that you needed?

[Tobias Kreidl]

It would appear there is only one PBD on that SR.  Could you verify that with the following?:

 

xe pbd-list sr-uuid=8e4aa9c7-f558-9164-46cd-6c5df455ef11 params=all

 

and see what device(s) it returns.

 

-=Tobias

[Jason Newsted]

It would appear there is only one PBD on that SR.  Could you verify that with the following?:

 

xe pbd-list sr-uuid=8e4aa9c7-f558-9164-46cd-6c5df455ef11 params=all

 

and see what device(s) it returns.

 

-=Tobias

 

Thank you.

 

The result is :

 

[root@xenserver ~]# xe pbd-list sr-uuid=8e4aa9c7-f558-9164-46cd-6c5df455ef11 params=all

uuid ( RO)                  : 1ef458b5-af53-c796-aab4-c308adbade91

     host ( RO) [DEPRECATED]: b28ef29a-1d10-4f47-adf2-470c21255eb2

             host-uuid ( RO): b28ef29a-1d10-4f47-adf2-470c21255eb2

       host-name-label ( RO): xenserver

               sr-uuid ( RO): 8e4aa9c7-f558-9164-46cd-6c5df455ef11

         sr-name-label ( RO): storage3

         device-config (MRO): device: /dev/sdd

    currently-attached ( RO): true

          other-config (MRW): storage_driver_domain: OpaqueRef:8704dd9d-bd94-946e-70f3-040778d1ac96

 

 

[root@xenserver ~]# 

[Tobias Kreidl]

OK, so if that is indeed the one you want to delete (storage 3) you should be able to do a "xe pbd-unplug uuid=1ef458b5-af53-c796-aab4-c308adbade91" and follow that with a "xe pbd-destroy uuid=1ef458b5-af53-c796-aab4-c308adbade91"  to get rid of it.

[Jason Newsted]

As I said, I used this command it show me an error :

 

[root@xenserver ~]# xe pbd-unplug uuid=1ef458b5-af53-c796-aab4-c308adbade91

This operation cannot be performed because this VDI is in use by some other operation

vdi: 6418cbc3-495e-442c-ad0e-40c06bd180f8 (HDD1)

operation: <unknown>

[root@xenserver ~]# 

 

 

It is my problem :(

[Tobias Kreidl]

Got to find where the VDI is still in use -- at least you know its UUID (6418cbc3-495e-442c-ad0e-40c06bd180f8). Time to hunt it down!

[Jason Newsted]

Got to find where the VDI is still in use -- at least you know its UUID (6418cbc3-495e-442c-ad0e-40c06bd180f8). Time to hunt it down!

 

How can I find it ? :(

[Tobias Kreidl]

xe vdi-list uuid=6418cbc3-495e-442c-ad0e-40c06bd180f8 params=all

 

If the associated VBD has been unplugged, you should be able to then run

xe vdi-destroy uuid=6418cbc3-495e-442c-ad0e-40c06bd180f8

 

If not, you need to first unplug and destroy the VBD associated with that VDI that should be able to be found with

xe vbd-list vdi-uuid=6418cbc3-495e-442c-ad0e-40c06bd180f8

 

(look for the UUID of the associated VBD) and then run

 

xe vbd-unplug uuid=(UUID-of-VBD)

xe vbd-destroy uuid=(UUID-of-VBD)

[Jason Newsted]

xe vdi-list uuid=6418cbc3-495e-442c-ad0e-40c06bd180f8 params=all

 

If the associated VBD has been unplugged, you should be able to then run

xe vdi-destroy uuid=6418cbc3-495e-442c-ad0e-40c06bd180f8

 

If not, you need to first unplug and destroy the VBD associated with that VDI that should be able to be found with

xe vbd-list vdi-uuid=6418cbc3-495e-442c-ad0e-40c06bd180f8

 

(look for the UUID of the associated VBD) and then run

 

xe vbd-unplug uuid=(UUID-of-VBD)

xe vbd-destroy uuid=(UUID-of-VBD)

 

I run the first command and results are :

 

[root@xenserver ~]# xe vdi-list uuid=6418cbc3-495e-442c-ad0e-40c06bd180f8 params=all

uuid ( RO)                    : 6418cbc3-495e-442c-ad0e-40c06bd180f8

              name-label ( RW): HDD1

        name-description ( RW): 

           is-a-snapshot ( RO): false

             snapshot-of ( RO): <not in database>

               snapshots ( RO): 

           snapshot-time ( RO): 19700101T00:00:00Z

      allowed-operations (SRO): clone; snapshot

      current-operations (SRO): 

                 sr-uuid ( RO): 8e4aa9c7-f558-9164-46cd-6c5df455ef11

           sr-name-label ( RO): storage3

               vbd-uuids (SRO): ab972ad1-6cb8-b11c-75c1-90bce6ae1380

         crashdump-uuids (SRO): 

            virtual-size ( RO): 1073741824000

    physical-utilisation ( RO): 1075847364608

                location ( RO): 6418cbc3-495e-442c-ad0e-40c06bd180f8

                    type ( RO): User

                sharable ( RO): false

               read-only ( RO): false

            storage-lock ( RO): false

                 managed ( RO): true

                  parent ( RO): <not in database>

                 missing ( RO): false

            other-config (MRW): 

           xenstore-data (MRO): 

               sm-config (MRO): vdi_type: vhd

                 on-boot ( RW): persist

           allow-caching ( RW): false

         metadata-latest ( RO): false

        metadata-of-pool ( RO): <not in database>

                    tags (SRW): 

[root@xenserver ~]# 

 

 

Tobias, I'm afraid and I don't like it affect to my Storage1 :(

[Tobias Kreidl]

Jason,

Note the associated VBD is on the SR names "storage3" and with UUID 8e4aa9c7-f558-9164-46cd-6c5df455ef11 -- are your "real" VDIs on that same SR or a different one?

 

Id you run "xe vm-list uuid-(UUID0of-your-VM) params-all" it will list out all associated VDIs. You should be able to prove to yourself which ones (1 and 2) are OK based on their VDIs and by doing the same "xe vd-list" command for them, you should be able to convince yourself which ones are the real ones. Note that a "vbd-unplug" does not destroy anything -- it just disassociates the VDI with the virtual block device. If you wanted to, you could right away plug it back in again.

 

That all said, have you tried a basic reboot just to see what he;lp that might do all on its own?

-=Tobias