[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [libvirt] Adding VirtualBox support to libvirt
- From: Pritesh Kothari <Pritesh Kothari Sun COM>
- To: libvir-list redhat com
- Cc:
- Subject: Re: [libvirt] Adding VirtualBox support to libvirt
- Date: Thu, 26 Feb 2009 17:20:55 +0100
Hi John,
> Generally, if you can, use the generic parts. If you need to specify
> something specific to VBox you have three options:
>
> 1. work out a hypervisor-agnostic abstraction for what you're trying to
> define (preferred), then use that
> 1. define a vbox-specific ref as you above
> 2. if it's just a small addition or choice, allow it as optional in the
> spec (say it's a disk property you want to add)
Thanks for the detailed explanation, as you mentioned above I will try to use
the generic parts first.
>
> > What exactly does the tag <os_type>xen</os_type> exactly mean? how can
> > xen, hvm, etc be an os type?
>
> It's a horrible wart. OS type really means "v12n method", and it means
> either paravirt or HVM here. Presumably vbox wouldn't use this choice
> (remember the relax ng spec isn't/can't be completely prescriptive).
so you mean to say, I can just use the parts necessary for me and don't care
about the rest?
> > why virDomainCreate doesn't actually create the domain but it just starts
> > it? (virDomainCreateXML actually creates it)
>
> Bad names. "Create" means start, "CreateXML" means "create using the
> definition given here, but don't persist the definition when it's shut
> down".
great.. :)
Regards,
-pritesh
>
> regards
> john
>
> --
> Libvir-list mailing list
> Libvir-list redhat com
> https://www.redhat.com/mailman/listinfo/libvir-list
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]