Adam Rosenwald wrote:
Thanks, Michael! See inline for comments...
Michael DeHaan wrote:
I've checked in some modifications to the --virt-path code and
rearranged it somewhat.
To use a standard disk image with koan:
leave --virt-path off and assume defaults (like /var/lib/xen/images)
While observing this (reasonable -- although should be documented in
Koan (if not already)) default, I think a free-space check is in order
for the filesystem that contains /var/lib/xen/images. If there is not
enough free space to accommodate --virt-size, then an error message
should be printed out. The current (virtinst?) reaction is to let the
filesystem fill up to 100% and /then* */alert the user about free
space. This doesn't make sense, and either cobbler/koan or dependency
libraries should show awareness of this problem.
Patches accepted -- though this should probably this should go in
virtinst as it wouldn't apply just to koan.
or specify --virt-path=/path/to/directory
What will the full virtual path be then? /path/to/directory/<name>?
/path/to/directory/<mac>?
If there is a specified name chosen on the client with --virt-name=bar,
/path/to/directory/$bar
If not...
For a profile: /path/to/directory/$macaddress
For a system: /path/to/directory/$nameofsystemobject
or specify --virt-path=/path/to/directory/filename
To use an existing partition:
specify --virt-path=/dev/sda4, or equivalent
To carve out of a chunk of a volume group, of the requested
--virt-size, using the name cobbler would ordinarily choose:
have an existing LVM volume group named something, such as
VolGroup00, with some free space on it
specify --virt-path=VolGroup00, or equivalent
or be more specific: --virt-path=VolGroup00 --virt-name=asdf
(this creates /dev/mapper/VolGroup00/asdf)
The --virt-name can be confusing with --name. What's wrong with
--virt-vg=VolGroup00 --virt-lv=asdf? Or --virt-path=VG:[LV]? To make
the second form clearer, '--virt-path=VolGroup00:' (notice the
trailing colon) or '--virt-path=VolGroup00:asdf'.
Those arguments are, IMHO, slightly confusing. Partitions start with
"/dev" (example: /dev/sda4), paths start with "/", so it's clear from
the path what the user is intending -- and much easier to
document/understand. It also helps keep koan/cobbler from getting too
many new arguments.
If you were concerned about the rare case where VolGroup or LogVol
included a colon in the name (e.g. "VolGroup\:" or "Log\:Vol00"), the
colon-checking could check for the existence of colons in the actual
filename and ignore them. Honestly, I don't think anyone would ever
consciously put a colon in their device name, unless (s)he were mad!
And this is a reasonable assumption!
While I'm not concerned with that, it also would not cause problems with
the current implementation.
Sidenote -- I've tested the above with qemu-kvm and they perform
quite well. When virt-manager's next-release supports installing
these
via kickstart locations (like Xen), I'll move the kvm bits over to
use virtinst -- until then, qemu-kvm systems created with koan do not
show up
in virt-manager and you have to use the standard KVM tools for basic
management. That should change very shortly.
Additionally I've added a --virt-graphics flag to koan which enables
VNC in both virt types ("qemu", "xenpv"). virt-graphics is
currently not read as a default
Cool! Should --virt-graphics check for the existence of vnc? Or are
you satisfied with xenlibs' awkward stack tracing output?
Koan is set to not-require a lot of optional things -- kvm, qemu, xen,
virtinst -- because the user might just be using --replace-self and we
do not want to pull in those dependencies.
value from cobbler, but it probably should be. --virt-path and
--virt-type can be passed to both koan and cobbler (profile add and
system add).
Awesome! Would you like me to follow your example in implementing the
other koan virt attributes? Or do you have these covered?
They are already implemented -- see upstream source.
-A.
--Michael
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
------------------------------------------------------------------------
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
