[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] 1. Domain Destroy , 2. Domain boot on a different host and 3. Domain start time



On 06/17/2010 07:04 PM, IKI-サガル バルウェ wrote:
<snip>
> I understood now what the destroy function does. As for "domainUndefine":
> To quote from the "undefine" method's documentation:
> Undefine a domain but does not stop it if it is running
> So, If the Domain remains as it is, what is the significance of removing the
> XML Description/Definition?
> What I want to do, is to remove the Domain completely from the system,
> including its associated virtual disks. Is there any way to do this using
> the API?

No worries.  There's a main concept you need to get, but it's easy so
keep on reading. :)

With libvirt, there are two related parts:

 a) Domain "definition" storage (an XML file)
 b) Running of a definition (KVM/Xen/etc)

Keeping the concept simple, the key idea is you have 2 ways of starting
a brand new domain:

 a) starting a domain in a "transient" fashion, where the XML that
    describes the domain's attributes and features isn't kept around.

    Using this method, KVM/Xen/etc is launched with the appropriate
    resources, but the config for it isn't saved to disk.  If you
    restart libvirt or the host server, then libvirtd will completely
    forget this domain exists.  It will be gone, and you won't be able
    to manage it.

    ================================================
    |  Runs in memory?  |   Config saved to disk?  |
    ================================================
    =      Yes          =            No            =
    ================================================


 b) starting a domain in a "persistent" fashion, where the XML that
    describes the domain's attributes and features IS kept around,
    saved to disk.

    Using this method, KVM/Xen/etc is launched with the appropriate
    resources too, plus the config for it (an XML file) is saved to
    disk.  If you restart libvirt, then libvirt knows about this
    domain and you can still manage it.

    ================================================
    |  Runs in memory?  |   Config saved to disk?  |
    ================================================
    =      Yes          =            Yes           =
    ================================================


The act of saving the config file to disk, so the domain is persistent,
is called "Defining" it.  You can get a type a) domain above that
wouldn't persist across host reboots, run a "Define" on it, then you
have a type b) that will persist across reboots.

Going the other way works too.  If you "Undefine" a domain, that doesn't
affect the running instance, but takes away the config file.  The next
time libvirt is restarted, the domain is unknown.

  http://libvirt.org/html/libvirt-libvirt.html#virDomainDefineXML
  http://libvirt.org/html/libvirt-libvirt.html#virDomainUndefine

****************

Separate to that are the "Create" and "Destroy" functions, which control
a (possibly running) instance:

  http://libvirt.org/html/libvirt-libvirt.html#virDomainCreate
  http://libvirt.org/html/libvirt-libvirt.html#virDomainDestroy

These don't affect the config file saved state, they just start up or
shut down KVM/Xen/etc.

****************

So, with the above in mind, to completely kill off a domain you need to
both:

  + Destroy it's instance if it's running
  + Undefine it's config file if it's defined

    Check with:
     http://libvirt.org/html/libvirt-libvirt.html#virDomainIsPersistent


(btw - this is all a concept explanation.  It's good enough to get you
started.  As you explore functions in the libvirt docs you will find and
learn to use bits that can short cut or change this. :> )


>>> Secondly, Is it possible to boot a domain on a completely different
>>> physical
>>> host with the same Hypervisor configuration?
>>
>> You can use libvirt for this, but it's not automatic.  As far as I know,
>> you'll need to have your software connect to each of the servers and
>> launch the appropriate virDomainCreate() (and probably other) commands.
>> So, it would be up to your application to make sure that the domain is
>> not running on server A, before you launch it on server B.
> 
> I am sorry, but I did not get this quite completely. Could you please
> explain this a bit more? Especially the "it would be up to your application
> to make sure that the domain is
> not running on server A, before you launch it on server B" part. Firstly,
> how will I get the domain from server A to server B to launch it there? By
> migrating it to server B?

Yeah, that's a more in depth explanation.  I don't personally have the
time at the moment to write that up. :(

The short answer is that you need to make sure the storage
(disk/SAN/NAS/etc) can be seen from both hosts, and that you can use
your above knowledge to transfer the XML config around (if you want) and
Create or Destroy or Migrate domains appropriately.

Hope that helps. :)

Regards and best wishes,

Justin Clift


> Please help.
> 
> Thanks and Regards
> Sagar Barve

-- 
Salasaga  -  Open Source eLearning IDE
              http://www.salasaga.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]