Ghost in the xen
I continue to scrutinize the Xen Cloud Platform and during the experiments I managed to create a “ghost”: a virtual machine that (from the point of view of the hypervisor) was missing.
This virtual machine once had a disk, but the disk was deleted (and only its cached copy remained in memory), which, in principle, did not prevent writing / reading on this disk.
This virtual machine once had a virtual network adapter, but it was removed, which in principle did not interfere with sending and receiving ip-packets.
')
This virtual machine was - and it was gone. She was not visible either at a high level or at a low level. It did not exist . Everything was complicated by the fact that I did not know on which of the cloud servers this virtual one worked.
In other words, I had a real full ghost. After I overloaded the required (laboratory) server, the virtual machine died. But the question remains open:
But what if this problem appears in a product in which it is not customary to overload hosts? If this virtual machine was controlled not by me, but by the client?
There is no virtual machine. Hosts (hosted virtual machines) are running. And somewhere between them a car was hidden, which is not. But which lives its own life.
... Maybe such cars already exist among the clouds hosting VDSs?
I remember a bike about a server that was accidentally bricked up and which continued to work for years. He was found passing through the wires.
And the virtual machine? Go through the virtual wires in the search for a non-existing virtual server?
And if this machine did not generate traffic, but thought something peaceful for itself? Not visible, not audible, not detectable ... Not that it was very scary, but ...
For publicity:
An experienced exorcist will drive all ghosts out of your cloud. Expensive. Warranty.
UPD: If anyone is interested in how this is done:
bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1606
After such a migration, we overload the wizard, “delete” all traces of the virtual machine — and it continues to work.
This virtual machine once had a disk, but the disk was deleted (and only its cached copy remained in memory), which, in principle, did not prevent writing / reading on this disk.
This virtual machine once had a virtual network adapter, but it was removed, which in principle did not interfere with sending and receiving ip-packets.
')
This virtual machine was - and it was gone. She was not visible either at a high level or at a low level. It did not exist . Everything was complicated by the fact that I did not know on which of the cloud servers this virtual one worked.
In other words, I had a real full ghost. After I overloaded the required (laboratory) server, the virtual machine died. But the question remains open:
But what if this problem appears in a product in which it is not customary to overload hosts? If this virtual machine was controlled not by me, but by the client?
There is no virtual machine. Hosts (hosted virtual machines) are running. And somewhere between them a car was hidden, which is not. But which lives its own life.
... Maybe such cars already exist among the clouds hosting VDSs?
I remember a bike about a server that was accidentally bricked up and which continued to work for years. He was found passing through the wires.
And the virtual machine? Go through the virtual wires in the search for a non-existing virtual server?
And if this machine did not generate traffic, but thought something peaceful for itself? Not visible, not audible, not detectable ... Not that it was very scary, but ...
For publicity:
An experienced exorcist will drive all ghosts out of your cloud. Expensive. Warranty.
UPD: If anyone is interested in how this is done:
bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1606
After such a migration, we overload the wizard, “delete” all traces of the virtual machine — and it continues to work.
Source: https://habr.com/ru/post/92375/
All Articles