Re: [convirt-users] guests lacking info after config file import

[jd <jds...@ya...>]

I think this is addressed on the forums.

http://www.convirture.org/forums/viewtopic.php?f=35&t=2019&sid=065cb35d38314caf6e7719ceb884a5b4

--- On Sat, 6/5/10, Jesús M. Navarro <jes...@an...> wrote:

> From: Jesús M. Navarro <jes...@an...>
> Subject: [convirt-users] guests lacking info after config file import
> To: xen...@li...
> Date: Saturday, June 5, 2010, 7:16 AM
> Hi list:
> 
> I'm using convirt 2.0 + patch bundle 1 on a test
> environment: Debian "Lenny" 
> with Xen for virtualization servers; paravirtualized guests
> and cLVM for 
> shared storage.
> 
> Since I already have production virtualization environment
> I started my tests 
> importing the config files for some of our (at the moment
> unused) virtual 
> guests.  Import procedure went OK (more or less: there
> were some minor 
> problems with regards of managing white spaces and/or
> multiline definitions, 
> but nothing non-obvious).
> 
> Once the definition imported, the info page for the virtual
> machine will show 
> no info neither for "Guest OS" (which I quite of
> understand) nor for "Virtual 
> CPUs" (I don't understand this one since it's right there,
> on the config).
> 
> On the other hand, it seems non posible to properly
> "integrate" the imported 
> config within "standard" convirt management tools: the
> "edit settings" option 
> does nothing, so you are stuck with managing the guest by
> means of the "Edit 
> Virtual Machine Config File", both suboptimal and
> misleading since the option 
> *won't* edit the config file but the imported version
> within the convirt 
> database.
> 
> By the way, while understandable, the "import config file
> and manage it from 
> the database from then on" seems a bit like burning your
> ships.  Being that 
> convirt is basically a "stateless" management tool (which I
> honour as being 
> one of its strong points -while a bit more on the
> conciliation side between 
> known state and reality would be quite worthy) it would be
> very interesting 
> some kind of "export" button or script that would produce
> valid config files 
> for the guests in case the user wants or needs to get free
> from the tool 
> (i.e.: because a show-stopping bug, at least while the bug
> is resolved).  
> Please pay attention that all this "virtualization trend"
> (which is here not 
> to go away), specially with regards of their management
> tools, means "putting 
> all your eggs in the same basket".
> 
> As an example, I manage a "not even big" environment with
> 10 virtualization 
> servers and about 200 virtual guests: a glitch on our
> management tools would 
> literally mean taking the whole company to its knees (see,
> for instance my 
> previous post about not being able to "move away" guests
> from failing 
> servers) so sounded ingeneering principles and clear and
> safe "escape lanes" 
> are paramount for our tool of choice (or else get along
> with our current 
> heavy-on-management but strongly decoupled and easy to
> fail-proof tools and 
> procedures).
> 
> Cheers.
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to
> win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> XenMan-Users mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenman-users
>