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 <jesus.nava...@andago.com> wrote: > From: Jesús M. Navarro <jesus.nava...@andago.com> > Subject: [convirt-users] guests lacking info after config file import > To: xenman-users@lists.sourceforge.net > 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 > XenMan-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xenman-users > ------------------------------------------------------------------------------ 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 XenMan-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xenman-users
